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.

Back to top

Related Topics