Configuring Ticket Workflows

Overview

Ticket workflows can support many different business processes in TeamDynamix, such as approving equipment purchases, granting application access, or supporting a change management process. They can even be used to integrate with other systems. Because each ticket receives its own copy of a workflow at the time it's assigned, changes you make to a workflow afterward only affect tickets assigned going forward — see How Workflow Changes Affect Assigned Tickets below for more.

You will need:

• An understanding of your business process
• TeamDynamix Administrator access
• Access to a ticketing application in Work Management

In this article, we'll cover:

• Creating a Ticket Workflow
• Checking Out a Workflow
• How Workflow Changes Affect Assigned Tickets
• Configuring Workflow Properties
  • Stages
  • Workflow Details
  • Associating with Services
• Types of Ticketing Workflow Steps
• Adding Steps to a Workflow
• Connecting Workflow Steps
• Validating a Workflow
• Activating a Workflow
• Scenarios Where Services Fail to Assign a Workflow

Creating a Ticket Workflow

Before adding steps and actions, you need to create the workflow itself, which serves as a container for the steps.

To create a workflow:

1. Open the Ticketing application admin UI:
   • Ticketing Application Admins: In Work Management, click View Applications, select the Ticketing application, click the gear icon in the top-right corner, then select Admin from the menu
   • Global Admins: In TDAdmin, go to Applications, then select the Ticketing application
2. In the left navigation, click Workflows.
3. On the Ticket Workflows page, click the +New button.
4. In the New Ticket Workflow window, enter a value in the Name field and a description.
5. Click Save.

When the new ticket workflow is created, it will automatically be checked out to you, the creator.

Checking Out a Workflow

If you want to edit a previously created workflow, it must be checked out. If a workflow is already checked out to someone else, their name will appear by the “Checked out to” label on the right side of the Builder toolbar.

To check out the workflow:

1. In the Ticketing application admin UI, navigate to the Workflows page.
2. On the Ticket Workflows list, click the name of the desired workflow.
3. On the Workflow Details page, click the View Builder button.
4. In the Workflow Builder, click File in the toolbar.
5. Select Check Out from the dropdown.

A workflow can be edited once it is checked out. When others view the workflow while it is checked out, they’ll see the draft version the user has saved so far.

If a workflow has been left checked out by someone and they cannot be contacted to check it in, a Force Check In option is available on the workflow details page.

How Workflow Changes Affect Assigned Tickets

When a ticket is assigned to a workflow, TeamDynamix creates a copy of that workflow's configuration and applies it to the ticket. Because of this, any changes you make to a workflow's configuration afterward apply only to tickets assigned to the workflow going forward — they don't affect tickets that already have the workflow applied.

This also applies to names referenced within the workflow. Group names and person names are copied onto each ticket's workflow copy at the time of assignment, so if a referenced group or person's name changes later, that change won't appear on tickets that already have a workflow copy — only tickets assigned to the workflow after the name change will show the update.

Configuring Workflow Properties

You configure workflow-level settings — including stages, classification promotion, and status/notification behavior — from the Workflow menu in the Workflow Builder toolbar. Changes you make to any of these settings take effect only after you check the workflow draft back in, and even then, they apply only to tickets assigned to the workflow going forward; they don't affect tickets already in progress on that workflow.

Stages

Stages group a series of workflow steps to give requestors a quick, high-level summary of a ticket's progress. Because stages are visible in the Client Portal, they let you communicate where a request stands without exposing the internal complexity of your workflow.

Stage status is distinct from workflow status. Each stage has its own status — Pending, In Process, or Complete — that reflects its position in the workflow's progress.

When a workflow starts, all of its stage statuses are set to Pending. From there, TeamDynamix manages stage status automatically:

• When a step associated with a stage starts, the stage's status changes 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 changes to Complete. If several sequential steps share a stage, the stage remains In Process until every step in that stage has finished.
• When a step is rejected, and the next step that starts belongs to a different stage, the rejected step's stage reverts to Pending.

