Getting Started with Process Builder – Part 16 (Creating Custom Record Sharing Logic)

Getting Started with Process Builder – Part 16 (Creating Custom Record Sharing Logic)

Last Updated on November 30, 2020 by Rakesh Gupta

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: Part 16.1 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.

Let’s begin building this automation process.

Guided Practice (We-do):

There are 4 steps to solve Brenda’s business requirement using Flow and Process Builder. We must: 

  1. Create a custom object with fields
  2. Create apex sharing reason 
  3. Lightning Flow Steps:
    1. Define flow properties for auto-launched flow
    2. Add a record variable to store an audit record data
    3. Add a create records element  – share the record with the auditor 
  4. Process Builder Steps:
    1. Define process properties
    2. Define evaluation criteria
    3. Define process criteria
    4. Add action – flows 

Step 1: Create a Custom Object Audit and Fields 

    1. Click Setup.
    2. In the Object Manager, click Create | Custom Object.
    3. Now create a custom object Audit and fields as shown in the screenshot below: 
    4. Click Save.

Part 16.1

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. 

  1. Click Setup.
  2. In the Object Manager, type Audit.
  3. Select Apex Sharing Reasons, then click New.
  4. Enter Reason Label and press the Tab key the Reason Name will populate. 
  5. Click Save.

Step 3.1: Lightning Flow – Define Flow Properties 

  1. Click Setup.
  2. In the Quick Find box, type Flows.
  3. Select Flows then click on the New Flow.
  4. Select the Autolaunched Flow (No Trigger) option and click on Next and configure the flow as follows: 
    1. How do you want to start building: Freeform
  5. Click Done.

Step 3.2: Lightning Flow – Add Record Variable to Store Audit Record

  1. Under Toolbox, select Manager, then click New Resource to pass the Audit Id.
  2. Input the following information: 
    1. Resource Type: Variable
    2. API Name: varRAudit
    3. Data Type: Record
    4. Object: Audit
    5. Check Available for Input
    6. Check Available for Output
  3. 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.

  1. Under Toolbox, select Elements. Drag and drop Create Records onto the canvas. 
  2. Input the following information:
    1. Enter Label the API Name will auto-populate.
    2. How Many Records to Create: One
    3. How to Set the Record Fields: Use separate resources, and literal values
    4. Object: Share: Audit
    5. Set Field Values for the Share: Audit
    6. Row 1:
      1. Field: AccessLevel
      2. Value: Edit
    7. Click Add Row
    8. Row 2:
      1. Field: ParentId
      2. Value: {!varRAudit.Id}
    9. Click Add Row
    10. Row 3:
      1. Field: UserOrGroupId
      2. Value: {!varRAudit.Auditor__c}
    11. Click Add Row
    12. Row 4:
      1. Field: RowCause
      2. Value: Share_record_with_Auditor__c
  3. Click Done.

In the end, Brenda’s Flow will look like the following screenshot:

Once everything looks good, perform the steps below: 

  1. Click Save.
  2. Enter Flow Label the API Name will auto-populate.
  3. Click Show Advanced.
  4. API Version for Running the Flow: 50
  5. Interview Label: Share record with Auditor {!$Flow.CurrentDateTime}
  6. 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

  1. Click Setup.
  2. In the Quick Find box, type Process Builder.
  3. Select Process Builder, then click New.
  4. Name the Process and click the Tab button. The API Name will populate. 
  5. As a best practice, always input a description
  6. The process starts when A record changes.
  7. Click Save.

Part 16.5

Step 4.2: Define Evaluation Criteria

  1. Click on the Add Object node to begin selecting the evaluation criteria.
  2. Select the Audit object from the dropdown list.
  3. Start the process when a record is created or edited.
  4. Click Save.

Part 16.6

Step 4.3: Define Process Criteria

  1. Click the Add Criteria node to begin defining the process criteria.
  2. Name the criteria.
  3. The criteria should execute actions when the conditions are met.
  4. Set Conditions
    1. Row 1
      1. Field: Audit__c | Auditor__c
      2. Operator: Is null
      3. Type: Boolean
      4. Value: False
  5. Select All of the conditions are met (AND)
  6. Click Advanced
  7. Select Yes to execute the actions only when specified changes are made to the record.
  8. Click Save.

Part 16.7

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

  1. Below Immediate Actions, click Add Action.
  2. For Action Type, select Flows
  3. Name the action.
  4. Select the flow we just createdShare record with Auditor.
  5. Set Flow Variables: 
    1. Row 1:
      1. Flow Variable: varRAudit
      2. Type: Field Reference
      3. Value: Select the Audit__c record that started your process
  6. Click Save.

In the end, Brenda’s Process will look like the following screenshot:

Part 16.8

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.

  1. Currently, the audit for Dell PowerEdge Tower Servers doesn’t have an auditor, as shown in the following screenshot:
  2. Now update the audit record with the valid auditor:
  3.  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:

Final Outcome

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

Have feedback, suggestions for posts, or need more information about Salesforce online training offered by me? Say hello, and leave a message!

16 thoughts on “Getting Started with Process Builder – Part 16 (Creating Custom Record Sharing Logic)

  1. 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

    1. @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.

  2. 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!

      1. 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.

  3. 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!

  4. 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 ?

  5. 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

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.