The following workflow components are covered in this help topic:
Workflows on multi-language sites (translation sets)
A workflow corresponds to a series of steps involved in completing a process. In the ACTIVE CM, a workflow corresponds to the steps involved in moving content from its creation through the edit, review and approval phase into publication.
Each step within a workflow consists of a task, and of one or more people who perform the task. For example:
Persons A, B, and C all create content (Content Providers) and submit it for approval.
Person D then reviews and approves (Approver Level 1) their content.
Person E then gives the final stamp of approval (Approver Level 2) of the content for publication.
Persons F and G simply receive email notification (Monitors) of the new content.
The role that people play in a workflow (provider, approver, monitor) is controlled by a permissions structure that provides user groups with the rights to perform each of those workflow tasks. When you create your groups, you will see the three different workflow type groups you can add users to: provider, approver monitor.
Once workflows have people assigned to them, they are applied to each page or section of your site. The workflow that gets attached to a page thus determines who will be responsible for editing, approving and monitoring that page. When you assign workflows to a page, you can set the system so that all child pages inherit the same workflow and are thus managed by the same people. Conversely, you can assign each child page its own unique workflow and have different people managing the content.
Each workflow approval level has a setting to determine whether one, all, or a majority of members are required to approve. The definitions of these are as follows:
One: One vote needed to Approve. All votes needed to Reject (from all users currently assigned directly or through group membership).
All: All votes needed to Approve (from all users currently assigned directly or through group membership). One vote needed to Reject.
Majority: The majority of votes by users assigned directly or through group membership needed to Approve. 50% or more needed to Reject. When there are is even number approvers in an approval level and the workflow option is set to majority, a tie-vote results in a rejection as a majority has not been reached.
An Approver can vote multiple times if desired (only the latest vote counts). If the action represents a changed vote, the user receives a confirmation message and can add a new Note. After each vote, the page's approval/rejection status is evaluated based on the current tally of votes, the current rule for that level, and the current approval level membership.
You can set follow-up tasks for each page type within the ACM. You may set some pages to have all follow-up tasks and you may restrict others to only one or two different follow-up tasks. This is done in using the Page Types Manager. The available follow-up tasks are as displayed below (Admin Center - Page Types - Page Type Details):
Once a page has been published, the next process it will undergo is dictated by the follow-up task settings on the Workflow tab (viewed when you are editing the page). If the settings in the Page Types Manager permit, pages can be scheduled for the follow-up tasks displayed below:
Note: If follow-up tasks have been disabled for this site or globally for all sites, the Follow-Up Task field and follow-up tasks will not be displayed as above and the following message will be displayed in their place (Follow-up tasks are controlled through Global System Variables, Site Manager and Page Types Manager):
When the Page is published and currently in the Workflow process
A review would only be triggered for a page that is not in workflow. Putting a page into workflow satisfies the requirement for review. A page is put into the workflow process the minute it is edited.
When the Page is published and not in the Workflow process
This condition exists when a page has not been edited and is now due for its scheduled review. A Review Required email is sent to content Providers. They can click Reviewed in the back-end view to satisfy the requirement, and a new review date is set automatically. Or they can click Edit, make changes, and send the new version through approval.
When the Page is published and currently in the Workflow process
The published version of the page is archived. The Workflow version can only be accessed from the child link in its parent's back-end child-page table.
When the Page is published and not in the Workflow process
The published version of the page is archived.
When the Page is published and currently in the Workflow process
When this is the case, the published version of the page will be inactivated and the version of the page that is currently in workflow will be displayed on the Child Pages tab of the parent page as Inactive and will no longer be in the workflow process.
When the Page is published and not in the Workflow process
The published version of the page is inactivated. No further action is required.
No workflow actions will be scheduled or required for this page.
The follow-up dates and tasks settings are configured in the Global System Variables, the Site Variables and the Page Types manager.
The Global and Site Variables managers allow you to set a default follow-up timeframe (e.g. 90 days, 180 days, etc.). When a page is created, the follow-up date becomes the creation date plus the 90 or 180 days.
If you set a page to Review, the system will expect you to review the page according to the follow-up days you set. If you are late reviewing it, the system will still require that the next review take place at its originally-scheduled time.
This is also true if you change the review period setting. If you change the period from 90 to 180 days, any pages set to be reviewed will retain the original 90 day setting. They will only change to the 180 day period after being reviewed (or manually changed).
There are, at most, two current versions of a page: the Published (live) version and the Workflow version. A page is considered to be in "workflow" if it is in the process of being edited or approved.
Only one current Draft version of a page can exist, as the current workflow version. When a change to a Draft version is saved, no new version is created — users cannot roll back to previous draft versions. A page version can be approved and awaiting publication (not yet published) if the publication date is still in the future.
A page is pending approval until it has either received final approval at the final approval level, or been emergency published, or been rejected. If a page is rejected by the necessary number of Approvers, according to the approval method in force, a new version is created (a copy of the last workflow version) with draft status. If an Approver makes a change to a page, the page is resubmitted for approval at the current approval level.
While a page is in approval, only Approvers at the current level or System Administrators can edit the page. Other users see a No-Editing icon on the front end with a Pending Approval method.
When a page is awaiting publication, only System Administrators can get to the back-end workflow version. Others see a No-Editing icon with a Pending Publication icon.
The publish button only shows for Providers when there are no Approvers. Otherwise, they click "Submit for Approval".
Monitors are not able to access the back end of any of 'their' pages. They only receive email notifications about those pages.
New pages that have not yet been published, and archived pages that were in workflow when archived, are accessible only from the sub-page table in the back end of the parent page. The child-page table in the back-end view of a page must show all child pages that are currently in workflow, even if there is no current published version.
As pages move through the workflow process, emails are generated and sent to the appropriate parties. The table below indicates the event that takes place and the user(s) that receive the triggered email.
|
|
Workflow event / Purpose of email |
Monitor |
Content Provider |
Approver |
Sys Admin |
|
1 |
Submitted For Approval An FYI is sent to all Providers. |
Yes |
Yes |
No |
No |
|
2 |
Approval Required Email informs all Approvers when a page is submitted to a new approval level. These emails include the escalation date. |
Yes
|
No |
Yes |
No |
|
3 |
Approval Notification Email informs all content Providers and Approvers of final approval at each level. |
Yes
|
Yes |
Yes |
No |
|
4 |
Rejection Notification Email informs all content Providers and Approvers of final rejection at any approval level. |
Yes
|
Yes |
Yes |
No |
|
5 |
Approved for Publication Email informs all content Providers and Approvers at all levels when final approval for publication occurs (includes publication date). |
Yes
|
Yes |
Yes |
No |
|
6 |
Emergency Publication Email informs all in workflow of emergency publication. |
Yes
|
Yes |
Yes |
Yes |
|
7 |
Emergency Rejection Email informs all in workflow of emergency rejection. |
Yes
|
Yes |
Yes |
Yes |
|
8 |
Escalation: Approval Required Email informs all that the escalation period for an approval level has expired. |
Yes
|
No |
Yes |
Yes |
|
9 |
Review Required Email informs content Providers that the review date has arrived (include escalation date). |
Yes
|
Yes |
No |
No |
|
10 |
Escalation: Review Required Email informs all that the escalation period for a review has expired. |
Yes
|
Yes |
No |
Yes |
|
11 |
Archive Warning Email informs users that archive will occur in a certain number of calendar days. |
Yes
|
Yes |
No |
No |
|
12 |
Archive Notification Email informs that page has been archived. |
Yes |
Yes |
No |
No |
|
13 |
Review Complete Notice Email is sent when review has occurred. |
Yes |
Yes |
No |
No |
One may only add a 'Note' for the current workflow version, when an action is taken. The notes area displays the notes entered since the last publication of the page. The workflow manager is used to determine who can add content (Providers), who can approve and publish content (Approvers), and who will simply overview the process (Monitors ).
The process of creating workflows involves:
creating users
creating Provider, Approver and Monitor type groups
assigning users to those groups. Users can be part of more than one group. For example if a user will be both creating and approving content, they will be in both a Provider group and an Approver group.
creating workflows using the groups you created
applying the workflows to pages, sections and/or sites
There are some differences in how workflows function when a site is part of a translation set.
Page versions can have a status of Pending Translation if the page being translated requires translation. When all the pages associated with the page for translation have been approved or published, the page goes into a Pending Publication status and can be published if the Publish Date/Time has passed. A page that is Pending Translation can also be Emergency Published if necessary.
Each time a primary page is updated, a Translation Required system email informs content providers for the other sites that there is a new page version to be translated.
If pages are emergency published, and their associations thus broken, users will get a prominent error message indicating that the multi-language versions of the page are no longer synchronized. The pages can be re-synchronized on the Translation tab of the secondary language page version.