Approval Step

The Approval Step allows a workflow to notify one or more approvers and wait for them to mark the step complete.

In this article, we'll cover:

• Overview
• Where to Find This
• Configuring Approvers
• Approval Mode
• Configuring an Approval Step
• Example

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 in a ticket workflow, the responsible resource(s) are notified, and the step appears in the My Approvals section of the My Work application in Work Management 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, but they cannot approve or reject steps on behalf of an assigned group — they must be individually assigned to the workflow step to act on it.

During approval or rejection, the person taking action can add comments. A feed entry is always made on the ticket for the action taken, including a description of the action and any comments.

For a complete guide to creating, configuring, and activating ticket workflows, see Configuring Ticket Workflows.

In the example workflow above, a Choice step flows into the Approval step “Final Approval - Approval to requestor to make sure the work is done,” configured with the All mode, requiring every assigned approver to approve before it proceeds. If the approver selects Approve, the workflow follows the green path to the final Complete (Approve) step; if Reject, it follows the red path to the final Complete (Reject) step.

Where to Find This

The Approval step is configured in the Ticketing application admin interface, and can be viewed on a ticket with the workflow applied in Work Management and the Client Portal.

Configure the step from the Workflow Builder in the Ticketing app admin UI following these paths:

• Ticketing Application Admins Work Management > View Applications > [Name of the Ticketing application]  > gear icon > Admin > Workflows > [Workflow name] > View Builder
• Global Admins: In TDAdmin, go to Applications, then select the Ticketing application > Workflows > [Workflow name] > View Builder

Access an active workflow:

• In Work Management > View Applications > [Name of the Ticketing application] > find the ticket with the workflow applied and review the step
• In the Client Portal > Services > Ticket requests > open the request and review the workflow steps

Configuring Approvers

You can assign approvers directly, by role, or both:

• Approver(s): Search for and select one or more specific people or groups to act as approvers.
• Approver Role(s): Select one or more relative roles (listed below) whose assigned person or group is evaluated when the step starts.
• Fallback for Approver Role(s): This field appears once you select an Approver Role. Choose a fallback approver or group to be assigned if none of the selected Approver Role(s) can be evaluated to a valid user or group. When you select an Approver Role, you must specify at least one Approver or Fallback for Approver Role(s), so the workflow can't get stuck.

Client users can only own an Approval step if they're individually assigned to it — a client user can't belong to a group and have that group own the step on their behalf.

Increasingly complex business processes often require workflow approvers to be set based on their relationship to the requestor, creator, responsible resource, reviewer, service, or department. Dynamically assigned approver roles allow you to consolidate what would otherwise be multiple duplicate workflows into a single workflow.

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 is always followed.

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 must still have access to the ticketing application to act on the step on behalf of the group, and they must be configured to receive notifications for the group.

Every Approval step must be configured with an Approval Mode:

• All (default): The step is considered approved only after all assigned approvers approve it.
• Any: The step is considered approved as soon as any one approver approves it.
• Vote: Selecting this mode reveals two additional fields — Votes to Approve and Votes to Reject — where you specify how many approvers must approve or reject the step to reach a decision. Only one of these two values is required, but you can specify both at once. The step is approved once it meets the Votes to Approve threshold, or once meeting the Votes to Reject threshold becomes impossible; it's rejected once it meets the Votes to Reject threshold, or once meeting the Votes to Approve threshold becomes impossible.

When a group is assigned under All or Any, one member of the group approving counts as approval for the whole group — for example, under All, if two groups are assigned to a step, only one person from each group needs to approve before the step is considered approved.

Under Vote mode, each group assignment counts as a single vote and doesn't expand out to the group's individual members. When any member of the group (with appropriate access) approves the step, that member casts the vote on behalf of the entire group. If an individual is directly assigned to the step and is also a member of one or more groups assigned to it, their vote counts both for themselves and for all pending votes belonging to their applicable groups.

Vote Mode Examples

Options

Every Approval step includes Allow Item Approval and Allow Item Rejection checkboxes, disabled by default, that let an approver immediately approve or reject the workflow as a whole from this step, rather than only advancing to the next connected step.

If an approver can take an action that results in approval or rejection of the workflow as a whole — even a basic Approve or Reject option — the displayed option's text is "upgraded" to reflect that.

When you include an Approval step in a ticketing workflow, both its Approve and Reject options must specify at least one next step.

Configuring an Approval Step

The steps below cover configuring an Approval step specifically. For guidance on connecting steps, validating a workflow, and activating it, see Configuring Ticket Workflows.

To configure an Approval Step:

1. Access Workflows in the Ticketing app admin UI:
   • Ticketing Application Admins: Work Management > View Applications > Ticketing application > gear icon > Admin > Workflows
   • Global Admins: TDAdmin > Applications > Ticketing application > Workflows
2. On the Ticket Workflows list, click the name of the desired workflow.
3. Click the View Builder button.
4. In the Workflow Builder, click File in the toolbar.
5. Select Check Out from the dropdown.
6. Click the New Step button.
7. Enter a Name that indicates what the step will do.
8. Set the Type to Approval.
9. If Stages have been configured for the workflow, optionally select one from the Stage dropdown.
10. In the Approver(s) field, search for and select one or more specific people or groups to serve as approvers. 
11. In the Approver Role(s) field, select one or more relative roles. When the step starts, each role is resolved to the person or group who currently occupies it on this ticket (for example, "Requestor's Manager" resolves to that specific requestor's manager).
12. If you selected an Approver Role, the Fallback for Approver Role(s) field appears — select a fallback approver or group in case none of the selected Approver Role(s) resolve to a valid person or group.
13. Select an Approval Mode: All, Any, or Vote.
    1. If you select Vote, the Votes to Approve and Votes to Reject fields appear — enter a value for one or both fields to set the threshold for a decision.
14. Under Options, select Allow Item Approval and/or Allow Item Rejection if you want an approver to be able to approve or reject the entire workflow directly from this step.
15. Under Reminder Schedule, select None, Every [ ] day(s), or Every Weekday to set how often reminder notifications go out to the assignee while the step is pending.
16. Optionally, enable Limit Notifications and enter a value in Do not send more than [ ] reminders to cap the total number sent.
17. Click Save.

Once the step is saved, connect each choice to the next step it should lead to, the same way you'd connect any other step's options — learn more about adding, connecting, and validating steps in Configuring Ticket Workflows.

Notification Reminders

When editing an approval step within the workflow builder, you can set a recurring notification reminder to remind the assignee until the step is completed. Administrators can customize a new "Ticket Workflow Step Reminder" notification template for these notifications.

For more information about notification reminders for workflow steps, see Reminder Notifications for Approval, Choice, and Task Steps.

Example

An Approval step can serve as a single verification gate after multiple parallel paths converge in a workflow, rather than requiring separate approvals for each path. This lets you consolidate sign-off into a single point in the workflow, regardless of how many conditional branches led to it.

In the New Hire Setup workflow example below, the workflow starts by branching into four Condition steps — checking whether new network connections, enterprise system access, a new computer, or a new phone are needed. Each condition that's met triggers its own set of Task and Branch (Collector) steps to complete the relevant setup work, and each of those paths feeds into a shared Collector step that waits for all the applicable setup tasks to finish. Once every path has completed, the ticket reaches a single Approval step, "Verify all setup was completed," where an approver confirms the work was done correctly. Approving the ticket routes it to a "Complete" (approved) endpoint, while rejecting it routes to a separate "Complete" (rejected) endpoint.

This structure can help you require one final review of a ticket's overall outcome, without needing to build approval logic into each individual condition path.

Click to open the PDF and view the workflow details.