2022 Flow Best Practices, Pt 2: Screen Flows

Today we’re bringing you Carissa’s best practices for screen flows, continued from last week’s Best Practices for All Flow Types…

Scroll down for the details, or click the links below to jump right to the best practice:

1. Formatting Text
2. Customize Buttons
3. Use Data Tables
4. Provide Helpful Error Messages
5. Launch Flows with Actions
6. Use Screens and Loops for Multiple Records
7. Use Subflows for Repetitive Tasks
8. Use Stages and Progress Bars
9. On Screen Error Messages

---

If Yes: Then definitely use the custom component! It will allow you to just add a “Save” button and a “Save & Add Another” button in tandem with a decision element, rather than needing an additional screen component

If No: Just update the custom text on the flow screen (if applicable)

---

---

Best Practice #4: Provide Helpful Error Messages

If you’re following the best practices from my last post, then you are working towards a special flow just for errors. Here’s what I suggest you include on the screen presented to users:

• A simple header – Let this fall in line with your corporate culture. Maybe it says “Well this is awkward” or maybe it says “Something Went Wrong”
• A meaningful message – I like this to reflect something specific to what went wrong, and also tell the user whether I want them to try again – OR if I want them to wait until I have time to look into it.

No matter what your error messages look like, just remember that not everyone speaks salesforce – so make it end-user friendly!

---

Best Practice #5: Launch Flows with Actions

If you’ve been in the Salesforce ecosystem for a while, you may be used to yester year, when we had to launch flows with a URL button. In today’s world, though, you need a REALLY good reason to do so – 99% of the time, you can get your needs met with an action and some input variables. Just remember to define the recordId input variable!

---

Best Practice #6: Use Screens and Loops for Multiple Records

As you’ll recall from last week’s post, I have witnessed a Screen > Create Record > Screen > Decision > Back to the first screen flow set up. Don’t do that. Instead, set up something that’s roughly

1. Screen to do a thing – with those custom buttons we mentioned above
2. An Assignment to set the values from the screen to a record variable and add the variable to a collection
3. Decision to decide what button was pushed
   • If Yes Add More – return to the screen for data entry
   • If No, That’s All – do the next thing

---

Best Practice #7: Use Subflows for Repetitive Tasks

Establish a rule for “How many Elements merit a subflow” – my usual go to is about 4. And since we’re talking about subflows….

• DO NOT nest subflows within subflows – try to keep navigating through subflows at the parent level
• DO use outputs from subflows, rather than creating variables just to store these things
• DO do as much database processing in the parent flow as possible – I like to use a boolean variable in my subflows to tell them whether they’re processing data or if the parent flow is
• DO use record input variables – if you’re getting records in your parent flow, just pass them down to your subflow and save yourself the DML limit

---

Best Practice #8: Use Stages & Progress Bars

Again, set a standard for your org for “How many screens need progress bars”. Once you do that, utilize the progress bar component you’ve already built, in conjunction with Flow Stages. If you’ve never worked with Flow Stages before, remember to assign the current stage as you navigate through the flow.

---

Best Practice #9: On Screen Error Messages

Honestly, this merits a post all on its own. But in a nutshell: Utilize Decisions, Boolean Variables, and Assignments to determine if screen input is valid, then circle back to the screen if something isn’t valid.

1. Screen for the user to input some stuff
2. Decision Layer 1 to validate each thing on the screen (I recommend one decision, with multiple outcomes for each item to validate)
   • This is a SIMPLE decision – we’re looking for “Did we validate Item 1”, “Did we validate item 2”, etc.
   • I utilize a formula to count my errors for the screen, then utilize this formula to determine if I need to return to the screen (see #6 below)
3. Decision Layer 2 to do the validation for each item
   • Here’s where we get complex – we utilize this one to decide what we need to consider Item 1 valid
   • If Valid – Hide Error
   • If Not Valid – Show Error
4. Assignment to mark Item 1 as validated
   • ALL outcomes from #3 above should to this assignment
5. Return to Decision Layer 1 for each item
6. If returning to the screen, Assignment to reset the Validation variables