Notification Step

In this article, we'll cover:

• Overview
• Where to Find This
• Using the Notification Step
  • Recipients
  • Notification Template
  • Configuring a Notification Step
• Examples

Overview

The Notification step automatically sends an email notification to one or more recipients or recipient roles when the workflow reaches this step. It uses a notification template specific to the workflow step, letting you customize the notification content. 

In the workflow pictured above, a Web Service step's Failure option leads to a Notification step — a common pattern for alerting someone when an automated action doesn't succeed as expected.

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

Where to Find This

The Notification 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: TDAdmin > Applications > [name of 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 > Ticket Requests > open the request and review the workflow steps

Using the Notification Step

Recipients

You can specify direct Recipient(s), Recipient Role(s), or both — a Notification step isn't limited to a single method for choosing recipients.

Recipient(s) are specific people or groups who receive the notification directly. When a group is selected, only its members with access to the ticketing application can receive the notification on the group's behalf. To select a Client Portal user as a recipient, use the lookup (magnifying glass icon) rather than the type-ahead field — Client Portal users are intentionally excluded from type-ahead suggestions to keep results focused on ticketing application users.

Recipient Role(s) let you configure recipients that depend on the ticket's values rather than being fixed in advance. As with direct recipients, if a role evaluates to a group, only members of the group with access to the ticketing application can receive the notification on the group's behalf.

A role won't add a recipient in a few specific situations:

• The person the role points to isn't an active User record or has been deactivated.
• The group the role points to has been deactivated, or has no one available to receive the notification.
• A "Manager" role evaluated relative to the Requestor resolves to the requestor themselves — this prevents manager-based notifications from going to a requestor who happens to be acting as their own manager.

The Department Manager role is based on the ticket's account/department value, not on the requestor.

When none of the selected Recipient Role(s) evaluate successfully, the notification falls back to whoever is configured in Fallback for Recipient Role(s).

Fallback for Recipient Role(s) specifies who receives the notification if none of the Recipient Role(s) evaluate successfully. The same access restriction applies here as with Recipient(s) — only individuals with access to the ticketing application can receive the notification on behalf of a group — and the same lookup requirement applies for adding a Client Portal user as a fallback recipient.

If you select one or more Recipient Role(s), you must also select at least one resource in either Recipient(s) or Fallback for Recipient Role(s), so the notification always has somewhere to go, even if every role fails to resolve.

Keep in mind that a Notification step sends to every configured recipient each time it runs — there's no way to conditionally exclude a subset of recipients from a given notification.

Notification Template

The Notification Template section lets you configure the notification that the workflow sends. It works the same as notification templates defined elsewhere in the system, except that there's no default message here — you need to provide your own Subject and Body.

Both the Subject and Body fields are required, and both allow you to use template tags — the available ticket details, encapsulated in curly brackets (for example, {{FieldName}}), that pull ticket data into the notification. All available fields for a Notification step template appear in the Insert Template Tag dropdown. For a full list of supported tags and their behavior, see Ticketing Notification Template Tags and Managing Ticketing Notification Email Templates.

Custom attribute tags work a little differently: inserting {{CustomAttributes}} directly won't display anything. Instead, you need the {{#CustomAttributes}} and {{/CustomAttributes}} start/end tags, with {{Name}} and {{Value}} placed in between — this defines an "area" for custom attributes, since a ticket can have more than one. Clicking CustomAttributes from the dropdown inserts the start/end tags, but not the Name or Value tags, so you'll need to add those yourself. See the Custom Attributes section of the Managing Ticketing Notification Email Templates article for the full syntax and examples.

Once you've entered your Subject and Body, click Generate Preview to see how your template tags resolve using sample ticket data, shown below the button as a preview of the actual text.

Configuring a Notification Step

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

To create a Notification step:

1. In the Ticketing application admin UI, click Workflows in the left navigation.
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 in the toolbar.
7. In the New Workflow Step window, enter a Name that indicates what the step will do.
8. Select Notification Step from the Type dropdown.
9. If Stages have been configured for the workflow, optionally select one from the Stage dropdown.
10. Optionally provide a Description for the step.
11. In the Recipient(s) field, search for and select one or more specific people or groups to receive the notification directly, and/or in the Recipient Role(s) field, select one or more relative roles whose assigned person or group should receive it.
12. If you selected a Recipient Role, the Fallback for Recipient Role(s) field appears. If you haven't already specified direct Recipient(s), you must select at least one fallback here so the notification always has a guaranteed recipient.
13. Under Notification Template, use the Insert Template Tag dropdown to add dynamic values, such as the requestor's name, into your Subject and Body.
14. Enter the Subject and Body of the notification.
15. Optionally, click Generate Preview to confirm that your template tags resolve as you expect.
16. Click Save, then close the window showing the Notification step details.
17. Locate the new Notification step in the Workflow Builder. It should be on the far left side, often on top of the Start step.
18. Click the directional arrows in the corner of the Notification step and drag it to the desired point in the workflow.
19. Click and drag from the step option of the previous step to create the connection to the Notification step.

Examples

Some workflows benefit from specific communication points throughout the lifecycle, such as letting a user know their request was approved or rejected, or adding a step to let someone know a chunk of work is coming at a certain interval to set expectations.

The Client Response Timer workflow pictured below uses Notification steps to remind an unresponsive requestor that a ticket is waiting on them. Rather than specifying a direct Recipient, this example uses the Requestor Recipient Role, since the same workflow is applied across many different tickets with different requestors, and configures a Fallback for Recipient Role(s) in case that data is missing. The example also links to sample HTML notification content you can adapt for the Subject and Body fields. See the Client Response Timer Workflow Example for full setup details.

In the New Hire Request workflow below, the "Send Hiring Manager account info" Notification step runs when the TeamDynamix iPaaS step's Success option completes, and its Complete option feeds into the "Wait for all tasks to be completed" Collector alongside the workflow's other parallel tasks.

Click to open the PDF and view the workflow details.