Salesforce allows you to control access to data at many different levels i.e. object-level, the record-level and the field-level. Here we will focus on methods for controlling access to data at the record-level. In the most of the scenario you can use Out-of-box sharing settings to grant record access, but there are few use cases where you have to write an Apex Managed Sharing to share the records with users or groups. Apex Managed Sharing allows you to use Apex Code to build sophisticated and dynamic sharing settings that aren’t otherwise possible. In this article I will show you how can use Flow and Process Builder to solve these requirements instead of using Apex code. Let’s start with a business use case
Business Use case
Warren Mason is working as System administrator at Universal Containers (UC). Currently he is working on a project that is implementing an audit management for Assets. For this he has created a custom object Audit (OWD: – private) and few custom fields as Shown in the following screenshot:
Audit Custom Object
Now business requirement is as soon as Auditor__c (Lookup of User object) field gets populated then auto share the audit record (Grant edit access) with the auditor.
Solution for the above business requirement
There are few solutions possible for the above business scenario. We will use Flow and Process Builder to solve the above business requirement. Before proceeding you have to understand the sharing table in Salesforce. All objects that have a default sharing setting of the either “Private” or “Public Read Only” also have a related “Share” object that is similar to an access control list (ACL) found on other platforms. All share objects for custom objects are named as CustomObject__Share, where CustomObject__c is the name of the related custom object. A share object includes records supporting all three types of sharing i.e. Force.com managed sharing, user managed sharing, and Apex managed sharing. Share object contains few fields those are following
A. ParentId: – The Id of the record being shared. This field cannot be updated.
B. UserOrGroupId: – The Id of the User to whom you are granting access.
C. AccessLevel: – The level of access that the specified User or Group has been granted.
D. RowCause (aka Sharing Reasons): – The reason why the user or group is being granted access.
First of all, we will create an Apex Sharing Reasons. Each Apex sharing reason has a Label and a Name. The Label value is displayed in the Reason column when viewing the sharing for a record in the user interface. This allows users and administrators to understand the source of the sharing. Follow the below instructions to create a Flow and Process Builder to solve the above business requirement
1. To create Apex Sharing Reasons click on Setup | Build | create | Objects | Audit then navigate to Apex Sharing Reasons related list and click on the New button
Apex Sharing Reasons
You can enter any words or phrase for Apex Sharing Reasons. The next step is to create a Flow.
2. Click on Setup | Build | create | Workflows & Approvals | Flows
3. Click on New Flow, it will open the Flow Canvas for you. Create two text variables VarT_AuditId and VarT_AuditorId as Shown in the following screenshot
Text Variables
4. The next step is to create a record on the Audit_Share object to share the record with the auditor at the run time. For this drag-and-drop Record Create Element (Give the name Share audit record with Auditor) on the Flow Canvas and fill the details as shown in the following screenshot
Record Create – Create an Audit_Share record
Once you are done click on OK. Finally, your Flow will look like the following screenshot, click on icon that mark in red to set as start point
5. Save your flow with name Share record with auditor and close the canvas. Don’t forget to Activate the Flow.
Launch a Flow from Process Builder
Our next task is to create a Process on Audit object to launch a Flow. To create a Process on the Audit object follow the below instructions
1. Click on Name | Setup | App Setup | Create | Workflows & Approvals | Process Builder and click on the New button, Enter Name, API Name and click on the Save button
2. Click on Add Object, select Audit object and for the entry criteria, Select when a record is created or edited, as shown in the below screenshot and also click on the Save button
Evaluation Criteria
3. The next task is to add Process Criteria, To do this click on Add Criteria, enter Name, Type of action and set filter conditions (In this case set [Audit__c].Auditor__c Is null False) and click on the Save button, as shown in the following screenshot
Process Criteria
4. Our final task is to add Immediate action to Process. Click on Add Action (Under Immediate actions), Select the type of action to create (In our case Flows), and then fill out the fields to define the action, as shown in the following screenshot
Add action – Flows
5. Once you are done, click on the Save button, it will redirect you to Process canvas. Finally, the Process will look like the following screenshot
Don’t forget to active the Process by clicking on the Activate button
It’s time to test this App
Now onwards if a business user creates an audit record with auditor then Process Builder will automatically trigger and Launch the Flow then it will share the audit record with the auditor.
1. Currently audit “Dell PowerEdge Tower Servers” doesn’t have an auditor, as shown in the following screenshot
Audit record before update
2. Now update the audit record with valid auditor, as shown in the following screenshot
Audit record after update
3. To verify the outcome click on the sharing button available on the record detail page and check out the sharing detail as shown in the following screenshot
Note: – I will suggest you to implement this first on your developer org test it and then move it to Production.
