- 21 Aug 2023
- 4 Minutes to read
- Updated on 21 Aug 2023
- 4 Minutes to read
A business process can be designed in many ways when using a Flow. Over time, certain design patterns and tools are recommended by senior Decisions Developers as best practices. When developing Flows, these tools and methods provide ways to maintain and optimize a process.
Below is a glossary of best practices and tools developers can implement in their Flows:
|Recording Statistics From a Flow
|Provides the user feedback on the execution details of a Flow, such as how long and who ran the Flow.
|Saving Flow Step Configuration as a Template
|Provides a way for users to save and reuse Flow sections as a Template.
|Using Swim Lanes
|Swim lanes provide ways to organize and visualize sections of a Flow.
|Refactoring In-Flight Flows
|Contains common questions and answers in regard to designing a Flow.
|Exception Handling Best Practices
|Provides best practices for handling exceptions generated in a Flow.
|Reference Composite Types early in the Flow
|Call Data Structures into the Flow as early as possible so that the Change Value output mapping can output the data from a step directly as a value of the specified structure.
|Design Flow Step Layout with easy maintainability
|Flow readability is a large consideration when designing Flow logic. The recommended Flow layout has steps orchestrated from left to right, top to bottom. Lines should be as straight as possible. In addition, steps should be renamed to reflect their specific purpose in the Flow. The steps and arrows should be connected to the processing logic in functional sequence while viewing it from the Designer's view.
|Use the Most Efficient Steps/Paradigms
|Don't use three steps when one will do. Use a Truth Table instead of multiple, sequential rules. Don't use the For Each step and Rules to filter a list. Use a Collection Filter step. Filter the Fetch Entities to return only what is desired when possible. Use default Converter Flows instead of their separate steps.
Use out-of-the-box Steps or Rules instead of creating custom ones unless they are reused, have business significance, or have multiple conditions.
If only a True/False is required from a Rule, uncheck Expose Step as a Rule from the Outcome section and use the output as the variable. The exception is if the Rule is used for routing.
|Reusing Logic with Sub Flows
|For maintainability purposes, use as few steps as possible to build the logic and compartmentalize specific process steps into Sub Flows. When a Flow is created, it can be referenced from other Flows using the Run Sub Flow Step. The step is populated with the values of the Flow it is sourcing, then appears as a regular step using those values with input mappings in the main Flow. Additionally, after a Flow is created, select multiple steps to create a Sub Flow directly within a Parent Flow.
|Data is being transferred through Sub Flows efficiently
|Consider the functionality. Keep variable names consistent. Keep the Data Explorer clean.
If an entire object is required, pass it as the object, not its individual fields. On the other hand, don't pass an entire object if only parts of it are needed.
Use the Change Value instead of declaring multiple new data types to pass in and out of flows.
|Practice Development Refinement
|Create Templates for commonly used components to reduce development time.
|Appropriate Naming Conventions Used
|Clear names provide insight into the function of the Flow/step. Provides insight about what project the Flow is a part of. Provides insight about what the data is referring to.
Is easy to read/understand.
Use tagging to include helpful metadata for the designer element.
When using collections and outputting a single item, rename it to indicate it is a single item of an object. E.g. Current Account
When Fetching Entities, name the collection indicative of what is in the collection and that it is a collection. E.g. All Accounts
|No Email steps in exception handling logic unless it also has exception handling.
Exception handling sub flow is Async if it contains an assignment unless the Flow should pause.
The exception message should be intuitive and does not contain PII/PCI.
The Logging step is named and categorized appropriately.
|Unit Tests are utilized
|Unit Tests should allow for the testing of different scenarios.
An evaluation Rule should be set up correctly.
|Be mindful of recursion limits with looping.
|Flows limit recursions to 20,000 by default to avoid an infinite loop that occupies all system resources. This can be changed in any Flow from within the Flow Designer, but high or unlimited recursion limits can cause performance issues. If a Flow has a recursion limit of 20,000 and calls a Sub Flow that loops 30,000 times, it would throw an exception in the environment.
|Use ForEach looping if there is a dependency on the order of data being processed or the ForEachBreak step.
|When using the ForEach step in a scenario where another list of items to iterate is fetched before the first list has completed looping, use the ForEach Break step to reset the internal counter of the ForEach step, or else it will pick up on the row number that it last received.
|Use parallel processing with the Run Flow For List [Batch Processiong] step
|Use the Run Flow For List [Batch Processing] step if processing can happen in parallel; this step will spawn asynchronous processing threads. If the processing threads have a large workload and the rest of the parent Flow depends on the complete processing of threads, the parent Flow may need to pause processing or prevent fetching of processed data until a reasonable time. This step will force the parent Flow to move after all independent processing threads are spawned (rather than processed).
|CSV iterations with no dependencies
|To iterate through a CSV with no dependencies, it is possible to forgo the "For Each Row in CSV" and do bulk processing of all rows at once using the “Run Flow for CSV” component. Large data sets (300K+ rows) have caused failures in this step.