What You Don’t Know About Salesforce Data Security
Estimated reading time: 5 minutes
Salesforce® data security… Who hasn’t pondered that while in the midst of a new implementation or ongoing usage, especially as there is not one sole document that will explain all of the intricacies of how Salesforce establishes data security.
In truth, security for any Object in Salesforce, not just Cases, entails the configuration of several different facets of the application. And much like an Etch A Sketch, you have to turn a number of knobs before you get the full picture.
In an effort to help you safeguard your Salesforce data, AdVic’s consultants – who work every day in the Salesforce ecosystem to help our clients secure their data – have compiled a list of seven things that users should be aware of within their Salesforce Org to ensure maximum data security.
1. Sharing Settings
The baseline security model for your data, from the perspective of which records both an internal and external user can see, starts with your Organization-Wide Defaults. The best practice is to set as many of the Objects (Cases, Contacts, Accounts, Opportunities, etc.) with a Private sharing model. In a Private sharing model, only the owner of a record can view that record. From there, you can open up visibility to records outside of ownership with Sharing Rules. Sharing Rules can open up visibility of records by either owner or criteria to Roles, Public Groups, or Queues.
2. Role Hierarchy
A role hierarchy works together with sharing settings to determine the levels of access users have to your Salesforce data. Users can access the data of all the users directly below them in the hierarchy. Roles can be used many ways, but mostly used in a way that mimics a company’s own role structure.
Remember, in a private sharing model, only record owners can see their records but from a case management perspective you want a Customer Support Manager to be able to see all the cases that are owned by those he or she manages. In that case you might create a role for Support Manager, which would be assigned to Support Managers and another role for Support Rep, which would roll-up under the Support Manager. Using Role Hierarchy will share the records owned by those in the Support Rep role with the Support Manager but wouldn’t share records across the Support Reps. That’s where Sharing Rules come into play.
3. Profiles
Profiles define how users access objects and data, and what they can do within the application. When you create users, you assign a profile to each one. While Sharing Settings determine which records you can access, Profiles determine whether you can even access that Object, what you can do with that Object (Read, Create, Edit or Delete), and what data you can see when you access a record, which is determined by Field Level Security
4. Record Types
Record types let you offer different business processes, picklist values, and page layouts to different users. Each Object in Salesforce, like Cases, can have varying Record Types. In your org, you can create a unique Record Type for Cases that are created as the result of a Form being submitted in your Community. Having a separate record type allows you to assign a unique Page Layout and have a unique Support Process for Forms cases that doesn’t affect the existing process for Cases. Record types can be assigned to specific Profiles so that only certain Profiles can create or access cases of a certain Type.
5. Page Layouts
Page layouts control the layout and organization of buttons, fields, s-controls, Visualforce, custom links, and related lists on object record pages. They also help determine which fields are visible, read only, and required. You can use page layouts to customize the content of record pages for users.
6. Queues
Queues are used to Prioritize, distribute, and assign records to teams who share workloads. For the Forms project, when a Form is submitted via the Community, it is assigned to a specific Queue. The user members of that Queue are able to access those Case records and assign them to themselves to work and close.
7. Private Communities
If your Salesforce Org is using Experience Cloud to enable users to submit forms and view records, additional settings can be configured to establish data security in addition to the items mentioned above. The first consideration is setting up your Experience Cloud as a private community, meaning only Authenticated users can access it. A Single Sign-On process can be initiated that will authenticate users into Salesforce to access the private community. This process creates a Contact and User record for each Experience user. Those users are assigned a Profile that has been tailored to only provide the right level of access from an Object perspective.
Concerned About Salesforce Data Security?
In summary, a combination of all the functionality mentioned above goes a long way toward determining security as it pertains to Case Management in Salesforce. As a result, groups of internal users can view cases that are directly related to their business function and Experience users can only access the cases they are directly related to.
Remember that as a Salesforce user, you are responsible for the security and integrity of your data, which can be a complex undertaking. If you’re concerned about securing your Salesforce data, reach out to the Ad Victoriam Team, who have experience with all facets of data governance. They’ll quickly diagnose any risks so you keep your eye on the bottom line, and yes, sleep a little better, too.
Related Articles:
Create an Effective Data Strategy
Making Smarter Decisions with 360-Degree Data
