Last Updated on June 1, 2022 by Rakesh Gupta
👉 To understand how to solve the same business use case using Salesforce Flow. Check out this article Getting Started with Salesforce Flow – Part 70 (Creating Custom Record Sharing Logic).
Big Idea or Enduring Question:
- Sharing records automatically without sharing rules or role hierarchy
- Using Apex Managed Sharing declaratively
Objectives:
After reading this blog post, the reader will be able to:
- Create declarative automation to automatically share a record
- Share a record without sharing rules or role hierarchy
- Start a Flow from a Process Builder
Business Use Case
Brenda David is working as a System administrator at Universal Containers (UC). Currently, she is working on a project that is implementing audit management for Assets. For this she has created a custom object Audit (OWD: – private) and few custom fields as shown in the following screenshot: The business requirement:
- as soon as Auditor__c (Lookup to User object) field gets populated, auto-share the Audit record (Grant edit access) with the auditor.
Automation Champion Approach (I-do):
Salesforce allows you to control data access at many different levels (object-level, record-level, and field-level). We will focus on methods for controlling access to data at the record level.
In most scenarios, you can use out-of-the-box sharing settings to grant record access, but there are few use cases where you have to write an Apex Managed Sharing rule 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, we will show how to use Lightning Flow and Process Builder to solve these requirements instead of using Apex.
Before proceeding, make sure you understand the sharing table in Salesforce. All objects that have a default sharing setting of either Private or Public Read Only. These objects 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 shared object includes records supporting all three types of sharing (Force.com managed sharing, User managed sharing, and Apex managed sharing).
The Share object contains the following fields:
- ParentId: – The Id of the record being shared. This field cannot be updated.
- UserOrGroupId: – The Id of the User to whom you are granting access.
- AccessLevel: – The level of access that the specified User or Group has been granted.
- RowCause (aka Sharing Reasons): – The reason why the user or group is being granted access.
Before discussing it, let me show you a diagram of a Process Flow at a high level. Please spend a few minutes to go through the following Flow diagram and understand it.
Guided Practice (We-do):
There are 4 steps to solve Brenda’s business requirement using Flow and Process Builder. We must:
- Create a custom object with fields
- Create apex sharing reason
- Lightning Flow Steps:
- Define flow properties for auto-launched flow
- Add a record variable to store an audit record data
- Add a create records element – share the record with the auditor
- Process Builder Steps:
- Define process properties
- Define evaluation criteria
- Define process criteria
- Add action – flows
Step 1: Create a Custom Object Audit and Fields
-
- Click Setup.
- In the Object Manager, click Create | Custom Object.
- Now create a custom object Audit and fields as shown in the screenshot below:
- Click Save.
Step 2: Create Apex Sharing Reason
First, we will create an Apex Sharing Reason. 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.
- Click Setup.
- In the Object Manager, type Audit.
- Select Apex Sharing Reasons, then click New.
- Enter Reason Label and press the Tab key the Reason Name will populate.
- Click Save.
Step 3.1: Lightning Flow – Define Flow Properties
- Click Setup.
- In the Quick Find box, type Flows.
- Select Flows then click on the New Flow.
- Select the Autolaunched Flow (No Trigger) option and click on Next and configure the flow as follows:
- How do you want to start building: Freeform
- Click Done.
Step 3.2: Lightning Flow – Add Record Variable to Store Audit Record
- Under Toolbox, select Manager, then click New Resource to pass the Audit Id.
- Input the following information:
- Resource Type: Variable
- API Name: varRAudit
- Data Type: Record
- Object: Audit
- Check Available for Input
- Check Available for Output
- Click Done.
Step 3.3: Lightning Flow – Create Records – Share the Record with Auditor
The next step is to create a record on the Audit_Share object to share the record with the auditor at the run time.
- Under Toolbox, select Elements. Drag and drop Create Records onto the canvas.
- Input the following information:
- Enter Label the API Name will auto-populate.
- How Many Records to Create: One
- How to Set the Record Fields: Use separate resources, and literal values
- Object: Share: Audit
- Set Field Values for the Share: Audit
- Row 1:
- Field: AccessLevel
- Value: Edit
- Click Add Row
- Row 2:
- Field: ParentId
- Value: {!varRAudit.Id}
- Click Add Row
- Row 3:
- Field: UserOrGroupId
- Value: {!varRAudit.Auditor__c}
- Click Add Row
- Row 4:
- Field: RowCause
- Value: Share_record_with_Auditor__c
- Click Done.
In the end, Brenda’s Flow will look like the following screenshot:
Once everything looks good, perform the steps below:
- Click Save.
- Enter Flow Label the API Name will auto-populate.
- Click Show Advanced.
- API Version for Running the Flow: 50
- Interview Label: Share record with Auditor {!$Flow.CurrentDateTime}
- Click Save.
Almost there! Once everything looks good, click the Activate button. Our next task is to create a Process Builder on the Audit object to start a Flow.
Step 4.1: Define Process Properties
- Click Setup.
- In the Quick Find box, type Process Builder.
- Select Process Builder, then click New.
- Name the Process and click the Tab button. The API Name will populate.
- As a best practice, always input a description.
- The process starts when A record changes.
- Click Save.
Step 4.2: Define Evaluation Criteria
- Click on the Add Object node to begin selecting the evaluation criteria.
- Select the Audit object from the dropdown list.
- Start the process when a record is created or edited.
- Click Save.
Step 4.3: Define Process Criteria
- Click the Add Criteria node to begin defining the process criteria.
- Name the criteria.
- The criteria should execute actions when the conditions are met.
- Set Conditions
- Row 1
- Field: Audit__c | Auditor__c
- Operator: Is null
- Type: Boolean
- Value: False
- Row 1
- Select All of the conditions are met (AND).
- Click Advanced.
- Select Yes to execute the actions only when specified changes are made to the record.
- Click Save.
The reason why we would select the Yes checkbox for the question — Do you want to execute the actions only when specified changes are made to the record? — is to allow the Process Builder to execute the actions only if the record meets the criteria now, but the values that the record had immediately before it was saved didn’t meet the criteria. This means that these actions won’t be executed when irrelevant changes are made.
Step 4.4: Add Action – Flows
- Below Immediate Actions, click Add Action.
- For Action Type, select Flows.
- Name the action.
- Select the flow we just created – Share record with Auditor.
- Set Flow Variables:
- Row 1:
- Flow Variable: varRAudit
- Type: Field Reference
- Value: Select the Audit__c record that started your process
- Row 1:
- Click Save.
In the end, Brenda’s Process will look like the following screenshot:
Almost there! Once everything looks good, click the Activate button.
Proof of Concept
Now onwards, When a business user creates an audit record with an Auditor, then Process Builder will automatically trigger and launch the Flow which will share the audit record with the auditor. You will have to do some of this testing in Classic.
- Currently, the audit for Dell PowerEdge Tower Servers doesn’t have an auditor, as shown in the following screenshot:
- Now update the audit record with the valid auditor:
- To verify the outcome, navigate to Classic click on the sharing button available on the record detail page, and check out the sharing detail as shown in the following screenshot:
Independent Practice (You-do):
- In a sandbox or dev/Trailhead org, create a quick custom object with a look-up to the Opportunity record
- Include a User look-up
- Create a sharing rule as outlined above
Formative Assessment:
Identify a custom object in your org that should be shared based on the settings in a related object and create an autolaunched flow that will share the records without actual manual sharing
Post a picture of the sharing on Twitter @automationchamp, #AutomatedSharingwithFlow
Hi Rakesh,
I have a question related to a requirement similar to this topic, hope you can help me.
We have a record that involves 3-5 people to work. We use 1 field named “Assigned to” (relate to User object) for this purpose.
Once the field is populated or changed, we need to share record to new user in that field. My manager also want the flow be triggered only when relevant changes are made.
How can I setup the criteria in process builder to meet this requirement?
Hope you can help.
Thanks
@Johnny – You can easily achieve it by tweaking the Lightning FLow and Process Builder a bit.
1. Make sure to select “Do you want to execute the actions only when specified changes are made to the record?” checkbox while defining the process builder criteria node, so that it will only fire when user lookup field is changed.
2. In the Flow you have to add condition/check, like this – if any user has record access where “Apex Sharing Reasons” is the same as the one you have created in the past, then go ahead and delete it.
3. In the end, add one record action to share the record with the new user.
Thanks for sharing this tutorial. I want to implement this with communities, Auditor__c (Lookup of User object) works only for internal users. Is there a way this can be done for Partner users_?
Thanks!
It will work for both internal and communities. Make sure that you have correctly setup OWD for External and Internal Users.
Thanks for your prompt response. I have the settings as follows> http://prntscr.com/gnjv3q
But the Lookup icon only works for internal users.
If you have created a custom Lookup Field (User) then it will allow you to select partner user.
https://automationchampion.com/wp-content/uploads/2017/09/Screen-Shot-2017-09-20-at-12.25.54-PM.png
Thanks.
Probably I’m going off topic right now. Is there a way to identify if a user is a community user and send that information to the contact? I’m kind of new on SF XD.
Yes, using profile, license type or ISPartner=True fields you can easily identify community user
When you create a portal user is coming from a contact. How can I related a Contact with the User? using $User.ProfileId ?
That’s true, the portal user is coming from a Contact, and at that time ContactId on user object is automatically populated. See this https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_objects_user.htm
Use this field to identify if a user is Partner user or internal user.
This is SUPER helpful for custom objects, but does it work for standard objects? I need to share an opportunioty based on a custom usier field on the Opportunity. The user field (and any other lookup field) is not available in the Opportunity Sharing Rule interface, so I was going to use this method to share it instead, but there is no Apex Sharing Reason option on the opportunity. So …. what are my options? Will creating a formula field on the opp make it possible to set the sharing rule using the standard sharing rule interface?
TIA!
Glad to hear it, Rebecca!.
Yes, this solution will work for almost all standard and custom objects. You have two options, either select manual, something else for (Row Cause) or leave it blank.
https://automationchampion.com/wp-content/uploads/2017/06/Screen-Shot-2017-06-25-at-3.07.16-PM.png
Nice Tutorial!
I have one doubt, suppose user A is an auditor for the audit records, so he can access the records according to the logic, but suppose admin update the auditor field from user A to user B, so my question is still user A will be able to access those records for which he was the auditor?
If yes then how can we restrict his access ?
In that case, you have to write logic to remove user A from Sharing table.
Hi Rakesh
Thanks for this post on Flows and Process builder to share records.
One quick question – I’ve a requirement at my org it is that I should share a record which has multiple user details in under one record and which is divided into 10 different departments each one having 3 empty text boxes(10 x 3 = 30 columns) for the record creator to fill in the user details and its SObject is a custom object and its sharing is set to private.
So whenever the owner creates a record and inputs the user name in the allotted text boxes of a particular department I want that record details to be shared with creator and user whose name has been filled in the record. This requirement I was able to do via apex code but now I need it to do it via Flows and Process Builder which I’m not able to achieve bcoz i get this error when ever I try to save a record “Workflow Action Failed to Trigger Flow
The record couldn’t be saved because it failed to trigger a flow. A flow trigger failed to execute the flow with version ID 301O000000058na. Contact your administrator for help.” I’m trying to input certain inputs for a particular out of the ten say for example I give inputs for HR dept alone and keeping the rest null but the process builder doesn’t accepts it and throws the above error. Please help me on this.
Thanks in advance
Can you please post the detail screenshot of Flow, Process and Test record ?