Custom processes can be implemented for your site that will insure reviewers can oversee site modifications.
This information refers to the Classic version of the UBCMS. Classic will be retired in May, 2022.
Last Reviewed: May 18, 2018
Workflow adds a built-in notification and authorization system onto your routine content production process. Pages can still be modified or activated without invoking a Workflow -- but once a Workflow is turned on, a specific series of steps are followed before that page can be published to your live website. Workflows are an optional feature that must be customized for your site in partnership with the DCT Help Desk.
We will ask you to work with us to set up your first Workflow. Before you contact us, please consider how you normally produce your content in the UBCMS now, which people are involved (for authoring, review, and activation), and how a new or revised page would ideally flow through that chain of people (author completes changes -> page is reviewed -> page is published or goes back for more changes, etc.). All of this will inform the custom solution we build for your site.
Remember, Workflows only add capabilities; they do not disrupt any business practices that are already in place. No one’s ability to edit or activate pages will be changed. Also, Workflows are not mandatory -- they must be added intentionally to each page, and manually initiated by an author. So you can begin gradually experimenting while still following your standard editorial procedures.
When identifying the people who will be part of your Workflow, start with your core team. We will suggest you initially set up a trial period to become accustomed to the Workflow process and make any adjustments. Eventually, you can transition to Workflows as the primary way to move things along for some or all of your website.
Workflows rely on your existing permission groups. For example, anyone in your site's author group will be able to initiate a Workflow, although you may initially instruct those outside the core group to ignore them. For the core group, they will make changes to a page and then initiate the Workflow process. Notification that the page has been modified will then be passed to a group of reviewers, and if accepted, the page will be activated, or passed back to the original author for additional changes.
Based on our pilot studies, we have established two standard templates that should meet most site's needs.
This workflow provides editorial oversight over the production flow, by sending author page modifications through a simple approve-reject process. If the request is acceptable to the approver, the page is then activated. If the changes are not acceptable, the approver can 'reject' the page, which is then returned to the original author for more work.
It is important to include comments in the appropriate areas of the process so it is clear what has been changed and why it may not yet be acceptable.
This workflow provides editorial oversight over the production flow, by sending requests by authors for page deactivatation through a simple approve-reject process. If the request is acceptable to the approver, the page is then deactivated.
It is important to include comments in the appropriate areas of the process so it is clear why the page is being deactivated.
Once you have a good idea how you wish your workflow to be structured, start the process with the Request Workflow form.
Workflows are initiated at the page level. Site authors will see all Workflows that are available for their site, and will not see Workflows set up for other sites.
What follows is a generalized description of a Workflow, highlighting significant features.
Someone in the first group (e.g. your site authors) opens a page in Author and makes desired changes.
They then initiate a Workflow as follows:
The Workflow adds a special annotation to the page, to warn authors that a Workflow now controls this page. That annotation will note the initiator's Name, the Workflow Name and the Date the Workflow was started
The Workflow also generates an email and places a message in the Inbox for the next group specified in the process (e.g. reviewers).
Recipients in the next group must now complete their part of the Workflow. (Workflows can have different steps depending how they are set up.)
Depending on the Workflow, there may be additional steps here...
The Workflow now progresses to the final step in the process.
The workflow will now end, and the annotation on the page is removed.
Here is how to start a workflow on a DAM asset:
A workflow icon should now appear in the status column of the asset list.
To complete DAM workflow steps when you have been assigned to complete a step:
After all steps of the running workflow have been completed, the little workflow icon should disappear from the status column of the asset list.
Start with your core team; be sure that your theory works in practice and you have full understanding.
Begin by slowly experimenting with a Workflow while you continue with your routine processes. Eventually, you can transition to a Workflow as the primary way to move things along, with what you have been doing traditionally as a backup.
We suggest during this trial period that you minimize who is using your Workflow and only gradually deploy it to your entire team.
Create a roll out plan:
Site managers can run a report to list details of any of their site's pages that have been associated with workflows. Since workflows are by site, you must be a member of that site's workflow groups to see the details.
Advanced users with workflow-editor permissions have the ability to modify their existing workflows.
These changes are done in the Workflows admin console (login required), which is accessible through the Welcome Page.
There is no way to apply an annotation to a DAM asset. There will be a little workflow icon in the status column of the asset in the asset list of its parent folder, but there will be no visible indicator when the DAM asset itself is viewed to indicate that there is a workflow actively running on it.