Client Response Timer Workflow Example

In this article, we'll cover:

•  Overview
• Where to Find This
• Building a Client Response Timer
  • Workflow Design
  • Create the Timer Steps
  • Create the Condition Steps
  • Create the Notification Steps
  • Arranging the Steps in the Workflow
  • Finalize the Workflow Configuration
• Putting the Workflow to Work
  • Automation Rule Applied Workflow
  • Manually Applied Workflow

Overview

Sometimes, during IT service delivery, submitted tickets go cold, and the requestor becomes unresponsive to requests for more information or action needed to complete the request. In short, the requestor "ghosts" the service delivery team. This is common when a requestor submits a support request for an issue that self-resolves or is solved with a simple action (for ex., restarting a laptop), and they no longer need it and forget the original request.  When this happens, it can be frustrating and wastes resources to continually monitor the ticket, send follow-up notifications, and ultimately close it due to inaction. This example shows how you can use specific TeamDynamix settings in conjunction with a workflow to let the system send necessary reminders to the requestor and ultimately close the ticket if the requestor has truly abandoned it.  This can also help you report how often this occurs and whether there are repeat offenders.  

Workflows are configured from the Ticketing application admin interface accessed by following these paths:

• Ticketing Application Admins: Work Management > View Applications > [name of the Ticketing application]  > gear icon > Admin > Workflows
• Global Admins: TDAdmin > Applications > [name of the Ticketing application]  > Workflows

Building a Client Response Timer

This example walks through building the workflow steps, configuring the related Ticketing application settings, and applying the finished process to your tickets.

The workflow itself uses 9 steps to build a repeating wait > check status > notify requestor loop, and its own settings automatically close the ticket if the requestor doesn't take action within the allotted time. Additionally, the Ticketing application must be configured to automatically take tickets off hold when the requestor does respond, so the workflow's Condition steps can detect that response accurately.

Workflow Design

1. Navigate to the admin interface for the Ticketing application you're building this workflow in (see Where to Find This for the two admin paths).
2. In the left navigation, click Workflows.
3. On the Workflows page, select the green + New button at the top of the page.
4. Provide a Name; remember, this is the name your technicians will use to identify the workflow.
5. If desired, add a Description or Purpose to give more context on the intended use.
6. Click Save.
7. Click the new workflow’s name on the workflow list to open it.
8. Click the green View Builder button.

Create the Timer Steps

Create three Timer steps that serve as the waiting period, giving the requestor time to respond. These time frames are flexible — adjust them longer or shorter to fit your needs. This example uses a 3-day wait based on operational hours for each Timer step.

