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.

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:

Create a custom object with fields
Create apex sharing reason
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
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.

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:
1. 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:
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
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:
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
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
1. Row 1
  1. Field: Audit__c | Auditor__c
  2. Operator: Is null
  3. Type: Boolean
  4. Value: False
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:
1. Row 1:
  1. Flow Variable: varRAudit
  2. Type: Field Reference
  3. Value: Select the Audit__c record that started your process
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

Automation Champion

Tag: Sharing a Record Using Process Builder

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

Posted at 12:12 AM by Rakesh Gupta, on April 7, 2015

Big Idea or Enduring Question:

Objectives:

Business Use Case

Automation Champion Approach (I-do):

Guided Practice (We-do):

Step 1: Create a Custom Object Audit and Fields

Step 2: Create Apex Sharing Reason

Step 3.1: Lightning Flow – Define Flow Properties

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

Step 3.3: Lightning Flow – Create Records – Share the Record with Auditor

Step 4.1: Define Process Properties

Step 4.2: Define Evaluation Criteria

Step 4.3: Define Process Criteria

Step 4.4: Add Action – Flows

Proof of Concept

Independent Practice (You-do):

Formative Assessment:

Search

Upcoming Trainings

Sponsor #1

Sponsor #2

Sponsor #3

Sponsor #4

Sponsor #5

Buy My Book

Buy My Book

Buy My Book

Recent Posts

Salesforce ID Converter Build on Lightning Flow

Blog Archives

Categories

Information

Top Posts

Social Media