Quick actions

In this page

Using the quick actions

There are several ways to take manual actions which affect the lifecycle of a page. Some of these manual actions are trivial and natural (e.g. editing), while others may require attention (e.g. modifying labels) or cannot be done via the built-in functions (e.g. modifying content properties). For example, if you mistype the label name and add the label arhive accidentally (note the missing "c"!), it will be ignored and nothing happens.

To ease working with the lifecycle of a page, the app offers so-called quick actions. Using these you can work in a friendly, controlled and less error-prone way.

This video gives a 3-minute introduction to quick actions:

Using quick actions while viewing pages

Quick actions appear in the bottom part of the Page Status Indicator. Secondary (less important) actions are hidden behind the "..." link to reduce the clutter on the interface.

After clicking one of the quick actions, you can configure its parameters and submit it with ease:

Note that different quick actions have different parameters:

Depending on its current status and on the quick action, the page's status may change immediately after submitting the quick action.

There are situations, however, when the status change is not immediate. For example, if you set a future date for expiration, then the page may remain "up-to-date" after submitting the quick action.

Finally, there are situations when there is no actual effect of the quick action. For example, if you set an archiving date for a page, but the assigned content status scheme does not use the arch.archivingDate field in any of its CQLs, then nothing is going to happen.

List of quick actions

The table below describes the quick actions and gives practical advices how to use them.

Action	How does it work?
Discuss	Coming soon!
Update	This action opens the page for editing (in the built-in editor). It should be used for those pages that became expired because haven't been updated for a long period and require an update. Effects After saving your changes, the page receives a new last update date. As a consequence, the expiration period restarts.
Confirm	This action confirms that the content of the page is still up-to-date and there is no need for an update. It should be used for those pages that became expired because haven't been updated for a long period, but don't require an actual update, because their content is still current. Effects The arch.event.lastUpdatedOn and arch.event.lastUpdatedBy content properties will be updated with the current timestamp and user. As the page receives a new last update date, the expiration period restarts.
Set owner	This action sets the user(s) who is responsible for the content in this page or in this page plus in its descendant pages. Owners can be notified of owned contents. This can be configured as a recipient group under the notification scheme. Effects The following content properties are updated, depending on the parameters selected in the dialog: arch.owner arch.owner.setBy arch.owner.setOn arch.treeOwner arch.treeOwner.setBy arch.treeOwner.setOn
Set expiration	This action sets the expiration date for the page and optionally for its descendant pages. Effects The following content properties are updated, depending on the parameters selected in the dialog: arch.expirationDate arch.expirationDate.inherited arch.expirationDate.setBy arch.expirationDate.setOn
Remove expiration	This action removes the expiration date from the page and its descendant pages (if applicable). Effects The following content properties are removed: arch.expirationDate arch.expirationDate.inherited arch.expirationDate.setBy arch.expirationDate.setOn
Set archiving	This action sets the archiving date (immediately or on a given date) for the page and optionally for its descendant pages. Effects The following content properties are updated, depending on the parameters selected in the dialog: arch.archivingDate arch.archivingDate.inherited arch.archivingDate.setBy arch.archivingDate.setOn
Remove archiving	This action removes the archiving date from the page and its descendant pages (if applicable) Effects The following content properties are removed: arch.archivingDate arch.archivingDate.inherited arch.archivingDate.setBy arch.archivingDate.setOn
Jump to ancestor	This action opens the ancestor page from which the current page inherits its status. For example, if the parent page specifies that the parent page itself and all its descendant must be archived on a given date, then a child page essentially inherits its status from the parent. In this case, you probably want to go to the parent and review the lifecycle settings of that. Effects The ancestor page is opened. (Even if it's not the direct parent, but the parent of the parent, this action makes the navigation super-easy.)
Exclude	This action excludes the page from lifecycle tracking. It should be used for pages with static, "always current" content. Effects The following content properties are updated, depending on the parameters selected in the dialog: arch.exclusion arch.exclusion.inherited arch.exclusion.setBy arch.exclusion.setOn
Include	This action includes a page, which was previously excluded, in lifecycle tracking. Effects The following content properties are removed: arch.exclusion arch.exclusion.inherited arch.exclusion.setBy arch.exclusion.setOn

Quick action triggered status changes

When you execute a quick action, the status of the page will be immediately recalculated. It results in an intuitive status change in most cases. For example, if you have a page that expired due to not being updated for 100 days and you use the "confirm" action, it becomes "up-to-date". So far, so good.

In some cases, however, the result may not look intuitive for the first look. Here are a few examples of these.

Example 1. If you have a page that expired due to not being updated for 100 days and also due to having "2018 Jan 1" set as expiration date, and you use the "confirm" action, it remains "expired". Why? Because although the first condition is not satisfied anymore, the second still keeps the page in "expired".

Example 2. If you have a page in status "Excluded" and you "include" it, it remains "Excluded". Why? Because either it has an ancestor that is excluded along with its descendants or the assigned content status scheme is configured to use an "Excluded" status in case of a specific CQL condition, other than the default arch.exclusion = "true".

Example 3. If you "exclude" a page, it remains included. Why? Because the assigned content status scheme is not configured to use the "Excluded" status or does not filter for the arch.exclusion content property.

These and similar situations are being caused by "overlapping" lifecycle rules and are relatively infrequent. Note that the app works correctly also in these cases, and even if the status is unchanged, its explanation in the Content Status Indicator will be different.

Tip: when you see the page in an unexpected status after taking a quick action, have a second look and eventually review your content status scheme.

Questions?

Ask us any time.