Avoid having multiple flow elements do similar behavior because it can lead to bugs and inconsistencies, instead, use variables or formulas to achieve the same using a single element.
Avoid
Say you were given the following requirements:
- When a Contact is inserted or updated and it is not yet assigned an Account (AccountId is blank)
- Find an Account whose phone matches a phone on the Contact, and assign the Contact to that Account (ContactId = Account’s Id)
- Match by the following fields
- On the Account, by its Phone field
- On the Contact, by its Phone field if it is not blank, otherwise, match by its OtherPhone field.
In the flow below, the approach is to first determine which of the Contact’s Phone fields to match by and then proceed down one of two almost identical paths to do the rest: find a matching Account and assign it to the Contact.
“Get Accounts By Phone” and “Get Accounts By Other Phone” are the same, except that they “get” (search) Accounts matching against different contact phone fields.
Same with “Relate Contact To Account”, both elements are identical, except that they each reference the “Get Account..” flow element in their respective path.
Avoid Because
Implementation should not be more complex than business requirements.
In this case, there’s essentially one requirement to assign the Contact to the Account that matches by phone. The added complexity of which phone to search by should be handled separately from the main requirement, instead of repeating the entire implementation.
The practical disadvantages are
- A more complex flow, divorced from plain business requirements, can be more difficult to comprehend.
- Any changes needed will have to be made in multiple places.
For example, say requirements changed and accounts need to be matched by a different phone field on the account, that change will need to be done in both “Get Account..” elements.
In addition to the added headache for the admin/developer, bugs or inconsistent behavior will be introduced if the duplicate elements are not updated in sync with each other as requirements change.
- Similarly, if something breaks in one of the elements, it may not be noticed as quickly (as it only “runs” under specific conditions), and when it is reported, the developer may have a harder time resolving because they will need to identify the specific path that has the broken element.
This advice reflects a well known concept in software development, known as Don’t Repeat Yourself, abbreviated as DRY. While flows are billed as a no-code alternative, many of the principles observed in software engineering and salesforce engineering in particular, apply to flows as well. Principles will often apply beyond the specific tool they are first introduced in.
Instead
Separate the logic determining which contact field to match by from the rest of the flow. The result can be stored in a variable which will then be used in the flow element that searches for the Account.
As you may notice, the decision element only determines what phone number is assigned to the variable. Subsequently, we simply use that variable named “PhoneToSearchBy” in the flow elements.
Formula Alternative
Another option is to use a Flow Formula that would encode the decision logic (determining which Contact field to use) and output the relevant phone number. This will result in a simpler looking flow, but requires some familiarity with formulas or code, and would also relegate the decision logic to outside the main flow area.
The Formula in this case is
it would replace the variable here
and further simplify the overall structure.
Please let me know any feedback or disagreements in the comments or on LinkedIn. I love to hear other perspectives and engage with them.
P.S. This flow is for demonstrative purposes only. There are several improvements needed before it goes into Production, but that’s beyond the scope of this article.
Readout below.
Be First to Comment