Newsletter

Assignment or Update

Hello folks,

I have a quick but important update for you this week.

An issue I see quite frequently happens when folks try and remember to use the assignment element instead of the update element in record-triggered flows. You can indeed use an assignment element instead of an update element in a before-flow to change the field values on the record that triggered the flow. However, this is not true when running your record-triggered flow in after-save mode.

To avoid confusion and facilitate an easy transition between before-save and after-save, always use the update element in a record-triggered flow to update the field values on the record that triggered the flow.

I am sure you know by now; before-save is labeled as Fast Field Updates, and after-save is labeled as Actions and Related Records in the record-triggered flow start element configurator.

If you have any questions, please do not hesitate to ask them on the Salesforce Break Slack. The invitation link is on https://SalesforceBreak.com.

Content and event updates:

Enjoy.

P.S. Originally published on 04/05/2022.

Read the previous issue of the newsletter here.

Read the next issue of the newsletter here.

Subscribe to the weekly educational Salesforce Flow Tips newsletter here.

Standard
Newsletter

Create and Update Elements

Hello folks,


What about create and update elements? Create and update elements perform DML operations. In other words, they write your data to the Salesforce database.

This is the type of element that you need to be most careful about. There are several reasons:

  • When you write data to the database, the changes are often irreversible, you may be doing a destructive change that you did not intend to do.
  • Salesforce governors limits are most strict about the number of DML operations you can perform. Especially combined with loops, you may hit limits in your transactions, which means you will experience faults/errors.

There are several ways of creating or updating records. You can create/update records one by one or in a collection. When creating/updating records one by one, You need to specify the object type you are working with, and you can set the field values one by one or use a record variable to set all field values in one shot.

One important tip here is related to the recordId(s):

  • Your create element does not accept a recordId as input. It will give you a recordId as output, and this will belong to the newly created record.
  • When you create a record using a record variable, or multiple records using a collection record variable, the recordId field must be empty. If you have any recordId value assigned to any record variables, your create element will fail.
  • When you update records using record variables or collection record variables, your recordId fields must have a valid matching value.
  • When you update records to set field values one by one, you don’t always have to specify a recordId; you can use filter criteria to determine one or more records that will be updated instead.

You can use fault lines to catch any errors you may experience when executing these elements. In addition, you can use your debug log, fault email, or failed flow interviews screen to review the debug logs and to view the failed interviews on flow canvas. This view shows the path your failed flow interview took highlighted on canvas.

Live session announcement:

Don’t Migrate Your Automations to Flow – Rebuild them instead: Salesforce plans to provide a migration tool to move Workflow Rules and Process Builders to Flow but, is that a good idea? What are the recommended next steps? Terry Miller and I discussed this topic live at 4:00 PM ET on Monday 11/29/2021. Watch the recording here:

Click here for the Youtube link

Click here for the LinkedIn link

Enjoy

P.S. Originally published on 11/28/2021.

Read the previous issue of the newsletter here.

Read the next issue of the newsletter here.

Subscribe to the weekly educational Salesforce Flow Tips newsletter here.

Standard