Executing Workflow Actions
Certain types of activities on the platform must be done in a specific sequence. These are often managed by workflows. For example, generally an app is created, then a Sandbox contract is requested, and then a Production contract is requested. At some point the app might be deleted. These actions are sequential, at least in part. An app must be created before a contract is requested; an app must exist in order to be deleted.
Some examples of workflow actions are: requesting or approving an API contract, sending a group membership invitation, or changing the status of a ticket.
These actions, which change a resource from one state to another, are controlled by the Execute Workflow Action operation. This applies to the following services:
- Groups: the POST /api/groups/requests/{MembershipRequestID}/actions operation
- Tickets: the POST tickets/{ticketID}/actions operation
- Contracts: the POST /api/contracts/{ContractDN}/actions operation
In each case, the operation verifies two things before executing the workflow action:
- The requestor is authorized to make the state change. For example, an API admin can approve or deny a request from an app to connect to the API; an app team member can cancel the app's request for access to an API.
- The state change is valid for the resource. To be valid, it must satisfy two conditions:
- The "from" state is the current state of the resource.
- The "to" state is a valid state for the resource to transition to. For example, a ticket can change state from Closed to Reopened but not from Closed to Resolved.
