Automation Template Scenarios
Contents
Scenario
The Core delegated creation dialog specification assumes that the resource is immediately created when the user exits the dialog. Automation added “execution” as an immediate consequence of Automation Request creation. In some scenarios the user may want one behavior without the other.
Scheduled execution
The user wants to use an orchestrator or a scheduler (consumer) to periodically execute an automation plan (on the provider).
- The user opens the provider user interface to define scheduling rules and uses a dialog of the provider to define the automation request. This automation request does not have to be submitted for execution yet.
- The scheduling rules and the “template” of the automation request are saved in a resource on the consumer
- When the scheduling rules are matched, the orchestrator triggers the execution of the action by creating the automation request from the “template” the user previously defined.
Execution that requires an approval process
The user wants to execute an action that requires an approval process.
- The user opens the ticketing interface and from this interface invokes a delegated dialog to define the automation request.
- The “template” of the automation request and all the other information about the ticket (priority, due date…) are saved in a resource on the consumer.
- Following the approval process, this ticket is processed by the approver, if the ticket is approved, the ticketing tool triggers the execution of the action by creating the automation request from the “template” the user previously defined.
Variations
- The “scheduling smarts” could be in either actor, provider or consumer. The scenarios above are currently written to assume one of these, but this is exemplary, not limiting.
- The template might be saved in either actor, provider or consumer. The scenarios above are currently written to assume one of these, but this is exemplary, not limiting.
