3

Salesforce is gradually pushing us to replace workflows and processes with flows. But: workflows have a special property that processes and flows don't have. I refer to Salesforce's Order of Execution documentation, step 11:

If there are workflow field updates: [...] Custom validation rules, flows, duplicate rules, processes, and escalation rules aren’t run again.

Processes and flows do not have this property: running without being followed up by duplicate detection. So it can happen that processes and flows fail with a DUPLICATES_DETECTED exception. Here's the idea on IdeaExchange to fix that. It was posted 7 years ago and it still hasn't been followed up by Salesforce.

Somewhere in the reactions to that idea a workaround is offered that involves using a checkbox, which is then used in the duplicates rules to circumvent them. And yes, that workaround works precisely because it uses a workflow, which has that property of not being followed up by duplicates detection.

The idea was originally about processes and the workaround works for processes. But it does not work for flows! Because if you read the Order of Execution documentation very carefully (and you should), pay special attention to:

  1. Executes the following Salesforce Flow automations, but not in a guaranteed order.
  • Processes
  • Flows launched by processes
  • Flows launched by workflow rules (flow trigger workflow actions pilot)

When a process or flow executes a DML operation, the affected record goes through the save procedure.

  1. Executes record-triggered flows that are configured to run after the record is saved.

If you replace a process with a flow, you will notice that after a DML operation by the process, workflows will run. But after a DML operation of the flow, workflows will not run. Hold on, you say, step 13 mentions flows. Yes, it does, but only flows that are triggered by something else. If you have a 1-to-1 flow replacement for a process, no workflow will run after the flow. And so, the workaround for evading duplicates detection will no longer work. Which prevents us from porting processes to flows for Account, Contact and Lead objects.

In summary: processes and flows may fail because of duplicates detection, where a workflow will succeed. A workaround for this will work for processes, but not for flows. Salesforce wants us to use only flows. I ask you: how are we going to do that? It seems that the Order of Execution will prevent a successful transition for those orgs that use duplicates management.

Improve this question
3
  • 1
    One thing to keep in your back pocket - The create/update element in my flows has a fault path where if the fault is a duplicate detected, I then delegate to apex to upsert the object with DuplicateRuleHeader enabled to bypass dup alerts.
    – cropredy
    May 5, 2022 at 16:55
  • @cropredy Good suggestion. Next challenge: the Update-Record element - that is the root of the fault path - specifies which values are assigned to which fields. So not only the record-to-be-updated, but also the set of fields and values has to be passed on to Apex. Any recommendations for how to do that easily?
    – Sander de Jong
    May 10, 2022 at 12:26
  • 1
    Move the field assignments out of the Update element into an immediately preceding Assignment element (which assigns to a record variable). Update element's Fault path supplies the record variable to the invocable apex
    – cropredy
    May 10, 2022 at 15:13

1 Answer 1

Reset to default
0

What I ended up with: Apex batch jobs that reset the checkboxes that are used to temporarily disable duplicates checks on accounts, contacts and leads. The Apex code uses the ability to perform a save operation with duplicates checking disabled (DuplicateRuleHeader.AllowSave = true).

So, not the most elegant solution, but it works and I have finally gotten rid of the last workflows in my org.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .