Flows - Question Everything

Owned by Jodie Miners
Last updated: Nov 05, 2021
6 min read

This is not about best practices… there are many people that are writing many things about best practices, and I will link to some of them… but it’s about questions you need to ask as you are thinking about Flows, working on building Flows, and using Flows. Hopefully thinking things through will help you create better, more robust Flows.

Be Opinionated

This post is VERY opinionated. My opinions may NOT fit with your thinking about Flows or coding or Salesforce in general. But I write from a perspective of being a Salesforce Administrator / Developer / Consultant / Architect (and all the rest of the titles) but only working on small to medium businesses. So take note, that I understand that if you work in large or enterprises or where your Salesforce org does critical things like health and banking then go and read something else.

Also, if your org is only hand-crafted artisanal code and you’ve never installed a Managed Package or an AppExchange app, and you pride yourself on having nothing but code that has gone through 16 rounds of both manual and automated code review, and only been added to production via a CI/CD process and no human hands have touched it, then look away.

But if you live in the real world where we are building functionality on top of the Salesforce platform, utilising ALL that it has to offer, and have a heap of AppExchange apps and Managed Packages because we trust that others can write better apps than us, then this post might be for you. (Almost 10 years ago I wrote this post about thinking like Salesforce, - except replace Flow for Workflow Rule and LWC for Visualforce Page - and it still holds very true today).

Best Practices

OK, so I said I would link to a few best practices documents… I don’t agree with them all, but here’s a few

One X Per Y (or Process Builder is D.E.D. Dead)

If you are reading any documentation on Flows or Process Builder or anything and come across rules that declare MUSTs then just stop to think about why they are saying this. The declaration by Salesforce (even still to this day baked into the UI), saying you should only build one Process Builder per Object was one of the top ever 10 bad decisions by Salesforce (this is a whole other post). Just ignore it. Ignore that it was ever a thing. Ignore that Process Builder was ever a thing. Move on. Go back to learning about how Workflow Rules taught you to do automations and start from that basis of thinking.

Pre-Knowledge

Do you know your Order of Execution like the back of your hand? Nope? Then start there… I like this diagram but it’s not up to date with Before-Save Flows. You need to know what is happening when you click the Save Button or send a record into Salesforce by one of the many Integration options, (and no Mulesoft != Integration, but that’s another post).

Questions

Before thinking of Flows

  • To Flow or to Code?

    • It's not an either / or

    • Try thinking of Flow as similar to Apex Triggers (but built in a way that business can modify them more easily) and create Invocable Apex to do the hard logic.

  • Is there other ways to achieve this

  • Is a Workflow rule enough?

    • Eg email alerts

    • Approval Processes

    • I would have said Time-Based Workflow until recently but now that is fixed and you can use them in Flows.

    • It’s still OK to do a Workflow Rule if it’s just one or two simple updates on an object that’s not used much… but it’s probably much nicer to start building Flows.

  • Have you been scared off Flows?

    • Re-think what people are telling you! Why are they telling you this? What horror stories have they seen? Is the same thing likely in your org? Nope? Then go with the Flow.

Before Building

During Building

  • Does your Flow involve updating a field with a value from a Formula?

  • Is your record updated by an external System?

    • I have not found Before Save Flows safe in this instance

  • Can you actually use a Before Save?

    • Try, but in practice it’s not fabulous… and then is it really worthwhile maintaining two Flows, or just move everything to After-Save.

    • Eg DLRS updates a field via a Trigger, which runs after Before Save, so your Flow needs to run after that.

  • Do you have formula fields that rely on other formulas

    • Eg Rate1 * %1 = Fee1, Rate2 * %2 = Fee2, then TotalFees = Fee1+Fee2

    • Maybe do one in a Before Save then one in an After Save

    • They say don’t do same-object field updates in After-Save Flows but I have found it to be necessary.

  • Do you REALLY need that Flow Loop?

    • Have a look at the Collections collection

      • Eg to get a comma separated field of names of contacts where they have the same email address as the existing contact, use Extract Strings from Collection

    • How many records will you be updating at any one time?

      • Can you control the batch sizes? There are new Batch Sizes options in Asynchronous and Scheduled Flows. Otherwise Mass Action Scheduler is amazing for that.

After Building Flows

  • Versions

    • All new features will be released with Flow Versions

  • Keep up to date

    • Eg all your early Before Save Flows with Assignments and not Record Updates will still work, but update them to be sure.

  • New Features

    • Eg I now need to re-build my Flows with Subflows on After-Save Flows

NOW

  • Start Moving Process Builders

    • D.E.D. Dead. Get rid of them. Make it your mission!

  • Or Simple Before-Save updates from Workflow Rules

  • Maybe leave Emails until last (Emails in Salesforce generally are still a complete mess, apart from you can now use Lightning Email Templates in Auto Emails, but that’s a whole other topic).

  • There is no real hurry, only do it if you are working on improvements, or the Process Builders are sooooo horrible that you just neeeed to delete them to save your sanity, or there are performance issues that are bugging you.

What else to do with Flows?

 

Bottom line is HAVE FUN!