I've setup a microflow to respond to a button press event on the Home Form (I'm using the Home Form as a main entry point for the application, where users then select the tasks they want to do). That microflow does the following: Creates new, blank Entity Shows a form where the user can edit the instance of the Entity Closes the form Saves a copy of the data to the disk If there is an error, then show a message, otherwise go directly to the End Event I set the "Concurrent Execution" of the Microflow as "Disallow = True" but when the microflow runs, I notice that the form in step 2 is presented to the screen, the close form activity is ignored and the microflow attempts to write the data to the disk. All this before I get control of the form. It seems that the flow is not respected and that all steps are executed at once, regardless of the "concurrent execution" setting. Is this a bug or is this behaviour by design? If by design, what is the value of the arrows in the flow diagram is they do not denote an actual sequential execution of activities?
asked
Alexander Lee
2 answers
3
Disallowing concurrent execution only means that the microflow can not be executed if it's already running.
The arrows do denote the actual sequential execution of activities but the actual forms are opened at the end of the microflow. There would be no point in opening them earlier because you cannot wait for user input in a microflow anyway. Your microflow has no way of telling when the user is done putting his data in. The way you should probably model this is just let the form open in the first part of the microflow and then having a next or save button on that form that executes the rest of the microflow.
answered
Sebastiaan van den Broek
2
so, basically, the FORM is the bit that actually dictates the flow of execution of user-dependent processes... thanks, this clarifies the framework assumptions, I'll give it a shot soon.