Salesforce Platform Best Practices: Data Management, Sharing & Security
The global shift to move toward digitalization in every business vertical/sector has created a massive requirement for secure, cost-effective, cloud-based solutions that help companies to adapt to the new world and also run their businesses smoothly and efficiently. As a result, the customer relationship management (CRM) market has grown from 2020 at $52.64 billion to $58.04 billion in 2021 and is expected to grow from $128.97 billion from 2021 to 2028.
Salesforce: The Trendsetter
Salesforce is the most significant single player in CRM applications holding 19.8% of the market share. With the acquisition of Slack, MuleSoft, Tableau, and many more over the past several years, Salesforce provides an ecosystem for companies to have the complete customer journey with data analytics and integration with other systems to leverage various features under a single platform.
In 2021, Salesforce served over 150,000 customers and generated $21.25 billion in revenue. Revenue has grown at a CAGR of 51% over the last 20 years, and in the previous 10 years, compound annual revenue growth is 29%.
Importance of Data Management, Security, & Privacy
Companies now have access to more data than ever before with the help of various tools and technology, which helps businesses create the basis for intelligence for essential business decisions. With this vast data also comes the responsibility to:
- Data Management: Manage the information efficiently to be used effectively.
- Data Security: Security breaches and hacking have been a significant concern due to extra connectivity and modern technology, making it even more critical for companies to put additional measures for data security.
- Data Privacy: Due to the availability of sensitive data floating on the internet, it’s essential to keep customers’ data privacy intact from any malicious attacks.
Salesforce Manages Data, Security, & Privacy
Salesforce works in a multi-tenant architecture where the resources are shared among the users with complete privacy and security. Salesforce provides a comprehensive and flexible data security model to secure data at different levels. It provides sharing tools to give or restrict access to data as per the business needs. To protect your system from unauthenticated access, Salesforce strongly recommends using the following solutions:
- Multi-Factor Authentication (MFA): This secure authentication method requires users to provide identity verification by supplying two or more pieces of evidence (or factors) when they try to log in. Only when all the elements are authenticated can the user log in, which is unique to each user.
- Single Sign-On (SSO): This authentication method allows users to log in to multiple applications with a single credential. For example, if users log in to Salesforce org and access other apps, they can access them directly from the app launcher.
Device & Session-Based Security
- Device Activation: Whenever a user tries to access the Salesforce platform from different devices or an unrecognized browser or IP address outside of the trusted range, Salesforce enforces them to verify themselves.
- Session Security: When a user logs in, a session is created. It can be controlled when an inactive user session expires, set trusted user IP address range, and restrict access to resources based on the session security.
Data Access & Permission-Based Security
Salesforce manages data-level security by providing control over who sees what. As an admin, you can set up different permission levels for each user and management to access which data. Salesforce lets the system admin expose specific data sets to individuals and groups of users. Permission sets, groups, and profiles provide object-level and field-level security by controlling access. Record-level sharing settings, user roles, and sharing rules control the individual records that users can view and edit. Here are various permissions that control data security:
- Object-Level Security & Profiles: You can provide object-level protection per each profile you create to assign different users according to their roles and responsibilities. It’s the most straightforward way to give or block access to a specific data set.
- Field-Level Security & Profiles: Even if you have given access to an object, you can still control what level of access the user can have to the thing. The admin can manage to read, write, and edit an entry on each object.
- Record-Level Security: Once the object and field level security is set up, one can provide the record level security so that users can have access to each other data or just their own.
- Organization-Wide Level Sharing: If you want all records visible to all the users as per their object-level access, then you can provide access to the public, but if you wish only the owner to have access, then you can give private access.
- Role-Hierarchy Sharing: This is a way to give broader access to the user’s role. You can also provide hierarchy-based access; anyone above the hierarchy will have the same access as the record owner.
Shield Platform Encryption:
One can also protect data by shield platform encryption that does the following:
- Gives data a new layer of security without impacting the functionalities. It enables you to encrypt sensitive data at the platform level and not just while you’re transmitting over a network. It helps companies comply with privacy policy, regulatory requirements, and contractual obligations.
- Helps you to encrypt specific fields in standard and custom objects.
- Encrypts the files and attachments using an advanced HSM-based key derivation system.
Salesforce Monitoring & Auditing:
- You can monitor the login history of all your users and determine what method they used to log in. It could be MFA or SSO, depending on the configuration.
- You can select specific fields to do field history tracking. It’ll record the date, time, and who made the change to a particular field. Salesforce saves up to 18 months of tracking data and 24 months through API.
- The field audit trail lets you define a policy to retain archived field history data up to 10 years from when the data was archived. This feature helps you comply with industry regulations related to audit capability and data retention.
Salesforce & Data Sharing Scenarios
When it comes to data, sharing data is a challenge that many organizations have. Providing access to detailed data to the users who aren’t owners of those records and are restricted by org-wide settings is always a challenge that needs resolutions.
This can be resolved by leveraging the power of Salesforce sharing rules, which are used to extend sharing access to groups, roles, or individuals, an automatic exception to the org-wide sharing settings. You can set the sharing location on records based on different types and rules, then provide desired access to individuals or groups.
Types of Data Sharing Rules
- Owner-Based Sharing Rule: An owner-based sharing rule opens access to records owned by users. Owner-based sharing rules allow for exceptions to organization-wide default settings and the role hierarchy that give the other user access to records they don’t hold. For example, the sales manager of the west coast wants to see the sales of the east coast, but due to hierarchy restrictions, he cannot access the data directly. A sharing rule can be set to resolve this issue, and the records can be shared in read mode.
- Criteria-Based Sharing Rules: Criteria-based sharing rules provide access to records based on the criteria applied to the field values. If one or many criteria are met, documents are shared with an individual user or a group of users.
- Guest User Sharing Rules: A special sharing rule where an unauthenticated user is granted access to records by using sharing settings. By this, one can access it without login credentials. They’re seldom used since exposing the data to an unauthenticated user is risky and not recommended.
- Manual Sharing: This refers to manually sharing other user records, which they don’t have access to, such as accounts, contacts, and leads. When the user manually shares a paper with associated documents, those records also get shared, like if the user transmits an account record, then associated opportunity and cases. If the ownership of the shared history is changed, then all sharing done by the original owner will be deleted, and users will lose access.
- Apex Managed Sharing: This allows developers to share records programmatically through apex code. It can only be used when OWD is set as private or public read-only. You can use the apex code to resolve the problem when you cannot convey a history by sharing rules. For example, if a complex calculation is needed and you need to share the records, one can fix this problem by sharing the apex.
Limitations of Sharing Rules
- Owner-based sharing rules have a limit of 300 rules. An organization can have a maximum of 300 rules. Criteria-based powers are limited to 50 per organization.
- Organization-wide defaults must be public read-only, or private to create sharing rules.
- We cannot set up sharing rules for an object where a parent controls the OWD setting; it needs to change into either private, public read-only, or public read/writes.
Workarounds with Sharing Limitations
- Limits can be extended by contacting Salesforce.
- Custom solutions can be built to extend the limit beyond the org limits.
- Developers can build custom screens or apps which admins can access to provide extended settings if the above limits are consumed.
- Apex-managed sharing helps in granting and managing complex sharing settings.
SoftClouds Innovation: An Implementation Scenario
Let’s review and understand a scenario and a possible solution that was implemented. The case object has a limit of 50 criteria sharing rules, but customers have requirements for more than 50 sharing rules. The solution was to build a custom solution using apex-managed sharing, that gives our customers the flexibility to create custom sharing settings on top of the limit provided by standard-sharing settings.
Innovative Implementation:
Create Custom-Sharing Setting:
- Build a custom object to hold the custom-sharing settings.
- Build a custom UI solution that helps customers build the criteria-based sharing settings, which should have minimum mandatory fields as shown in the sample wireframe below for easy understanding.
- Use the standard/custom object dropdown to select the desired object.
- Use the field’s dropdown to select the area where you want to build the sharing setting.
- Use the operations dropdown to select the appropriate process to build the criteria, for example, Status = Closed.
- Value to match with the field value. Make sure to enter the numeric value number field and text for text.
- Use the connector dropdown to select and define all conditions that should satisfy one of them.
- Add a row button to add as many conditions as required.
- Use the delete button to delete any row which isn’t needed.
- Generate the filter logic button that will build the criteria.
- An editable text box shows the final bars made using the fields, operators, and values.
- Dropdown to select groups or individuals
- Dropdown to select the access level with values (read, edit).
- Click the save button.
- Show the custom-sharing settings under the new tab created for custom sharing configurations.
The record can look like the one below.
- Once the sharing setting is captured, a batch job runs in the background, which processes all the records and inserts them into CaseShare, which matches the criteria and share the documents with relevant group or individuals.
- Batch execution can be scheduled in apex batches for full data/incremental/deletes
- Batch will be executed on short schedules for only incremental data (newly created and updated records); this helps process a small number of documents and improves performance and accuracy.
- A batch of complete data can be executed once or twice a day, depending on the number of records.
Delete Sharing Setting:
- One can delete sharing setting from the new tab created for custom sharing configurations.
- Once the user deletes the sharing setting, the batch will pick all the records matching the criteria and deletes them from the CaseShare object on the Case ID and the Group ID.
Some Notes:
- Before creating any custom sharing setting, verify that it already doesn’t exist in the standard sharing settings.
- Performance is directly proportional to the number of records processed by the rules and the number of practices per entity.
Salesforce Best Practices for Data Sharing:
The following are some of our recommended best practices for sharing data in Salesforce:
- Keep the number of ownership-based sharing rules to 100 per object and keep the number of criteria-sharing rules to 50 per object. You can define up to 300 directions for each object, including 50 criteria-based sharing rules.
- Beware of the dangerous permissions of “view all” or “modify all” within the profiles. These permissions, although set up in profile or permissions set where you should be giving object access, yet are providing access to records, refrain from using them. Also, remember that these permissions can be applied to the object level and all data.
- If multiple sharing rules give a user a different level of access to a record, the user gets the most permissive access level.
- Sharing rules automatically grant additional access to related records. For example:
- Opportunity sharing rules give access to the account associated with the shared opportunity.
- Contact and case sharing rules provide the role or group members access to the related account.
- When you delete a sharing rule, the sharing access created by that rule is automatically removed.
Salesforce Data Sharing: Common Pitfalls to Avoid
- Duplicating a standard sharing setting while creating a custom sharing setting
- Assigning multiple permission sets to the same user with contradicting permissions
- Any changes in sharing settings lead to recalculation and take time to process.
Sharing rules are Salesforce mechanisms to extend access to individuals, groups, or territories depending on the requirements. Even with limitations, one can leverage the capabilities of the platform. Salesforce, a powerful platform, supports your needs to extend its capabilities and bypass the specific limitations level through Apex custom solutions.
We should always be mindful of how much customization is needed and required for the best performance and desired outputs which makes it easier to manage and maintain.
My Thoughts:
Data is central to any business and managing data properly is important to the success of the business. A clear and documented data management strategy is very important to drive your business goals. It’s very important to have standard operating procedures and policies for processing and managing your data.
Though Salesforce is a very powerful platform that’s very flexible and capable of your data management, you need to have clear control of your data implementation, needs, and security. It’s very important to evaluate your data management and put some best practices in place. Make sure that you keep your data future-ready and use your data to drive analytical solutions that can transform your business and boost your organization’s productivity.
Click HERE to let us know your comments/opinions or email us at “info@softclouds.com”
This post was written by Nixon James, Director of Salesforce Practice at SoftClouds, Nixon has two decades of experience in innovating, designing, building, and delivering world-class CRM/CX/ DevOps/AI solutions around the globe to meet our clients’ digital transformational needs. Nixon is passionate about our clients’ goals and committed to making their vision a reality and client success his number one priority.
SoftClouds is a recognized leader in CRM/CX transformation with experience in numerous service cloud implementations with pre-configured best practice business processes for multiple verticals/domains.
To learn more about this topic, please click here.