An example of using signals is one in which a workflow is triggered based on some dependency being satisfied, as well as show the anticipated or expected run time of the workflow in the forecast tab. The following workflow demonstrates this functionality.
The purpose of this workflow is to "Do Some Work" shown in the lower right of the workflow after a dependency is satisfied. "Do Some Work" is shown here as a Flow Chart Action, initiating another workflow. The dependency "Trigger to Actually Run" is an Audit Trail trigger that is listening for another workflow to finish. The use of an Audit Trail trigger as the dependency is arbitrary and the dependency could be a File Exist trigger waiting for a file to arrive or any other Flux trigger waiting for an event. The "Expect to Run By" is a Timer trigger that is used to show in the forecast tab that this workflow is expected to run by 12:00 and to drive a notification is the dependency is late in firing. If the Audit Trail trigger does not fire because the other workflow does not complete by 12:00, the Timer trigger will initiate a loop to announce that the completing workflow is late, and it will retry until the "Trigger to Actually Run" fires.
In order to accomplish this - we add to the flow between 'Trigger to Actually Run' and 'Do nothing' - we raise a signal named "ready". The dialog looks as follows.
We also add "Signal" flows to the workflow that listen to the "ready" signal. When the ready signal is raised (and the word "ready" is completely arbitrary and can be any other value) the right portion of the flow shown listens for that signal to trigger"'Do some work" and to remove the 'Expect to Run by' timer trigger from the forecast.
This workflow is reusable and runtime variables can be used to configure it for a variety of work types. The "Do Some Work" will in most cases be a Flowchart Action that will initiate the actual workflows that perform the "real work" within the application.