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 support@appfire.com
Expiry Dates
Overview
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:
- State expiry date
- Task expiry date
- Messages – they just disappear after expiring
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.
Units | 5 * Unit |
---|---|
Years | 5Y |
Months | 5M |
Weeks | 5W |
Days | 5D |
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} {state:Current|expired=Stale|duedate=P3M|changeduedate=true} {state} {state:Stale|expired=Expired|completed=Updated|duedate=P1D|changeduedate=true} {task:name=Update state about to expire|duedate=PT18H} {state} {state:Expired|completed=Updated} {state-selection:states=Current|permission=ADMINISTER} {state} {state:Updated} {state} {trigger:taskexpired} {set-message:duration=PT6H}Task expired "@taskname@"{set-message} {trigger} {trigger:stateexpired|state=Stale} {set-message:duration=P2W1D} "@state@" state expired with @duedate@ Please update content and set all tasks as completed. {set-message} {trigger} {trigger:statechanged|state=Current} {set-message}{set-message} {trigger} {trigger:statechanged|state=Updated} {set-state:Current} {trigger} {workflow}
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
Notes:
- Can only be used on
duedate
parameters or Value References - The time is in 24-hour format.
- The time zone is based on that set in the Java Runtime Environment in which Confluence runs.
An example is shown below:
{workflow:name=Example} {state:Already expired|duedate=2020-11-20 13:05|expired=Expired} {task:Already expired|duedate=2020-11-20 13:05} {state} {state:Expired} {state} {trigger:stateexpired|state=Already Expired} {set-message}State expired: @state@{set-message} {trigger} {trigger:taskexpired} {set-message}Task expired: @taskname@{set-message} {trigger} {workflow}
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.
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} P1M {workflowparameter} {state:Will expire|duedate=@Task Duration@} {state} {workflow}
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.
Macros
The following macros have parameters or settings which support expiry dates:
-
set-message macro — Add/remove a page message
-
set-state-expiry macro — Set state expiry duration
-
state macro — Define workflow states & basic transitions
-
task macro — Add tasks to workflow states
-
workflowparameter macro — Define editable workflow Value References
For a summary of how expiry dates interact with these macros, see: Expiry Dates - Macros.
Notifications
By default, page watchers and task assignees will receive notifications when states or tasks expire.
For more information, see the App configuration section below.
Events
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}
expiredtaskexpired
– a{task}
expired
You can use these events to Trigger one or more Actions.
Examples:
-
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.
Pseudo-users
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:
Pseudo-user | Where | Notes | |
---|---|---|---|
Comala Document Management | Activity Report - Content | The user associated with entries relating to state/task expiry | |
Anonymous | Comments, Notifications | Any 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
Setting | Where | Notes |
---|---|---|
State Expired Notification | Should page watchers receive notifications when a state expires? | |
State's Task Behaviour | Should tasks be retained when transitioning to a new state? | |
Task – Assignee | Should task assignees receive notifications when a task expires? | |
Task – Page Watchers | Should page watchers receive notifications when a task expires? |
Examples
-
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
-
State expiry dates — Using state expiry dates, defining them with metadata, and making them editable