How To

Reference Prior Value in a Before/After Update Record Triggered Flows

Comparison

One of the long awaited flow features is coming in Spring ’21 — the ability to use prior value in before or after update record triggered flows. This brings us closer to be migrating our processes into flows as Flow Builder is the end state declarative automation tool.

In a record triggered flow, you can access a record’s prior value using the global variable, $Record__Prior.

PriorValue

Business Use Case:  Addison Dogster is the system administrator at Universal Containers. Katrina Jones is the Operations Manager and she would like to track when the opportunity amount changes in the opportunity description field.

Solution: While in the past, Addison would’ve selected process builder as her declarative automation tool, as of the Spring ’21 release, Addison can now track whether a field has changed using the record’s prior value or reference a field’s prior value in flow builder in a before or after update record triggered flow.

If your use case is to make changes to the record that triggered the process only, then a before update record triggered flow is the way to go. In a before update flow, you only need the assignment resource to update the values of the record before the record is actually updated in the database. There is no need to use an Update Records flow element.

The before update record triggered flow may look like this:

PriorValue_BeforeSave

View image full screen

This flow will fire when a record is updated before the record is saved on the opportunity object: (1) where a decision is made whether the opportunity amount has changed and (2) if yes, update the the opportunity description to “The opp amount was changed from <the prior amount> to <the updated amount>.”

If you need to make changes to the record that fired the automation and/or other records, then an after update record triggered flow is your automation solution.

The after update record triggered flow may look like this:

PriorValue_AfterSave

View image full screen

This flow will fire when a record is updated after the record is saved on the opportunity object: (1) where a decision is made whether the opportunity amount has changed and (2) if yes, update the the opportunity description to “The opp amount was changed from <the prior amount> to <the updated amount>.” (3) Update the description on the opportunity record and lastly, (4) update the description field on the associated account record to “The opp amount was changed to <the updated amount>.”

In an after update flow, we need the Update Records flow element to update the record that triggered the flow because this automation is happening after the record has already been saved to the database.

Below, we will walk through the steps for an after update record triggered flow.

Highlighted Steps: 

1.Create a custom field (rich text area) on the Opportunity object to store a description. This is done because we need to store a line break and the OOTB description field is a long text area and does not allow us to add line breaks. Since we are also calling this field Description, I suggest removing the standard description field from the page layout to avoid confusion after you add the new field to the page layout. Set the FLS accordingly to whomever needs to view/edit the field.

Best practice tip: Provide a description so you and other/future admins know what this custom field is used for.

  • Data Type: Rich Text Area

Description

2. Create the Record Triggered flow shown above. In Lightning Experience, it is found under Process Automation | Flows. Click on “New Flow.” Select Record Triggered Flow. Click on the Create button.

In the flow, we would configure the following flow resources.

A. We need to create a constant resource called Linebreakconstant to store the line break.

Best practice tip: Provide a description so you and other/future admins know what this flow resource is used for.

This is how that flow resource would be configured.

  • Data Type: Text
  • Value: <br>

linebreakconstant

B. We need to create a formula resource called AmountChangedFormula to hold the value for the opportunity description field. Here, we are referencing the prior opportunity amount via the global variable $Record__Prior and the updated amount via the global variable $Record.

Best practice tip: Provide a description so you and other/future admins know what this flow resource is used for.

This is how that flow resource would be configured.

  • Data Type: Text
  • Formula: “The opp amount was changed from ” + text({!$Record__Prior.Amount}) + ” to ” + text({!$Record.Amount}) + “.”AmountChangedFormula

C. We need another formula resource. This one is called AccountDescriptionFormula, which holds the value for the opportunity’s account description field. Here, we are referencing the opportunity name and the updated amount via the global variable $Record.

Best practice tip: Provide a description so you and other/future admins know what this flow resource is used for.

This is how that flow resource would be configured.

  • Data Type: Text
  • Formula: {!$Record.Name} + “‘s amount was updated to ” + text({!$Record.Amount}) + “.”.”

AccountDescriptionFormula

D. Next, we create a text template resource called TextTemplate. This references the formula resource {!AmountChangedFormula} and adds a line break using the constant resource {!Linebreakconstant}.

Best practice tip: Provide a description so you and other/future admins know what this flow resource is used for.

This is how that flow resource would be configured.

  • Body: {!AmountChangedFormula} {!Linebreakconstant}

TextTemplate

