Description: This guide explains how to use Timestamp Transforms to convert a date or time placeholder into a target timezone and format before using it in an email, chat message, API request, attribute push, or custom script step.

Tags: Dynamic Workflow, Placeholders, Timezone, how-to

Estimated time to complete: 5 minutes

If you run into any problems, please contact your support team or support@claritysecurity.io.

Overview

Dates that travel through a workflow arrive exactly as the source system stored them — often in a raw form like 2026-08-06 14:00:00, and almost always in a different timezone than the person who’ll read them. Timestamp Transforms let you convert a date into the timezone your audience expects and present it in a readable format, then drop that result anywhere in the step.

For example, a termination date stored in UTC can appear in an offboarding email as “August 6, 2026 at 9:00 AM CDT” — in the employee’s own local time.

Before You Begin

• Timestamp Transforms are configured on a per-step basis, inside a step that already supports placeholders.

• You’ll need an earlier step in the same workflow that provides the date value you want to convert — for example, the workflow’s trigger step, or a prior action step.

Where Transforms Are Available

Transforms are available on every step that lets you write a message or payload using placeholders:

• Send Email and Send Configurable Email

• Send Configurable API Request

• Slack and Teams messages

• Push Static Application Attributes

• Trigger Custom Script

Open the step’s settings and find Timestamp Transforms near the bottom of the panel. Each step keeps its own transforms — a transform you create on one step isn’t available on any other step, so add it to the step where you want to use it.

How to Configure

Step 1: Add a transform

From one the the actions mentioned above, click Add a timestamp transform.

Step 2: Choose the value to convert

Under Value to convert, pick the date you want to convert. The list offers the values available from earlier steps in the workflow, grouped by the step they come from.

Step 3: Set the value’s format

Leave Value’s format on Detect automatically unless the value is an Active Directory FileTime — a very long number used by attributes like AccountExpires. Those must be selected explicitly, because they can’t be told apart from other numeric dates reliably.

Step 4: Set the source and target timezones

• Convert from timezone — the timezone the original value is in. This is only used when the value doesn’t already carry a timezone of its own. Leave it blank to treat the value as UTC.

• Convert to timezone — the timezone you want the result shown in. Leave it blank to change only the format and keep the original timezone.

Step 5: Choose a display format

Step 6: Name the result

Under Name this result, enter a name using lowercase letters, numbers, and underscores, such as hire_date_local. The editor shows you the placeholder you’ll use, for example {transformed.termination_date_local}.

Step 7: Check the preview

The Preview panel shows the converted result as you make changes, so you can confirm the output before the workflow ever runs. You can type your own sample value into the preview box; if you leave it empty it uses the current date and time in UTC.

Step 8: Save the transform

Click Save Transform. The transform appears as a row showing its placeholder and a summary of the conversion.

Using the Result

Once saved, the transform appears in the placeholder picker for that step’s fields, under This Step’s Transforms. Click it to insert the placeholder, exactly like any other placeholder. It works in email subjects and bodies, message text, API request bodies and URLs, attribute values, and script arguments.

You can add several transforms to one step — for example a hire date and a termination date in the same email. Each needs its own name.

Using a Timezone That Varies by Person

Both timezone settings have a From a value option. Switch to it when the timezone should come from the record rather than being fixed — for example an identity attribute holding each person’s own timezone. One workflow then serves people in every region.

Timezones taken from a value are worked out while the workflow runs, so the preview shows “resolved at runtime” for that setting instead of a computed time. Windows-style names that often come from Active Directory, such as “Central Standard Time”, are understood.

Tips & Best Practices

• Use Friendly for anything a person reads and ISO 8601 for anything a system reads. The friendly format always includes the timezone abbreviation, so the reader is never left guessing.

• If a value already includes a timezone (for example ending in Z or +02:00), that timezone wins and Convert from timezone is ignored. This is usually what you want.

• Dates with no time are only reformatted, never moved to a different day. A date like 2026-08-06 stays the 6th no matter which timezone you convert to.

• Nothing breaks if a conversion can’t be done. If a value isn’t a recognizable date, or a timezone taken from a record is empty or unrecognized, the step shows the original value and continues — your email still sends, your provisioning call still runs.

• When a result looks wrong, open the workflow execution and expand the step. It lists each transform with the value that went in, the value that came out, and — if a conversion fell back — the reason why.

Need Help?