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.

The sections below provide information on the actions that are valid on these three types of objects and the roles required for each.

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

Workflow: Groups

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

Back to top

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 an action.

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

Workflow: Tickets

Back to top

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

Workflow: App/API Contracts

Back to top

Related Topics