If we are creating multiple flows with roughly the same logic, it can be helpful to create ‘configuration’ object values. This can be a good strategy for re-using the same flow for multiple similar, but not identical, use-cases.
For example, we might have a flow that is the same for many situations, but occasionally, certain rules are skipped or some page components are not rendered. Here is a possible use case – Say, we have an on-boarding portal. Depending on the URL with which each class of user launched the app; the app can dynamically pass different views/information to the user, based on the configuration object. This way, the HR manager, the employee, or a department head can use the same app to handle different parts of the same business process.
In such cases, we can create a new type that has the various settings as properties. We can then set the various properties on initialization of the flow (make sure the configuration object value has Access set to Input for this). We can also load the configuration object value from a database (in which case, we need to make sure we have a table for it, and the appropriate filter for the record).
We can then leverage this configuration object value in our decision operator and page conditions as appropriate. We can simply flip the configuration object value properties as needed without needing to change the flow.