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:
- 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.
- 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.
Best Answer
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.