before the question itself, I would like to describe the current situation.
We are thinking about the new process application (for processing client requests), which should be used by different front-end applications (corporate web, mobile app......hosted on different infrastructure than process engine). This is the main reason, I don't want to use forms inside the process engine for interacting with the user. Front-end applications, will be responsible for UX and calling basic process steps, and process engine will be responsible for handling the process logic and orchestration of underlying services. With this approach, also Different front-end applications (web,mobile) will use the same process.
Now, about the process...
Imagine the simple flow, where you fill-in basic info about yourself (on the front-end application screen) which triggers the start of the process.
After that, basic check is performed (by the process ,calling the backend systems) if we can find such client. If no, we will ask him to register (on the front-end application.)
Below, you can see, how the flow looks like right now. Because I don't have forms in my process application, I used message throwing and receiving approach, instead of User Task.
So the logic is: If no client is found in our backend systems, the process will send the message (some Rest call). The message will be identified by the front-end application (the same, where user filled-in the first set of data), and registration form will be displayed. Process will wait, for message from front-end, indicating the client was registered. After the message is received, the flow will continue to the next step.
And my question is, if you think this design of communication between process engine and front-end is a good design, or you are aware of better alternatives how to design and model this situation.
Another alternative would be to handle the registration by the process itself.