Best Practices

Best Practices

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:

Flow Design

Practice		Purpose
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
Exception Handling		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.

Looping/Lists