1. In the Workflow Builder, click File > Check Out if it’s not already checked out. See Configuring Ticket Workflows for more on checking workflows in and out while you edit them.
2. Click the New Step button in the toolbar.
3. Give the step a Name that indicates its duration (for example, "Wait 3 Days").
4. In the Type dropdown, select Timer.
5. Add a Description, if desired.
6. Enter the Timer Duration in days, hours, and/or minutes (for ex., "3 Days”).
7. Select Use Operational Hours so the duration accounts for non-working hours, weekends, and organizational days off rather than counting continuously. This field is optional for a Timer step, but this example uses it for all three Timer steps to keep the wait periods limited to business days.
8. Click Save, then close the popup.

Repeat these steps to create three identical Timer steps.

The Timer step configuration should look like this:

Create the Condition Steps

Each of the three Condition steps checks whether the ticket is in an On Hold status. If it is, the condition is met, and the workflow moves to the Notification step below it. If the status is anything other than On Hold, the condition is not met—meaning someone has updated the ticket—and the workflow moves to the Reject end, closing without making any further changes to the ticket.

1. In the Workflow Builder, click the New Step button.
2. Give the step a Name that indicates its purpose (for example, "Status Check").
3. In the Type dropdown, select Condition.
4. Add a Description, if desired.
5. Under Conditions, type “Status” in the Column field and select the Status standard attribute.
6. Set the Operator value to "is one of".
7. In the Values field, select an On Hold classification of status.
8. Click Save, then close the popup.

 Tip: Consider creating custom statuses to indicate a ticket is waiting on the requestor, such as "Waiting on Requestor." This improves clarity and helps with the workflow steps below. Create the status with an On Hold status class in the Ticketing app admin interface > Statuses. Remember, you cannot delete statuses once created; you can only deactivate them. For more info on statuses, see the Ticket Statuses article.

Repeat the steps above to create three identical Condition steps.

The Condition step configuration should look like this:

Create the Notification Steps

Create three Notification steps; the first two are reminders prompting the requestor to take action, and the third is a notice that the ticket is being closed. Each message can be tailored.

1. In the Workflow Builder, click the New Step button.
2. Give the step a Name that indicates its purpose (for example, "Notify Requestor of Need for Response").
3. In the Type dropdown, select Notification.
4. Add a Description, if desired.
5. Because this workflow will be used on many different tickets with different requestors, skip the defined Recipients(s) parameter and use Recipient Role(s) instead. Choose Requestor for the role.
6. Define the Fallback for Recipient Role(s), used if no user matches the role for the ticket.
7. Enter the Subject of the email message. For example, “IT Dept - Your Ticket needs your response” or “{{ResponsibleName}} - The {{Title}} ticket needs your attention”.
8. Define the message body using HTML. This can be a simple text string or something more complex. The "Response Request Notification HTML.txt" file attached to this article contains example code you can use; see Managing Ticketing Notification Email Templates for other options.
   • Note that the example file includes a logo URL. If you are not familiar with editing HTML, and you want to change that logo, start after the "</table>" on line 6.
9. Click Generate Preview as often as you like to see how your current design will display in an email.
10. Click Save and close the popup.

Repeat the steps above to create two identical Notification steps. The final notification will be different.

The Notification step configuration should look like this:

If you use the attachment HTML code, the preview will look something like this: 

Configure the final Notification step by repeating the steps above, with these differences:

• Name: indicate this is the final notice (for example, "Final Notification to Requestor").
• Subject: for example, "Ticket Closure Notification" or "Ticket Closure Notification - {{Title}}."
• Body: use the "Final Notification HTML.txt" file attached to this article, or design your own HTML.

Note: As with the first notification, the example file has a logo URL baked in — start after the "</table>" tag on line 6 if you want to change it. This example also includes a URL string for the Client Portal Service Catalog, currently pointing to https://solutions.teamdynamix.com. Change that URL to match your organization's Client Portal resources.

Your final Notification step should look something like this:

If you use the attached "Final Notification HTML.txt" code, your preview will look something like this: 

Arranging the Steps in the Workflow

At this point, all 9 steps should be created and visible in your workflow builder. Now, they need to be arranged and connected.

1. Use the four-arrow handle button at the top right of each step to move it around the screen.
2. Move the red Reject and green Approve ending blocks to the far right.
3. Stack the other steps in three columns with a Timer step at the top, a Condition step below it, and a Notification step below that.
4. The "Final Notification to Requestor" Notification step should be the last step at the bottom of the last column.
5. If the top left Timer step is not pale blue with the play icon next to its name, click the gear icon on the step and select Mark as Start.
6. Click Complete on the first Timer step, then drag to draw a connector to the Condition step directly below it.
7. Click Condition Not Met on that Condition step and drag all the way to the red Reject ending block to connect them.
8. Click Condition Met on that Condition step, then drag to the Notification below it to connect them.
9. Click Complete on that Notification step and drag up to the Timer step at the top of the second column.
10. Repeat the connection steps 6-9 for the second column steps:
    • Timer Complete > Condition step
    • Condition Not Met > Reject end block
    • Condition Met > Notification step
    • Notification Complete > Timer step (column 3)
11. On the final Notification step, "Final Notification to Requestor", connect Complete to the green Approve ending block.

Your workflow should look like the example below. For a clearer view of the workflow details, download the PDF ​​​​​​attachment, Client Response Timer Workflow Example.pdf.

Finalize the Workflow Configuration

These settings work together to make the workflow fully automatic. The workflow-level settings determine what happens to the ticket depending on whether the requestor responds, while the Ticketing application setting automatically takes the ticket off hold when they do—so you never have to change the status by hand for the workflow's Condition steps to catch it.

Set the Workflow Details

1. To finish the workflow design, click the Workflow dropdown in the top menu and choose Details.
2. In the Details popup, you can rename the workflow or add/adjust the description as needed.
3. Click the Approval Status dropdown and choose Closed.
4. Leave the Rejection Status blank; this lets the workflow stop after a client response without changing the Status.
5. Leave the Notify Requestor notification option enabled to automatically notify the requestor when the ticket is updated after this workflow completes.
6. Click Save.
7. In the Workflow Builder, click File in the top menu and choose Save and Check In to complete the design.

 Tip: Consider creating a custom status to indicate this ticket closure is not standard, such as "Inactive Closure". You will likely still want credit as a "completed" ticket when reporting, not canceled. Make sure to create the status with a Completed status class in the Ticketing application > Statuses. Remember, you cannot delete statuses once created — only deactivate them. For more information, see the Ticket Statuses article.

When the workflow is ready for use, open it from the Ticketing application admin interface > Workflows, then click the green Activate button at the top to make the workflow available. You can return and activate it at any time.

Ticketing Application Settings

Configure automatic handling to take tickets off hold.

Remember, these settings apply to all workflows in this Ticketing application. If you have multiple Ticketing applications, this won't affect the others.

1. Navigate to the Ticketing application admin interface (see Where to Find This for the two admin paths) and click Settings in the left navigation.
2. In the top General section, under On Hold Options, enable Automatically take tickets off hold when they are commented on. This setting allows the ticket to move out of On Hold status when a requestor takes the required action and ends the workflow.
3. Optionally, you can define the Automatic Off Hold Status. When an On Hold ticket automatically goes off hold, it moves to this status.
   • If you do define this, it is best practice to choose In Process or a custom status.
   • If you don’t set this status, it will move to the status it had before it was placed on hold.
4. Click Save.

Putting the Workflow to Work

You can put this workflow to work in two ways: triggered automatically through a Ticketing Automation Rule, or applied manually by a technician on a ticket-by-ticket basis. Either way, the workflow must be Active before it becomes available to use.

Note: A ticket can only have one active workflow at a time. Before applying this workflow — whether automatically or manually — confirm the tickets you're targeting don't already have another workflow in progress.

To verify a workflow is active, view the Workflows list in the Ticketing app admin interface. In the list, confirm the workflow shows “Yes” in the Active column. If it shows “No,” click the workflow name, then click the green Activate button at the top.

Automation Rule Applied Workflow

One of the most seamless ways to apply this workflow would be through a Ticketing Automation Rule. For this, you will need to create an Automation Rule in your Ticketing application that runs on ticket modification. If you choose this route, use a condition designed to trigger exclusively for this workflow—a custom attribute named something like "Waiting on Requestor" works well. You can use any condition stack you like, but make sure it always triggers this workflow.

Note: The workflow must be activated to be visible in the automation rule configuration.

Configure the Automation Rule

1. Start by identifying your condition; the best option is a specific custom status.  This should match the status you set in your Condition steps when building the workflow.
2. In the Ticketing application admin interface (see Where to Find This for the two admin paths), select AI and Automation, then Automation Rules in the left navigation.
3. Click the +New button.
4. On the New Automation Rule page, enter a Name that indicates what the rule does.
5. Under Applies To, choose Modify.
6. Click Save.
7. On the Detail page, click the Edit button.
8. Click the Active checkbox.
9. Under Automation Conditions, in row 1, type “Status” in the Column field and select the Status standard attribute.
10. Set the Operator value to "is one of".
11. In the Values field, select an On Hold classification of status.
12. Under Automation Actions, select your workflow from the Assign to Workflow dropdown.
13. Set any additional settings you want.
14. Click Save.

Technician Steps

1. Comment on the ticket, asking the requestor for the desired action or information; this is best done as part of a ticket update.
   1. Set the New Status to the On Hold classification of status used in the workflow’s Condition steps and the automation rule (for example, "Waiting on Requestor").
   2. Under Comments, uncheck the Make comment private box so the requestor can view it when they look at the ticket in the Client Portal.
   3. In the Notify field, select the Requestor.
   4. Click Save.
2. Now that the requestor has been notified, the comment is confirmed as public, and the ticket status is set to the On Hold classification of status, the automation rule should automatically assign the workflow to the ticket.
3. If the requestor responds, the status will automatically drop off On Hold based on the Ticketing application setting. When the workflow checks the status, it will find the ticket no longer On Hold and moves to the Reject end of the workflow, closing the workflow and making no further change to the ticket.
4. If a technician returns to the ticket before the workflow checks the status, they can:
   • Leave the workflow to stop itself in time.
   • Manually stop the workflow from the ticket Actions > Remove Workflow.
   • Use Actions > Reassign Workflow to restart the process if further communication is needed from the requestor.
5. If the requestor doesn't respond—by email or by commenting on the ticket through the Client Portal—the workflow waits out the defined timer periods and sends the reminder notifications. It ultimately sends the final notification, moves to the Approve end of the workflow, and closes the ticket to the complete status defined in the Workflow Builder.

Manually Applied Workflow

Alternatively, you can make this workflow available for technicians to apply to tickets individually, rather than relying on automation.

Note: The workflow must be active to be visible as an Assign Workflow option.

1. Comment on the ticket, asking the requestor for the desired action or information. This can be a standalone comment on the feed or part of a broader ticket update.
   • Notify the requestor and leave the comment public, so they can view it when they look at the ticket in the Client Portal.
2. Set the ticket's status to the On Hold status used in the workflow's Condition steps (for example, "Waiting on Requestor").
3. Click the ticket’s Action button and select Assign Workflow.
4. Select the Client Response Timer workflow from the dropdown and click Save.
5. If the requestor responds, the status automatically drops off of On Hold, based upon the Ticketing application setting. When the workflow checks the status it finds the ticket no longer On Hold and moves to the Reject end of the workflow, closing the workflow and making no further change to the ticket.
6. If a technician returns to the ticket before the workflow checks the status, they can:
   • Leave the workflow to stop itself in time.
   • Manually stop the workflow using Actions > Remove Workflow.
   • Use Actions > Reassign Workflow to restart the process if further communication is needed from the requestor. 
7. If the requestor doesn't respond — by email or by commenting on the ticket through the Client Portal — the workflow waits out the defined timer periods and sends the reminder notifications. It ultimately sends the final notification, moves to the Approve end of the workflow, and closes the ticket to the complete status defined in the Workflow Builder.