AppExchange and package licensing – Salesforce Data Management – Salesforce Certified Data Architect Study Guide

AppExchange and package licensing

Depending on the licensing requirements of an AppExchange, managed, or unmanaged package, permission set licenses are the typical method of licensing paid packages. As you’ll already know, when installing a package from AppExchange (or directly from Salesforce, in the case of an offering such as Financial Services Cloud), users will need to be given the correct permission set licenses in order to gain access to any objects or other functionality specific to that package. When designing solutions that require access to data entities and other functionality exposed by a package, one or more permission set licenses associated with that managed package will need to be given to the users that require access to that functionality.

As you now know, there are myriad licensing options available to us as Salesforce architects when it comes to producing robust, scalable solutions on the platform to deliver the right functionality to the right users. This extends to external users of the system interacting in a controlled manner to the data held within your Salesforce Organization (org). We can now turn to persisting data in a consistent manner on the Salesforce Platform.

Persisting data

Ensuring data is persisted in a consistent manner is paramount to the long-term success of a Salesforce implementation. Therefore, it is important to understand the causes of data quality issues and the techniques available to improve data quality but ideally prevent it from happening in the first place as much as possible.

Data quality issues can arise due to the age of the data, how complete and accurate the data is, whether duplicate data exists, and the consistency in the way data is used. Data quality issues can cause users to be presented with incomplete or incorrect information, causing them to spend more time gathering that information (which may require them to spend time in multiple systems or with multiple data sources). Worse still, customers may be subjected to poor customer service caused by account managers or service agents having incomplete or incorrect information. Lastly, frustrated users may be deterred from utilizing a System Of Record (SOR) and move to offline processes instead, meaning reduced or degrading system adoption. Luckily, Salesforce has several features that can be utilized in order to address these potential issues.

Starting with duplication of data, Salesforce has the ability to specify matching and duplicate rules in order to identify and merge records of a particular type, such as duplicate leads (such as an example of multiple Web2Lead captures from the same person yet existing as multiple lead records). The out-of-the-box matching and duplicate rules are built around sensible defaults, such as leads or contacts sharing an email address being potential duplicates. Users are presented with a notification on the Salesforce User Interface (UI) from which they can take remedial action such as discarding the record they are on (or the potential duplicate) or merging record information together.

When it comes to the inputting of data, validation rules can be utilized to ensure that formulaic conditions are met in order to prevent record creation or updates, making users adhere to a specific format when entering correct data. For example, if a lead is being progressed beyond a certain stage, validation rules can be used to ensure that a certain industry field is selected or a valid phone number has been entered (down to the format). Secondly, picklists (predefined lists of values) can be used to limit the values a user can enter against a record. When picklists are used over free-text values, users are restricted (in a good way) to selecting values from managed lists. Reporting and searching are made quicker and easier as a result. There is also the concept of dependent picklists, whereby the values in one picklist are filtered or restricted based on another. This again can be used to direct users to select from specific value sets in order to drive data quality. Those value sets can be shared across multiple picklists to ensure consistency in the values chosen (as the underlying values are shared and managed centrally).