When you create a new ticket workflow, it automatically inherits any Default Ticket Workflow Stages configured for the Ticketing application, if set up.

To create a new stage:

1. On the Workflow Builder page, click Workflow in the toolbar, then select Stages.
2. Click New Stage, add a name and optional description, then click Save.

To modify an existing stage:

1. Click Edit under the stage name in the Edit Ticket Workflow Stages window.
2. Reorder stages using the Move Up and Move Down buttons, or by dragging and dropping.

Workflow Details

The Promotion Classification, Approval/Rejection Status, Notification, and Submission settings are configured together under Workflow > Details.

Promotion Classification

A workflow can change a ticket's classification when a step starts, when a step is approved or completed, or when the entire workflow is approved. Because some classifications support features that others don't, TeamDynamix uses classification promotion to prevent inadvertent data loss — tickets can only move upward through the classification hierarchy, never downward.

The classification hierarchy, from highest to lowest, is:

1. Release
2. Change
3. Problem
4. Incident
5. Service Request

This means:

• A Service Request can be promoted to any other classification.
• Nothing can be promoted to a Service Request.
• A ticket can only be promoted upward through the hierarchy above.

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 doesn't change, because Release already sits above Change in the hierarchy.

A classification's display name may differ depending on your organization's customizations, but the underlying System Type determines the hierarchy above.

If you select Step Starts or Step is Approved/Completed as the Promote Classification When option, you must also select a Classification Promotion Step. If you want a ticket to remain classified as a Service Request after the workflow completes, you don't need to configure a Promotion Classification on the workflow.

Approval/Rejection Status

These settings control how a ticket's status updates automatically based on the outcome of a step:

• Approval Status: if the ticket is approved, it's automatically changed to this status.
• Rejection Status: if the ticket is rejected, it's automatically changed to this status.

Each field offers a dropdown of the ticket statuses available in your environment (for example, New, Assigned, In Process, On Hold, Pending Customer Response, Customer Responded, Resolved, Closed, and Canceled).

Notification Options

These settings control who's notified when the workflow completes and the ticket updates as a result:

• Notify Requestor: automatically sends the requestor a notification when the ticket updates upon completion of this workflow, keeping them informed of the outcome without manual follow-up.
• Notify Reviewer: automatically sends the reviewer a notification when the ticket updates upon completion of this workflow, so they're aware of the ticket's final status and any resulting changes.

Submission Options

This setting determines whether this workflow can be used with tickets submitted by certain types of requestors.

• Public and Read-Only Requestors: When enabled, the workflow can be assigned to tickets submitted by requestors who are public, read-only, or omitted. This allows workflows to be used in broader scenarios where the requestor might not have full access or visibility into the ticketing system.

Configuring the Workflow Details

To configure workflow details:

1. On the Workflow Builder page, click Workflow in the toolbar, then select Details.
2. Select a Promotion Classification from the dropdown. Additional required fields appear.
3. Select a Promote Classification When option.
   • If you select Step Starts or Step is Approved/Completed, also select a Classification Promotion Step.
4. Select an Approval Status.
5. Select a Rejection Status.
6. Enable or disable the Notify Requestor and Notify Reviewer notification options.
7. Optionally, enable Public and Read-Only Requestors.
8. Click Save.

Associating with Services

A workflow can be associated to any service that has been configured to create a request in the Ticketing application where the workflow resides. Associating or disassociating a workflow with a service does not require that the workflow is checked out, and changes take effect immediately.

Enabling Workflows for Public Forms

By default, tickets submitted through public forms don't automatically have a workflow applied. To allow a workflow to run on tickets created by public forms, enable the Public and Read-Only Requestors submission option described under Submission Options above.

See Using Ticketing Forms in the Service Catalog for more details.

Types of Ticketing Workflow Steps

There are 11 types of steps that may be used in ticketing workflows, and a single workflow might use several different types.