E. First, we configure a Decision flow element to determine whether the opportunity amount has changed. Since there is no ability to use the IsChanged() formula syntax in flow to determine whether a field has changed value, we can do a comparison of the prior ($Record__Prior) and current ($Record) field values.

Best practice tip: Provide a description so you and other/future admins know what this flow element is used for.

Configure as follows:

  • Outcome: Yes – {!$Record.Amount} Does Not Equal {!$Record__Prior.Amount}
  • Default outcome: No

PriorValue_AfterSave-Decision

View image full screen

F. Next, create an Assignment flow element called Update Description where we assign the opportunity’s description to “The opp amount was changed from <opportunity’s prior amount> to <opportunity’s updated amount>.” and a line break.

Best practice tip: Provide a description so you and other/future admins know what this flow element is used for.

Configure to match the below:

  • {!$Record.Description_LongTextArea__c} Add {!TextTemplate}

PriorValue_AfterSave-Decision-Assignment

View image full screen

G.  Next, we need an Update Records flow element called Update Record to update the description field on the opportunity record

Best practice tip: Provide a description so you and other/future admins know what this flow element is used for.

Configure to match the below:

  • How to Find Records to Update and Set Their Values: Use the IDs and all field values from a record or record collection
  • Record or Record Collection: {!$Record}

PriorValue_AfterSave-UpdateRecords

View image full screen

H. We need another Update Records called Update the account which will update the description field on the opportunity’s associated account.

Best practice tip: Provide a description so you and other/future admins know what this flow element is used for.

Configure to match the below:

  • How to Find Records to Update and Set Their Values: Specify conditions to identify records, and set fields individually
  • Object: Account
  • Filter Account Records: All Conditions Are Met: Id Equals {!$Record.AccountId}
  • Set Field Values for the Account Records: Description: {!AccountDescriptionFormula}

PriorValue_AfterSave-UpdateRecords1

View image full screen

I. Now, we need to connect the flow elements to match the screenshot below.

PriorValue_AfterSave-Connectors

J. Save your flow. I’m calling this Prior Value – After Update. You may want to consider adding the object name to the flow name.

Best practice tip: Provide a description so you and other/future admins know what this flow is for.

PriorValue_AfterSave-Properties

K. Activate the flow.

Now, before you deploy the changes to Production, don’t forget to test the rest of your configuration changes.

  1. Update the opportunity amount and save.
  2. Verify that the opportunity description field is updated to: “The opp amount was changed from <opportunity’s prior amount> to <opportunity’s updated amount>.”
  3. Verify that the associated account’s description is updated to: “<Opportunity name>’s amount was updated to <opportunity’s updated amount>.”

Deployment Notes/Tips:

  • Flow can be deployed to Production in a change set (or can be deployed using a tool such as Metazoa’s Snapshot).
  • You will find the flow in a change set under the Flow Definition component type.
  • Activate the flow post deployment as flows deploy inactive in Production, unless you have opted in on the Process Automation Settings screen, to “Deploy processes and flows as active.” NOTE: With this change, in order to successfully deploy a process or flow, your org’s Apex tests must cover at least 75% of the total number of active processes and active autolaunched flows in your org or you can select 0%, which will run the apex classes not related to your flow.

2 thoughts on “Reference Prior Value in a Before/After Update Record Triggered Flows

  1. Thanks for this article. A related point – you say at the top “This brings us closer to be migrating our processes into flows as Flow Builder is the end state declarative automation tool.” One of the things Flows don’t do that Process Builder does do is to enforce organization of your processes. Some time back a SF ‘best practice’ was suggested that you have, if at all possible, just one PB for each Object, even though that may encompass many processes and flows. This has the effect of forcing logical thought about in what order multiple flows (triggered within the PB) will execute, as well as controlling that order (far as I know). Also, when troubleshooting or even enhancing, and searching for the Flow to fix/change, you can go to the PB list and find the processes (and flows) that are triggered by operations on a specific object. If you don’t do this (i.e., you have only Flows) it seems to me that finding the Flow you want is a matter of either having a really good memory or tedious searching. I think a good idea for one of your blogs would be a suggested strategy for so deploying Flows that the organizational benefits of PB would not be missed. Thanks again for sharing with all of us!

    Like

  2. On the flow roadmap is the ability to use subflows. Once that feature is in, you can have one before save flow and another after save flow for each object and use decisions like you do criteria nodes and use subflows like an invocable process.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s