Approval Step

This introduction article will help TDAdmin users to use the approval step within ticketing workflows using TDAdmin. The user must have either environment wide admin access or ticketing application admin access in TDAdmin.

Overview

The Approval step allows a workflow to assign one or more approvers to a step and wait for them to make an approval or rejection decision.

When an Approval step becomes active on a ticket workflow, the responsible resource(s) are notified, and the step appears in the My Approvals section of the My Work application in TDNext for the resource(s) assigned to the step. The step also appears in the My Approvals section of the Services application in the Client Portal for the resource(s) assigned to the step.

When an Approval step is assigned to a group, all resources in that group who have access to the associated ticketing application may approve the step. Individual client users can also be included in the approval process. Client users cannot approve or reject steps on behalf of an assigned group. Clients must be individually assigned to the workflow step for them to act on it.

Where to Find This

This feature appears in the TDAdmin, TDNext, and TDClient interfaces.

TDAdmin is where the workflow is created and configured, TDNext is where techs can see the status of the workflow and the steps, and TDClient is where TDClient users can interact with this workflow step.

Navigate to approval steps following these paths:

• TDAdmin > Applications > [Name of the ticketing app] > Workflows > New workflow > Open the the workflow up and click new step
• TDNext > Applications menu > [Name of the ticketing app] > Find ticket with a workflow on it and open it > Examine the workflow for the approval step
• TDClient > Ticket requests > Find a ticket with a workflow on it and open it > Examine the workflow for the approval step, or click on the link that is sent to the step owner to evaluate the approval step

Using the Approval Step

Increasingly complex business processes often require that workflow step approvers are set based on their relationship to the requestor, creator, responsible resource, reviewer, service, or department. Previously, administrators had to create many different copies of the same workflow to account for the varying permutations of approvers. However, with the use of dynamically-assigned approver roles, many duplicate workflows can be consolidated into a single workflow to represent the appropriate business process.

The following roles are supported:

• Requestor
• Requestor's Manager
• Requestor's Resource Pool Primary Manager
• Requestor's Primary Group Manager
• Responsible
• Responsible's Manager
• Responsible's Resource Pool Primary Manager
• Responsible's Primary Group Manager
• Creator
• Creator's Manager
• Creator's Resource Pool Primary Manager
• Creator's Primary Group Manager
• Reviewer
• Reviewer's Manager
• Reviewer's Resource Pool Primary Manager
• Reviewer's Primary Group Manager
• Service Owner
• Service Owner's Manager
• Service Owner's Resource Pool Primary Manager
• Service Owner's Primary Group Manager
• Department Manager

The role is evaluated when the step starts. To be valid, a variable approver role must evaluate to at least one of the following:

• An active user with TeamDynamix access (not a "Customer")
• An active group with at least one active user with access to the ticketing application (as the group approval restriction mentioned above still applies)

In addition, the "Reports To" manager, resource pool manager, or primary group manager(s) for the ticket requestors cannot refer to the requestor themselves. This ensures that appropriate escalation will always be followed.

Furthermore, certain roles can result in an assignment scoped only to a group's managers:

• Any relative "Primary Group Manager" role
• Responsible's Manager (when Responsible is a group)
• Reviewer's Manager (when Reviewer is a group)
• Service Owner's Manager (when Service Owner is a group)

When this is the case, the group's managers still must have access to the ticketing application to be able to act on the step on behalf of the group and must be configured to receive notifications for the group.

Configuring Dynamically Set Approvers

When selecting an approver role, at least one approver or fallback for approver role must be selected. This ensures that no workflow process will be abandoned should there be a problem with the approver role.

To configure an approver role:

1. In TDAdmin, click Applications in the left navigation.
2. Click the Name of the Ticketing application you want to add a workflow to.
3. In the left navigation, click Workflows.
4. On the Ticket Workflows list, click the name of the desired workflow.
5. Click the View Builder button.
6. In the Workflow Builder, click File in the toolbar.
7. Select Check Out from the dropdown.
8. Create or Edit an approval workflow step.
9. In the Edit Workflow Step window, select the desired role from the Approver Role(s) dropdown.
10. If an Approver Role is selected, a Fallback for Approver Role(s) may be selected in case none of the Approver Role(s) selected are not set in the system or otherwise fail. When selecting an Approver Role, at least one Approver(s) or Fallback for Approver Role(s) must be selected. This ensures that no workflow process will get abandoned should that occur.

During approval or rejection, comments can be added by the person taking action. A feed entry is always made on the ticket itself for the action that is taken. This includes a description of the action and any comments the person entered.

Each approval step also has "Allow Approve Item" and "Allow Reject Item" options for allowing an approver to immediately approve or reject the workflow as a whole. These options enable approvers to take actions which directly exit the workflow, either approving or rejecting the workflow, and are disabled by default.

If an approver can take an action which will result in approval or rejection of the workflow as a whole, even if it is a basic "Approve" or "Reject" option, the text of the displayed option will be "upgraded" to reflect that.

When including an approval step in a ticketing workflow, both its "Approve" and "Reject" options must specify at least one next step.

Approval Mode

An approval step must be configured with an approval mode. When the approval mode is Any (the default), this means the step is considered approved when any of the approvers approve the step. When the approval mode is All, this means the step is only considered approved when ALL of the approvers have approved the step.

When a group is assigned, when any member of the group approves the step, that group is considered to have approved the step. For example, if two groups are assigned to a step, only one person from each group must approve the step before the step is considered approved.

The Vote approval mode was added in version 10.2. When this is selected, you must configure the number of approvers who must approve -Votes to Approve- or reject -Votes to Reject- the step in order to reach a decision. Only one of these two values are required, but both can also be specified simultaneously. The step will be approved when it meets the Votes to Approve threshold or when it's impossible to meet the Votes to Reject threshold. Similarly, the step will be rejected when it meets the Votes to Reject threshold or when it's impossible to meet the Votes to Approve threshold.

Vote Mode Examples

The table below shows some examples of how the approval voting mode works. Based on the number of approvers and the rules in the first two columns, it will be have as described in the votes to approve and votes to reject columns.