The flow size indicator is a tool that helps you determine if your flow is reaching the maximum size allowed in Architect. If a flow’s size is lower than 70% of the allowable size, the flow indicator does not appear. To review the size of your flow, hover under your user name. If the flow size reaches 70% or above, the flow size indicator appears automatically. At this point, consider looking for ways to reduce the flow size.

Note: Common module flows have a lower size limit than other flow types.

Click the image to enlarge.

Architect flow size

Flow size indicator

This table describes the four flow size warnings:

Size indicator Percentage reached Restrictions Indicator appears automatically?
Low Lower than 70% of the maximum size allowed None No
Medium 70% of the maximum size allowed None Yes
High 90% of the maximum size allowed None Yes
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.

Note: The flow size can increase or decrease as settings go in and out of error. 

For example, suppose you have several actions within a task that reference a variable that does not currently exist.  The actions will be 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 may increase more than expected because when you add the variable, all of the actions are no longer in error. This is true even when a smaller number of actions with a large number of 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 with the exception of 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 need to 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.