How to restrict sensitive objects in Salesforce and share them with limited users – Manoj

As a Salesforce admin or sales operation team member, it is always a worry that contracts will be exposed to wrong users leading to a lot of risks and answer compliance questions. Every year you are faced with a barrage of questions from the audit teams on how secure is our sensitive objects? We know we have the right security in place but there is an add-on fear of what there is some back door we had created in Salesforce for our users? So the question is how do we ensure all contracts are still visible to the leadership and still hidden from most of the users? Here is my solution that can solve the problem with a 3 step approach.

1.Set the foundation straight using OWD.

2. Identify the users who need access.

3.Create an automation that will provide access to the users upon contract record creation or update using a point and click solution.

Set the foundation straight using OWD.

Start with the foundation on organization-wide defaults and ensure that your sensitive data is marked as private. See an example of a custom object below with the right setting.

Make the Custom object private which is shown in the above screenshot and ensure that the grant access using hierarchies is checked for allowing leaders to view the record.

Identify the users who need access

Once you have made the object hidden with OWD, you can now identify the users who need access to the sensitive object. If the users who need access is a manager, you can use the manager field in the user object as a starting list. If there is a need for external users, create a public group say Contract access and add the users to it. Then, Create Apex Sharing Reason Under NDA Contract Custom Object. Under Salesforce Classic experience, Navigate to set up || Objects || NDA Contract || Scroll down to Apex Sharing Reason and Click New Button to define an Apex sharing as below

The final solution is a flow that will be fired from a process builder which will query all these users and insert into the share object records automatically. To make that happen, you will need to create an Apex sharing reason and the above screenshot explains it.

Create an automation that will provide access to the users upon contract record creation or update using a point and click solution.

Create a Lightning (Auto Launched) Flow that will Create Record share for the user’s Manager. Navigate to set up || Flows || Click New Flow – Use Free Form Template for Flow creation. Lightning Flow for record share creation is as below:

Note: Here the value assigned to RowCause is the Apex Sharing Reason we created earlier. || User or Group ID refers to a User who needs access to the Contract. In our case it is, Contract record owners Manager || ParentId is the NDA Contract Record id AND, VarRContract is the Flow Variable created to link with NDA Contract Record.

  1. Once Flow is created, the Next step is to create a Process Builder that will Auto Launch the Flow upon Contract Record creation. Process Builder will look like the below screenshot.

Here Manager Check indicates a check on the User’s manager as NOT NULL, AND Immediate action refers to the Flow we created in the previous step. In a scenario where you would need to provide access to a group of users, you can leverage the public group id and assign it to the NDA object share records.

Will our solution work for future changes?

In a scenario where your manager of the user changes, the new records will still have the new manager field on them and will work. Existing records will need a one-time data load to update old contracts share records with the new manager to provide access.

If the owner is changed on the NDA sensitive object, how will this work?changes of the contract -> This will work with existing solution with a slight tweak in the process builder evaluation criteria. Implies, apart from the Manager “Not Null” check, we can also add a condition to consider a change of Contract Record Owner. This will ensure process builder triggers the flow for change in Contract ownership.

So here are the 3 action steps you can take now to make sure your sensitive objects are hidden and provided the right access.

  1. Start with OWD to make it private
  2. Identify the list of users who need access and create groups if needed
  3. Leverage process buider/flow to automate user access.

As always feel free to post any questions below for Manoj or email me at buyan@eigenx.com for further questions.

Please Subscribe

Subscribe to our mailing list to get tips on maximizing your salesforce

We respect your privacy.

Please subscribe

Subscribe to our mailing list and get tips to maximize salesforce to your email inbox.

I am honored to have your subscription. Stay tuned for tips to maximize your salesforce investment

Something went wrong.

Share:
Manoj Nambirajan

Author: Manoj Nambirajan

An IT Leader handling Salesforce Enterprise Architecture responsibility with 14 years of Salesforce experience. Experienced Senior Consultant with a demonstrated history of working in the information technology and services industry. Salesforce Certified Application Architect Skilled in Software as a Service (SaaS), Business Intelligence, Solution Architecture, and Agile Methodologies. A strong consulting professional who strives to provide the best and smart possible approach towards business problems. Author @manojn2sf.blogspot.com || Senior Consultant, IT Architecture at Dell Technologies || Salesforce Certified Application Architect with 11x certifications and 2X Trailhead Ranger (6 super badges)

0 thoughts on “How to restrict sensitive objects in Salesforce and share them with limited users – Manoj

Leave a Reply

Your email address will not be published. Required fields are marked *