As an example, we have a process by which our main business entity is modified through an amendment process. We have a dialog launched from our main business entity that collects the information the changes, creates the amendment with the appropriate fields which control the approval process and once all the approvals (different for each type of amendment) are approved the changes are applied to the main business entity. This allows us to use a single approval process to control five different types of modifications to the main business entity, each requiring approval from different groups of people without the business users needing to know the implementation details of how we control the process. The changes must NEVER be applied to the main business entity until after they are approved.
Since business process flows have no support for variables and can only branch their workflow from data collected rather than all the fields in the entity, there is no way for me to duplicate this type of process. I would have to have a separate business process flow for every amendment type, and then the business user would need to create the amendment and select the correct business process flow. I would also need to write separate actions to set the internal fields in each case.
I understand breaking changes in upgrades to an application, but business process flows are not even close to a substitute for dialogs. They are primitive by comparison. Even something as simple as only prompting for a field if it is not currently set is impossible to do with business process flows. What is the recommendation for migrating complex dialogs in an on-premises environment?