• The Approval Step sends a notification to one or more approvers and waits for them to decide how the workflow should proceed. The approver can approve or reject the step, which can branch the workflow into two paths. If approved, it could go down path A; if rejected, it follows path B.
• The Branch Step allows administrators to more easily manage branches in workflows with multiple paths. Different steps can then branch into separate paths, allowing tasks and other activities to run in parallel rather than in sequence.
• The Choice Step presents a user or group with multiple choices in order to progress through a workflow.
• The Collector Step joins several paths of a workflow (typically created via a Branch step) and waits for ALL of the paths preceding it to complete.
• The Condition Step automatically routes a ticket one way or another based on the ticket’s values.
• The Notification Step automatically sends a notification to one or more recipients.
• The Task Step adds a ticket task to the ticket with the settings defined in the workflow.
• The TeamDynamix iPaaS Step allows those organizations that have configured iPaaS flows to integrate a ticketing workflow directly with flows built in the TeamDynamix iPaaS product.
• The Timer Step creates a waiting period. The workflow will pause until the designated time has elapsed. When it expires, it will move on to the next step.
• The Update Ticket Step automatically applies changes to the ticket the workflow is running on — such as updating its status or responsibility, adding a comment and notification, or setting custom attributes — before the workflow moves to the next step.
• The Web Service Step allows organizations to automate processes by calling an external RESTful web service.

Adding Steps to a Workflow

The Workflow Builder is a graphical tool that lets you create, arrange, and connect workflow steps. Every workflow has two default steps: Approve and Reject. A ticket will move through the process and conclude at one of these two points. As additional steps leading to the final Approve or Reject steps are added, each will need a name, type, conditions, and, optionally, a stage.

When you choose a step type, the New Workflow Step form will update to include the appropriate fields. A step's type cannot be changed after it is created.

A workflow can have up to 250 steps. The Workflow Builder will begin warning you when you reach 75% of this limit. You can add steps beyond this quota and save the draft, but you will not be permitted to check in the workflow until it meets the quota.

To add a step to a workflow:

1. In the Ticketing application admin UI, navigate to the Workflows page, and click the Workflow name.
2. Click the View Builder button and check the workflow out if it isn’t already.
3. Click the New Step button in the toolbar.
4. In the New Workflow Step window, enter a Name that indicates what the step will do.
5. Select the step Type from the dropdown.
6. If Stages have been configured (see Stages above), optionally select one from the dropdown. If no Stages are configured, this field will not appear.
7. Optionally enter a Description for the workflow step
8. Click the Save button and close the Workflow Step window.

The new step will now appear as a box on the left side of the Workflow Builder screen. The first step that is added will automatically be light blue and designated as the first step.

To mark a different step as the start:

1. Click the gear icon in the top right corner of the step.
2. Select Mark as Start from the dropdown.

Note that a Collector step cannot be used as a starting step.

Once you've added a step, refer to that step type's individual article — linked in Types of Ticketing Workflow Steps above — for details on configuring and using it.

Connecting Workflow Steps

Each step's type determines which options appear as rows within its box in the Workflow Builder. For example, a Condition step has Condition Met and Condition Not Met, an Approval step has Approve and Reject, and a Task step has only Complete.

You connect steps by dragging an option from one step to the next in the sequence; a line appears to show the connection. A step cannot directly link to itself. Each option can connect to a different next step, which is how a workflow branches. For example, if step A is an Approval step, its Approve option might connect to step B, a task that must be completed, while its Reject option connects to a different step C, which notifies the requestor that the request was rejected.

To connect two steps:

1. Click and hold an option on the step  (an arrow icon appears).
2. Drag the option to the appropriate next step in the process.

To remove an existing connection between two steps:

1. Click the line connecting the two steps.
2. Click the Delete button.
3. Click OK on the confirmation popup.

Once you've added and connected all the steps your workflow needs, you're ready to validate it before checking it in.

Validating a Workflow

To activate a workflow, it must be valid. TeamDynamix flags two categories of issues when you validate a workflow: errors, which block activation, and warnings, which don't block activation but can indicate a misconfigured workflow.

