Please let me know if there is already a good solution to this.
Problems
It is not obvious that the current “Add a pause before next action” operation blocks all other front-end actions on the page, so it’s easy to accidentally think that if a workflow is triggered during the pause somewhere else on the page, it would run.
There is no non-blocking front-end pause operation, so any workflows that need to run during a pause cannot run.
Solutions
Change the wording of “Add a pause before next action” to “Add a pause for before all actions” or something similar to make it obvious that it’s blocking.
Add a non-blocking front-end pause operation.
Importance
Adding a non-blocking pause allows for functionality like this:
Workflow A mutates shared state
Workflow A starts a non-blocking pause
In another place on the page, Workflow B triggers due to the state change
Workfow A resumes
Note: in this example there is no way for Workflow A to directly trigger Workflow B or vice versa, namely because Workflow B is in a reusable inside a repeating group, so there can be multiple instances of Workflow B.
So, I’m confused. This example describes the trigger for workflow B has the state change that workflow A produces, so why do you need a pause at all anyway?
Either way, @ihsanzainal84 is correct that the non blocking pause is essentially schedule a custom workflow, but based on your example I don’t think you need that anyway.
You mention multiple instances of RE on page that needs the state change from workflow A before workflow B in the reusable element can run. Have you thought about a custom workflow in the reusable and on page in workflow A just trigger custom workflow from reusable element? Probably a cleaner solution than a state change set up as I imagine your reusable has some sort of conditional workflow trigger based on the custom state value to have workflow B run.
I can’t trigger an event on the frontend because the reusable element running the workflow is nested inside of a repeating group. Yes, I can schedule one the backend, but then that would require me to use the database to update state inside that reusable element, which I’m trying to avoid having to do.
Good point. It wasn’t clear in my post. I am trying to have Workflow A essentially rely on Workflow B, because Workflow A has an action that relies on Workflow B having run already, hence the need for a pause to give Workflow B time to run.
An arguably better solution would be handling this through the database by storing Workflow B’s state in the database or having Workflow B scheduled on the backend like @ihsanzainal84 suggested, but I was trying to avoid having to store temporary state in the database.
I suppose writing to the database might be the only solution here though.
Why not copy/paste or recreate the workflow into the parent page/reusable element? If you need to reference a selection from the repeating group, it can be passed as a parameter of the custom event.
I haven’t come across any need to use backend states for clientside workflows At most I’m listening for a change to a field or data source.
No, never a better solution to store a temporary value in database and waste WUs.
You can have on page where workflow A needs to run after workflow B runs from inside a RE for conditional trigger based on RE custom state value, or use URL parameter or use toolbox to trigger workflow A on page after RE workflow B is run…there might be other better solutions I have not mentioned, but storing value in DB is not the right choice.
Share screen shots of your setup, then somebody might tell you an optimized solution for the specific use case.
At most I’m listening for a change to a field or data source.