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:
- API Versions: the POST /api/apis/versions/{ApiVersionID}/action operation
- Contracts: the POST /api/contracts/{ContractID}/actions operation
- Groups: the POST /api/groups/requests/{MembershipRequestID}/actions operation
- Model objects: the POST /api/models/versions/{ModelVersionID}/action operation
- Tickets: the POST /api/tickets/{TicketID}/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.
The sections below provide information on the actions that are valid on these types of objects and the roles required for each.
- All Groups: Valid Workflow Actions
- All Groups: Workflow Diagram
- API Scope Groups and Independent Groups: Additional Workflow Actions
- Tickets: Valid Workflow Actions
- Tickets: Workflow Diagram
- App/API Contracts: Valid Workflow Actions
- App/API Contracts: Workflow Diagram
- API Versions: Valid Workflow Actions
All Groups: Valid Workflow Actions
| Action | Value |
|---|---|
| Accept (must be an invited group member who has not yet accepted or declined) | group.membership.action.accept |
| Decline (must be an invited group member who has not yet accepted or declined) | group.membership.action.decline |
| Resend (must be a group administrator resending to an invited group member who has not yet accepted or declined) | group.membership.action.resend |
| Remove (must be a group administrator removing a current group member) | group.membership.action.remove |
All Groups: Workflow Diagram
API Scope Groups and Independent Groups: Additional Workflow Actions
| Action | Value |
|---|---|
| Make Admin (must be a Member or Leader) | group.membership.action.make.admin |
| Make Leader (must be a Member or Admin) | group.membership.action.make.leader |
| Make Member (must be an Admin or Leader) | group.membership.action.make.member |
Tickets: Valid Workflow Actions
To perform any of the actions listed below, the user must be an app team member, author or submitter of the ticket, or API or Business Administrator. The Site Administrator can delete a ticket.
| Action | Value |
|---|---|
| Resolve | ticket.action.resolve |
| Close (must be open) | ticket.action.close |
| Reopen (must be closed) | ticket.action.reopen |
| Delete | ticket.action.delete |
| Edit priority (doesn't change the state of the ticket) | ticket.action.edit.priority |
Tickets: Workflow Diagram
App/API Contracts: Valid Workflow Actions
The Contracts workflow actions switch an app/API contract from one valid state to another. Again, the two conditions to be met are 1) the requestor is authorized to make the change, and 2) the change is valid for the specific contract. In order for the switch to be valid, the old state must be the current state of the object, and the new state must be a valid change.
| Description | Value |
|---|---|
| Approve | apicontract.action.approve |
| Activate | apicontract.action.activate |
| Cancel | apicontract.action.cancel |
| Reject | apicontract.action.reject |
| Resubmit | apicontract.action.resubmit |
| Suspend | apicontract.action.suspend |
| Resume | apicontract.action.resume |
App/API Contracts: Workflow Diagram
API Versions: Valid Workflow Actions
The API version workflow is optional. If custom workflow is implemented, these workflow actions govern how API versions are managed on the platform.
As always with workflow, the user performing the workflow action must be authorized to perform the action, and the action must be valid for the object's current state.
| Description | Value |
|---|---|
| Submit for Approval | apiversion.action.submit.approval |
| Approve | apiversion.action.approve |
| Activate | apiversion.action.activate |
| Cancel | apiversion.action.cancel |
| Reject | apiversion.action.reject |
| Resubmit | apiversion.action.resubmit |
| Suspend | apiversion.action.suspend |
| Resume | apiversion.action.resume |
App/API Contracts: Workflow Diagram