DRY - Don’t Repeat Yourself. These are words that resonate with everyone - regardless of your job title or role. In other words, you want to avoid doing the same tasks over, and over, and over again …
In this module let’s review common Best Practices that Flowgrammers use to build scalable and repeatable solutions!
Course Material
DRY - Don’t Repeat Yourself. These are words that resonate with everyone - regardless of your job title or role. In other words, you want to avoid doing the same tasks over, and over, and over again …
In this module let’s review common Best Practices that Flowgrammers use to build scalable and repeatable solutions!
Scalable and Repeatable Flows
Building scalable and repeatable Flows isn’t hard. Let’s review some of the ways that experienced Flowgrammers accomplish this.
1 - Scalable Flows are Generic
Simply put, this means that such Flows are configurable and customizable. Well-design Flows should have a minimum number of steps.
- You may initially create a Flow that’s more complex or necessary
- You may start by cloning a FLOPack from someone else (or our library)
The key is to iterate and ask yourself, “How can I make this simpler?” Chances are, after you understand your Use Case you’ll be able to find better ways to simplify your Flows.
2 - Human Readable
Again, think about a couple things:
- Will someone else (not me) use this Flow?
- If I don’t look at this Flow for 6 months, a year, or more - will I remember what it does?
In other words, time that you invest to Document what the Flow is doing is well worth the effort.
3 - Have reusable parts and are easy to monitor
Clearly it’s helpful to have Flows which perhaps use modular, well-designed child or helper Flows and are designed in such a way that you can easily understand / monitor execution.
4 - Are flexible
For those of you with one environment, this is less an issue, but if you’re developing Flows in a larger organization you will likely have MULTIPLE environments to allow for testing.
So in short you should think about making it so that your Flow can easily to switch from test to production!
Make it Generic
Let’s go back to point 1 - Make it Generic!
Veteran Flowgrammers will share their “trick”: Create a generic object before passing fields into a Flow
Why? One lesson that we learn by merit of interacting with a wide number of Applications across many customers is this: Every single instance is different!
Like you see in the image below, we’ve created an Object >> Construct card.
With this, if you’re copying a Flow (say from a FLOPack or elsewhere) - you can simple delete and re-map fields to this one card.
Without using this “trick”, you’re left with the alternative where you’ll need to drag fields the their appropriate places throughout the Flow.
If you’re a Partner or you’re working as part of a team, we strongly recommend making a point of implementing this use of Object Mapping as part of your process!
Easy-to-Use: Flow Pack Handling
If you’re - again - working as part of a team across (perhaps) multiple orgs then Flow Packs are an amazing way to share your work and quickly migrate from one org to another.
Here are some suggestions:
1 - Build Template Flows in a “Core Org”
If you’re in an organization that has multiple instances where you build Flows, you should have a single “source of truth” where your team develops. This way everything is created and tested in a central location.
2 - Naming conventions are important!
Just like we explained about documenting your Flows (making human readable), if you’re working with other Flowgrammers you should use standard naming conventions.
Module 203 - Designer Best Practices - reviews this in detail.
3 - Keep all parent and child Flows in same folder
Similarly important, we advise you to keep all related parent and child Flows in same folder. Folders are a fantastic way to “keep everything together”.
This way, that they retain parent/child relationships on when you go to EXPORT them.
If you use a Shared Folder, any clones will retain mappings so this is a great best practice.
4 - Import Into Shared Folder
Finally, we recommend doing any Flow Pack imports into a shared folder so all org members by default have access.
Conversely, you could create new folder and apply permissions to appropriate people.
Flow Pack Export & Import
- Accessing Export/Import
- Select the gear next to the folder for sharing options
- Export
- Select export
- Flow Pack download dialog opens
- Select download
- Import
- Navigate to the folder where you want to import the file
- Select import
Reusable Parts and Easy to Monitor
There are a number of things that you can do to “future proof” your work. Overall, you certainly want to minimize how often you are setting up the same set of cards or setting certain kinds of inputs.
1 - Create an Error Notification System with Routing
If you’re managing a large (airquotes) “ecosystem” of Flows, you may find a lot of value in creating an error notification system that routes certain kinds of messages to a single location.
For example, if you have multiple Orgs where you build and run Flows (particularly if you’re a Partner) you may direct messages (like Slack) to a single org. That way your team always knows where to find images and you have a single source of truth.
2 - Create Child Flows within a Set of Flows
You’ll want to do this, particularly if same set of cards are commonly called.
3 - Cross-Org Child Flows
You can call Child Flows across orgs!
A great use case behind this is if same set of cards are called across different solutions.
4 - Set Global System Values
Again, particularly if you’re managing Flows across different environments you may want to take advantage of storing standard values in a common place.
For example, Azuqua tables are great ways to store commonly-used values.
As we talked about previously, you could also leverage Child Flows to pull this information.
Summary
As we close this section, remember that these are only suggestions - but ones informed by a lot of hands-on experience. Just like developers do with code, great FLOWGRAMERS always take some time to think about how to scale and make repeatable solutions.