This site has moved to the integrated Appfire documentation and information site for our apps.

From February 2024 this site is no longer updated.

Take a look here! If you have any questions please email

Expiry Dates


Expiry dates (due dates and durations) can be set for States, Tasks and {set-message} macro notifications.

You can see how expiry dates are visualized in the user interface:

Date formats

Expiry dates can be set using either a duration code or by specifying a specific date and time.

Duration codes (ISO 8601)

The duration code says "From the current time, wait for this amount of time before expiring".

When the state is entered, or a task or message is created, the duration code is internally converted to a date and time (based on the current time plus the duration). You don't need to know the exact date and time in advance; the workflow will work it out for you.

The duration is specified by a code starting with "P" (for Period) followed by codes for the number of Years, Months, Weeks and Days, or any combination of those.

Units5 * Unit

For example, a Period of 2 Weeks and 1 Day (a total of 15 days) would look like: P2W1D

An example is shown below for the following workflow.

{workflow:name=Example Expiry}
        {task:name=Update state about to expire|duedate=PT18H}
        {set-message:duration=PT6H}Task expired "@taskname@"{set-message}
        "@state@" state expired with @duedate@
        Please update content and set all tasks as completed.

The Current state content is set to expire after 3 months. On expiry the Current state transitions to the Stale state for triage.

The Stale state has

  • a duedate of 1 day
  • a task added by the workflow with a due date of 18 hours

The expiry of the due date for the task causes a trigger to display an on-screen message. The message is displayed for a duration period of 6 hours.

Note: It is also possible to specify hours and minutes; for more information, see: Full ISO 8601 Duration Specification

Date and time

To set a specific date and time, use the following format: YYYY-MM-DD HH:mm

For example, 1:05PM on the 20th November 2020 would be: 2020-11-20 13:05


An example is shown below:

   {state:Already expired|duedate=2020-11-20 13:05|expired=Expired}
     {task:Already expired|duedate=2020-11-20 13:05}
   {trigger:stateexpired|state=Already Expired}
      {set-message}State expired: @state@{set-message}
      {set-message}Task expired: @taskname@{set-message}

In the example above, the dates are all in the past, so, for example, the "Already expired" state will already be expired when the workflow enters that state; it won't cause any events, and it won't transition to the "Expired" state, so no messages will be shown. The same is true for the tasks.

This may not seem like it would have much value on its own, it would be pretty unlikely that you know the exact date you want a state to expire when setting up a workflow.  But the value in the macro can be set by Value References. This now allows you to get the date from some other source, such as a workflow parameter, page properties or other metadata.


Using metadata, you can obtain expiry dates from other sources or make them editable.

{workflow:name=Custom dates}
   {workflowparameter:Task Duration|type=duration|edit=true}
   {state:Will expire|duedate=@Task Duration@}

In the example above, a "Task Duration" parameter is defined with a default duration of P1M (one month). This can be edited by anyone with Edit permission on the content, via the workflow popup (due to the edit=true parameter).

For example, if we wanted a 2 month (P2M) duration:

As mentioned above, expiry dates can also be set using Value References, including Supplier References and Metadata references.


The following macros have parameters or settings which support expiry dates:

For a summary of how expiry dates interact with these macros, see: Expiry Dates - Macros.


By default, page watchers and task assignees will receive notifications when states or tasks expire.

For more information, see the App configuration section below.


When a state or task expiry date is reached, only if the state or task is active at the time it is reached, one of the following Events will be sent:

  • stateexpired – a {state} expired
  • taskexpired – a {task} expired

You can use these events to Trigger one or more Actions.


  • Page:
    State expiry dates — Using state expiry dates, defining them with metadata, and making them editable

User interface

Depending on workflow configuration, expiry dates can be edited by users and/or admins in the following places:

Filter by label

There are no items with the selected labels at this time.


When a state or task expires, it's not a direct result of human interaction. As such, events and actions arising from the expiry are not associated with a user account.

To handle this situation, the Document Management app uses two pseudo-users:


Comala Document Management

Activity Report - ContentThe user associated with entries relating to state/task expiry


Comments, NotificationsAny notifications or comments arising from state/task expiry

For example, the Comala Document Management pseudo-user is shown in the page activity report below for the expiry event transition to the Stale state and the workflow created task added to this state.

App configuration

State Expired NotificationShould page watchers receive notifications when a state expires?
State's Task BehaviourShould tasks be retained when transitioning to a new state?
Task – AssigneeShould task assignees receive notifications when a task expires?
Task – Page WatchersShould page watchers receive notifications when a task expires?


  • Page:
    Communardo Metadata for Confluence app — Using the Communardo metadata as value references in a workflow - including use in a custom condition for a trigger macro
  • Page:
    State expiry dates — Using state expiry dates, defining them with metadata, and making them editable

See also

Workflow Authoring Guide:

User Guide:

Reporting Guide:

Integration Guides: