[Note: This blog post will be updated after the release of Spring ’21 to mention updates to the capability of record triggered flows.]

In Summer ’20, Salesforce is releasing the after record save flow trigger. This joins the before record save flow trigger introduced in Spring ’20. In introduction of these two flow features is the start to moving automation from multiple tools (process builder and flow builder) to flow builder. I consider these features MVP and need further enhancements to get it to them to the point where you can really truly start transitioning your processes to flow.

With the introduction of the after record save flow trigger feature (the equivalent to a process built in process builder), I wondered how close this feature was to replacing process builder.

I build my processes using the best practices of apex triggers – one trigger per object. I build one master process per object. Given that design, my processes normally handle both situations – record creation and record update.

So, I wanted to see if I can build an after record save flow trigger to cover both situations. Unfortunately, I hit roadblocks immediately.

There was no way for me to determine whether a record is new (I can use the IsNew() syntax in my process criteria node). Since the new record is already created, I can no longer use the $Record and specifically, to see whether the $Record.Id was null as I can in a before record save flow trigger. In a before save, the record does not yet exist in the database, therefore, if the id is null, it would signify a new record.

For existing records, I still cannot determine whether a field has changed (using the IsChanged() or PriorValue() syntax as I do in my process criteria node).  Because this is an after save function, I cannot query the record for its current values for comparison as I can with a before record save flow trigger. (Thanks, Gorav Seth for your blog post.) I don’t know about you, but I do not want my automation to run every time the record is updated and the field equals a specific value. I only want it to execute if the field is changed.

You also cannot call a subflow in an after record save flow trigger. It is not efficient to build a complex flow in your after record save flow trigger and not maintain this in its own flow.

I have to admit, I was disappointed.

So, I thought, can this possibly work to handle situations for when a new record is created.

I took a fairly simple process on record save only and looked into whether it would be feasible to convert the process built in process builder and built that same automation using the new summer ’20 after new record save flow trigger.

Here is my process for a new case:

View Image Full Screen

The first criteria checks to see if the case origin is web. If true, it will update the priority of the record to high.

The second criteria checks if the case reason is breakdown. If true, it will update the case ownership to a specific case queue and to send an email alert.

I was able to build this automation in flow builder.

View Image Full Screen

View Image Full Screen

Let’s walkthrough each process builder element and how this translated to flow.

In process builder, after you specify the process starts when a record changes, you specify the object (Case) and that it starts only when a record is created.

In flow builder, you create a record-changed flow and then you specify to trigger the flow when the record is created and to run the flow after the record is saved.

Then, you select the object (Case) that triggers the flow.

Now, lets take a look at the first criteria node…In process builder, we set the condition to [Case].Origin Equals Picklist Web.

View Image Full Screen

In flow builder, we need to create a Decision flow element. The condition for the “Case Origin is Web” outcome here is {!Record.Origin} Equals Web. Note: Any record attributes are found using $Record global variable. The default outcome is “Case Origin is Not Web.” Note: The default outcome is equivalent to the false condition in process builder.

View Image Full Screen

Now, let’s look at the immediate action in process builder to update the record that started the process to update the priority to high: Priority Picklist High.

View Image Full Screen

Switching over to flow builder, for the “Case Origin is Web” outcome, we need an Update Records flow element. Configure it as follows:

• How to Find Records to Update and Set Their Values: Specify conditions to identify records, and set fields individually
• Object: Case
• Condition Requirements: Conditions are Met where Id Equals {!Record.Id}
• Set Field Values for Case Records: Priority: High

View Image Full Screen

At the end of the first criteria node in process builder, we set it to evaluate the next criteria.

In flow builder, the equivalent function is done with a regular connector from the Update Records flow element to the next decision (i.e. “criteria node”).

Now, for the second criteria node in process builder, Case Reason = Breakdown, we set the conditions to [Case].Reason Equals Picklist Breakdown.

View Image Full Screen

In flow builder, we need to create another Decision flow element. The condition for the “Case Reason is Breakdown” outcome here is {!Record.Reason} Equals Breakdown. As mentioned above, any record attributes are found using $Record global variable. The default outcome is “Case Reason is Not Breakdown.” Note: The default outcome is equivalent to the false condition in process builder.

View Image Full Screen

For the immediate action in process builder, we want to update a field for the record that started the process: Owner ID Queue Jen_Queue.

View Image Full Screen

Switching over to flow builder, this one step in process builder will require two flow elements for the “Case Reason is Breakdown” outcome: Get Records flow element  and Update Records flow element to update the owner Id to the queue Id.

In the Get Records flow element, we need to get the queue Id based on the queue name. We need the Id to update the owner id. We can’t just reference the queue name.

We first need to create a text variable to store the queue Id. Configure as follows:

• Variable name: varJenQueueId
• Data Type: Text

Configure the Get Records flow element as follows:

• Object: Group
• Condition Requirements: Conditions are Met where DeveloperName Equals Jen_Queue
• How Many Records to Store: Only the first record
• How to Store Record Data: Choose fields and assign variables (advanced)
• Where to Store Field Values: In separate variables, Id: {!varJenQueueId}

View Image Full Screen

Next, we use the Update Records flow element to update the owner Id to the queue Id. Configure it as follows:

• How to Find Records to Update and Set Their Values: Specify conditions to identify records, and set fields individually
• Object: Case
• Condition Requirements: Conditions are Met where Id Equals {!Record.Id}
• Set Field Values for the Case Records: OwnerId: {!varJenQueueId}

View Image Full Screen

For the second immediate action in process builder, we need to send an email alert Case_Email_Alert.

Switching over to flow builder, we will use the Case Email Alert email alert and set the Record ID to {!Record.Id}.

If you have fairly simple processes for new record creations, you can possibly start moving your processes to the new after record save record creation flow trigger.

I don’t chase new shiny objects, as they aren’t usually mature on their initial release, so I’d recommend watching this feature for a couple of releases as they improve it before you start moving processes to flow.