Errors

A workflow will be invalid and generate an error if any of the following are true:

• There are no steps configured.
• A start step has not been designated.
• The start step is a Collector step.
• There is no path from the starting step to the final "Approve" step.
• One or more steps are not connected to the workflow.
• An Approval or Task step has not been assigned.
• An Approval, Branch, Collector, or Timer step has an option that isn't connected to any next step.
• A single step option links to both the final "Approve" and "Reject" steps.
• A Web Service step is not associated with a web service.
• A step with the Promote Classification When setting set to "Step Starts" or "Step is Approved/Completed," doesn't have a Classification Promotion Step included.
• The workflow has more than 250 steps.

Warnings

The following aren't necessarily errors, but can indicate a misconfigured workflow:

• No path exists from the starting step to the final "Reject" step.
• In an Approval step, the Approve and Reject options share one or more next steps.
• There is a cycle composed solely of Approve and automated actions.
• There is a cycle composed solely of Reject and automated actions.
• A Task or Web Service step links to an invalid step.
• At least one step has no path leading to it from the starting step.

These warnings are generally skipped when more serious errors are detected.

When finished editing a workflow within the Workflow Builder, click File, then select the Save and Check-in action to automatically run the validation. Any errors or warnings will be listed and explained.

When viewing the list of validation errors and warnings, hovering over each message will highlight the step (or steps) that are in violation in the Workflow Builder. Top-level issues, such as the lack of a Promotion Classification, must be remedied through the Workflow > Details menu option, and therefore, the Workflow menu option is highlighted for such issues.

If you are in the process of developing a workflow and would like to test your steps as you edit, you can manually validate it.

To manually validate a checked-out workflow, click File in the toolbar, then select Validate from the dropdown.

To save an invalid workflow so you can continue working on it later, click the File menu and select Save Draft.

Activating a Workflow

A workflow can be activated or deactivated, regardless of whether it's checked out.

To activate a valid workflow:

1. In the Ticketing application admin UI, navigate to the Workflows page and click the workflow name.
2. On the Workflow Details page, click the Activate button.

The workflow will now display as Active.

To deactivate an active workflow:

1. In the Ticketing application admin UI, navigate to the Workflows page, and click the workflow name.
2. On the Workflow Details page, click the Deactivate button.

The workflow will now display as Inactive.

Deactivating a workflow only affects new tickets going forward — it stops the workflow from being applied to tickets assigned after that point. Tickets already in progress on the workflow at the time it's deactivated aren't interrupted; they continue running through the workflow until they finish.

Scenarios Where Services Fail to Assign a Workflow

In most cases, a service automatically assigns its configured workflow to a ticket. In a couple of scenarios, though, that assignment can silently fail. It's worth knowing what these look like so you can rule them out if a workflow you expect to see isn't appearing on a ticket.

A form's default Service value conflicts with the expected workflow

The most common cause is that the form assigned to your service has a default value set for the Service field — one that differs from the service actually being requested, or that points to a different workflow than the one your service is configured to assign. When this happens, the ticket's workflow assignment follows the form's default rather than the service the requestor selected. To prevent this, check the form's Service field default whenever a service isn't triggering the workflow you expect.

The requestor is a Read-Only value

This scenario applies to services that are configured for public requests. If Requestor Name Matching isn't enabled on the service — specifically, the option that creates a People record when the entered email doesn't match an existing one — a public requestor whose email doesn't match an existing record is stored as a Read-Only Requestor value rather than a real user account.

Because workflows can include approval steps that depend on having a recognized requestor to hold responsible, TeamDynamix can't safely assign a workflow when the requestor isn't a valid account — there'd be no one to assign as the approver's counterpart. Rather than let the workflow start and break partway through, the workflow is withheld entirely in this case, whether the assignment was attempted by the service itself or by an automation rule.

To prevent this, enable Requestor Name Matching (with the option to create a People record for unmatched emails) on any service that's publicly requested.