Body
Who can use this feature?
- Available in Work Management
- License Requirement: Enterprise, Technician, or Student Technician
- Application Access: User must have access to Work Management and the specific Ticketing application
- To assign a workflow to a ticket:
- User must meet any one of the following: has the Ticketing app security role permission "The user will be able to edit all tickets regardless of type," OR be the Reviewer of the ticket.
- To approve, reject, or skip ticket workflow steps:
- User must have the Ticketing app security role permission "The user will always be able to approve/reject/skip ticket workflow steps." Without this permission, you can still act on steps you are directly responsible for.
Ticket workflows automate the approval and fulfillment process that a request must move through. A workflow can include a range of step types — approvals, condition evaluations, notifications, decision branches, and more — to enforce and automate complex business processes. Workflows guide tickets through structured stages that may involve multiple decision points and parallel activity, and can use Web Services to integrate with systems both within and outside of TeamDynamix.
In this article:
You can access workflows from tickets in any Ticketing application you have access to in Work Management:
- Work Management > View Applications > [Ticketing application]
A workflow can be assigned to a ticket in one of two ways: automatically based on configuration, or manually by a technician after the ticket is created. In either case, when a workflow is assigned, a copy of the workflow configuration is applied to that ticket. Changes made to the workflow configuration after assignment do not affect workflows already in progress — except for reminder notification settings, which affect steps already assigned to a ticket. Additionally, because group and person names are copied into the workflow at the time of assignment, any subsequent name changes will not be reflected in workflows already in progress; the workflow configuration itself must be updated for name changes to take effect.
For a workflow to be assigned to a ticket, the ticket's requestor must be a Customer or User in the TeamDynamix system. If a requestor appears as a read-only value, you must update their record to a Customer or User record before a workflow can be assigned. A read-only requestor is not tied to a user account; without a recognized requestor, the system cannot assign workflow approval steps and will not apply the workflow, whether the trigger is a service, an automation rule, or a manual assignment by a Work Management user.
A workflow is automatically assigned to a ticket when either of the following is true:
- The ticket was submitted through a service that has a default workflow configured (set up in the Admin UI under Client Portal > Services).
- An automation rule is configured to assign a workflow based on specified conditions.
When a workflow is automatically assigned at ticket creation, the ticket's classification is set to Service Request.
A workflow can also be manually assigned to a ticket after it is created by selecting Actions > Assign Workflow on the ticket. See the Manually Assigning a Workflow to a Ticket section below for details.
Assigning a workflow to a ticket that already has one removes the existing workflow, including any incomplete workflow ticket tasks. If you select the same workflow that is already assigned, the current instance is removed, and the workflow restarts from the beginning.
A workflow begins at a designated starting step. From there, the ticket moves forward as each step is completed — either through direct user action or automatically, depending on the step type. Some steps require a user or group to take action, such as approving, rejecting, or making a choice, before the workflow can proceed. Other steps advance automatically: a Condition step routes the ticket based on ticket attribute values, a Notification step sends a message and moves on, a Timer step pauses the workflow until a specified amount of time passes, and a Web Service step calls an external system without requiring user involvement.
As the workflow progresses, multiple steps can be active in parallel. A Branch step, for example, splits the workflow into separate paths that run simultaneously; a Collector step then waits for all preceding paths to complete before the workflow continues. Attempting to trigger a step that is already in process has no effect — it remains active but does not restart.
Each workflow applied to a ticket has its own status, separate from the ticket's status. The possible workflow statuses are:
- In Process — set as soon as the workflow is assigned to the ticket.
- Approved — set as soon as the workflow reaches the final Approve step, regardless of whether other steps are still active in a parallel branch.
- Rejected — set as soon as the workflow reaches the final Reject step, regardless of whether other steps are still active in a parallel branch.
Certain workflow steps may include an option to approve or reject the entire workflow immediately, bypassing remaining steps.
Whenever a ticket workflow finishes, both the reviewer and the requestor are notified by email.
When the workflow is approved, the following actions are taken on the ticket:
- The ticket's status is changed to the Approval Status configured on the workflow.
- The requestor and reviewer are both notified by email of the approval if the workflow has an Approval Status set. Note that the reviewing group is not notified.
When the workflow is rejected, the following actions are taken on the ticket:
- The ticket's status is changed to the Rejection Status configured on the workflow.
- The requestor and reviewer are both notified by email of the rejection if the workflow has a Rejection Status configured.
- The workflow system attempts to notify each email address only once. If the ticket reviewer and requestor are the same person, that person receives a single notification — the reviewer notification takes precedence.
A workflow can change a ticket's classification when a step starts, finishes, or the entire workflow completes. The following rules govern classification promotion:
- A Service Request can be promoted to any other ticket classification.
- Nothing can be promoted to a Service Request.
- A ticket can only be promoted upward in the following hierarchy:
- Release
- Change
- Problem
- Incident
- Service Request
For example, if a workflow's Promotion Classification is set to Change and an Incident is sent through that workflow, the Incident is promoted to a Change. If a Release is sent through the same workflow, its classification is not changed because Release is already above Change in the hierarchy.
The name of a classification may differ depending on your organization's customizations, but the fixed System Type drives the hierarchy above.
Stages group a series of workflow steps to provide a quick, high-level status summary of a ticket's progress. Because stages are visible in the Client Portal, they let you clearly communicate to requestors where their request stands without exposing the internal complexity of your workflow.
Note that stage statuses are distinct from workflow statuses. Each stage has its own status — Pending, In Process, or Complete — that reflects its position in the workflow's progress, independent of the overall workflow status described above.
When a workflow starts, all stage statuses are set to Pending. Stage statuses are then managed automatically by the workflow according to the following rules:
- When a step associated with a stage starts, the stage's status is set to In Process.
- When a step is approved or completed, and no other in-process steps are associated with that stage, the stage's status is set to Complete.
- When a step is rejected, and the next step that starts is associated with a different stage, the stage's status is set to Pending.
- When a workflow is started, all stage statuses are set to Pending. If several sequential steps share a stage, that stage remains In Process until the ticket moves to a step associated with a different stage, at which point the shared stage is marked Complete.
You can see the steps awaiting your approval — either individually or on behalf of a group — in the My Approvals section of the My Work application in Work Management.
Requestors can similarly view the steps awaiting their approval in the My Approvals section of the Services tab in the Client Portal.
As the ticket moves through the workflow, its current state is displayed on the ticket's General tab. Steps currently awaiting user interaction appear in the Current Activities section.
All actions taken on the workflow are recorded in the ticket feed. If a workflow is removed from a ticket or replaced by a different workflow, the feed entries remain, but the detailed workflow status and history information will no longer be accessible.
High-level workflow information can be retrieved and filtered on for each ticket in Ticket Report Builder Reports under the Workflow section of available columns.
Even though a copy of the workflow configuration is made each time it is applied to a ticket, the system stores a reference to the underlying workflow, steps, and stages. This allows you to filter on the associated workflow configuration, current stage, or current step. This reference is maintained even if the original workflow, step, or stage is later reconfigured. For example, if a step named CAB Approval is later renamed to ECAB Approval, filtering on ECAB Approval will still match the CAB Approval step on tickets where the original workflow was applied.
To manually assign a workflow to a ticket:
- In Work Management, click View Applications, then select the specific Ticketing application.
- Locate the desired ticket.
- Click Actions > Assign Workflow at the top of the ticket.
During workflow assignment, you will see a Convert this Ticket to a Service Request checkbox. If you select this option, any existing parent/child relationships and maintenance activities are removed from the ticket, as these are not valid for Service Requests. If the first step of the workflow is configured as the Classification Promotion step, the ticket is not converted to a Service Request upon assignment — this exception does not apply during ticket creation.