Architect flow size
The flow size indicator is a tool that helps you determine the percentage of the maximum size your flow currently uses in Architect. The tool enables you to better anticipate the eventual size of your flow during design time so that you can consider looking for ways to optimize the flow size in a timely manner. For example, divide your flow into multiple flows at an early design stage and not when your flow is reaching the limit.
The flow size indicator is accurate within 0.1%. Architect shows the first digit of any fractional flow size value so you can observe what effect even small changes in flow logic can have on the flow size. Architect rounds the flow size percentage to the nearest single-digit fraction value. For example, if the actual percentage is 10.68, the flow size indicator shows 10.7.
Flow size indicator
This table describes the four flow size warnings:
Size indicator | Percentage reached | Restrictions |
---|---|---|
Low | Lower than 50% of the maximum size allowed | None |
Medium | 50% of the maximum size allowed | None |
High | 90% of the maximum size allowed | None |
Full | 98% of the maximum size allowed |
You cannot publish the flow, but you can save changes to it. Note: If a flow reaches 100% of the maximum size allowed, you cannot save changes or export the flow. |
For example, suppose you have several actions within a task that reference a variable that does not currently exist. The actions are in error due to the missing variable. If you add a variable to resolve the error (which seems like a small change), because the configuration is now valid, Architect can fill out internal flow structures such as expression trees. The flow size can increase more than expected because when you add the variable, the actions are no longer in error. This is true even when a smaller number of actions with many settings reference the variable.
Tips for reducing flow size
These tips can help reduce the size of a flow:
- If you have multiple Update Data actions in a row, each with one update statement, consolidate the actions into one Update Data action that contains multiple update statements.
-
Avoid duplication. Consider the fact that certain actions such as Call Data Action, Call Secure Data Action, Set Screen Pop, Create Callback, and Call Data Actions can consume a large amount of space depending on how you configure the inputs, success outputs, and failure outputs.
If you have multiple instances of the same action with generally the same configuration except for a few different settings, best practice recommends that you update the logic to have one instance of the action, and then use variables to pass in the values that change. Along with reducing flow size, this method is more maintainable in the future. If you must change a setting that previously was common throughout all instances of the action, you now only need to update the setting in the single instance of the action.