-
Notifications
You must be signed in to change notification settings - Fork 51
How to Use Bricolage Workflows
In the world of content management, workflow is a method of ensuring that assets meet standards before they are published to the live system. Good workflows organize people with different responsibilities to efficiently work together on assets and ensure their accountability for the finished product. Bad workflows create unnecessary bottlenecks and disrupt the flow of assets to production.
Bricolage has a particularly powerful workflow model that manages both content and templates used to format content. If you are considering or have selected Bricolage, chances are that workflow is important to you.
Bricolage’s workflow is based on a desk
metaphor. Each desk represents the state of documents it contains. On the participant side, a desk also represents a role in the editorial process. Examples of desks include an author or edit desk (where assets are created), a copy desk (where assets are reviewed for correctness and style), a legal desk (where the asset is reviewed for policy), and a publish desk (where the document is ready to be made live
).
Participants in the workflow process monitor a desk, check out items for review, and then promote them to the next desk in the workflow. This model has several advantages: by routing through desks
rather than individuals, the system can more easily respond to bottlenecks created by increased volume or the absence of individuals; individuals can easily be substituted in the process, and it is easy to see lists of documents that are in a particular state.
Unless specifically configured, Bricolage’s workflow does not enforce a progression of assets from desk to desk. A user has the ability to move an asset to any desk to which he has READ
access. Unless permissions are configured in a certain way, a document’s existence on the Publish desk does not mean that it has worked its way through every relevant intermediate desk. This is different from other CMSs, which define workflow as a collection of states and transitions. Bricolage workflow does not define transitions but uses permissions to restrict what actions are available to the user.
Users with permission to a workflow will see the workflow listed on the left navigation menu beneath the item that reads My Workspace.
Within each workflow there are Actions and Desks. All content workflows will have the same actions: New [Media | Story], New Alias, Find [Media | Story], and Active [Stories | Media]. These are pretty straightforward so I will not get into describing them.
Desks are where things get interesting. Bricolage comes installed with the several desks. More desks can be added very easily but the system comes with:
Art, where media assets are created and modified
Edit, where story assets are created and modified
Copy, where story assets are reviewed
Deploy, where template assets are when they are
live
Development, where template assets are created and modified
Legal, where story assets are reviewed for legal compliance
Selecting the menu item for one of these desks displays all the assets that are currently waiting on that desk. If other users are on the system, some assets may indicate that they are checked out. With sufficient permissions, a user can check an item out to notify other users that he is working on it and block other users from trying to edit the asset until he is done. To edit an asset, one must check it out to one’s workdspace. A user can also move the item to another desk to which he has READ
permission. If you check out an asset, the asset will appear in your workspace and you will be notice that you have option to edit the asset by clicking the edit link.
Bricolage allows workflow participants to communicate about assets through notes. Each asset has a notes link where users can add notes to explain to other workflow participants what they did and what needs to be done. For example, a media asset might be moved from Legal back to the Art desk because there is no copyright symbol on the logo. Notes are stored in a chronological note history. Participants can get additional context about an asset by viewing its event log, which lists all the actions that have been carried out on the asset. There is also an audit trail that tracks all the events of the worfkflow process itself.
For each workflow, one desk is designated as a start desk.
The start desk is where assets will appear when they are first created or recalled from the Bricolage document library. Some desks are designated as publish desks.
Assets on publish desks will appear with a Publish
check box that allows users with PUBLISH
permissions to publish the asset.
The workflows that come with Bricolage assume a relatively egalitarian editorial process that prioritizes efficiency over control. The Edit,
Copy,
Legal,
and Publish
desks do not enforce a workflow progression, and special permissions are required only for publishing content. If the default workflows do not meet your requirements, apply permissions to them or create your own.
Creating a workflow is a very simple process of selecting the desks that should be part of the workflow, designating one of the desks as a start desk, and selecting the workflow groups that the workflow should belong to. These groups will be used to set permissions to user groups. Note that desks can be shared between workflows. Shared desks have the following implications: assets on a desk appear in all the workflows that contain the desk, and permissions for the desk apply to every occurrence of the desk. This is generally a good thing because it allows workflows to work together. For example, you could have a legal workflow with just the legal desk on it. If the legal department just had access this legal workflow, they would just monitor the legal desk. They could also have READ
permissions on other desks that are not part of their workflow—such as publish and edit desks— and this would allow them to accept or reject assets by moving them to the appropriate desks. Either action would effectively make the asset disappear
from the user’s scope (the Legal workflow).
To define a new workflow, you need to have administrative rights to Bricolage. You will see a Workflows
item under the Publishing
subsection of the Admin menu. Click on the item and you will see a list of all the workflows that exist in the system
The select list at the top of the permissions page allows you to assign specific permissions to the assets on individual desks (i.e., choose Desks
from the select list), so if the members of the lusers group have no permissions for a particular desk (NONE
), they won’t even see it. Remember also to set (under Object Groups
in the selet desk) All Desks to NONE
as well. (The easiest thing is to choose All
from the select list and run down all the permissions, experimenting with what you think is necessary.)
Click the Add a New Workflow
link and you will get a form to enter information about your workflow. The key field here is Type,
which can one of Story,
Media,
or Template.
A workflow cannot be used to process more than one asset type. The logic here is that different users are involved with story documents (writers), media documents (designers), and templates (developers). The other important field to consider is the start desk. It is here that new assets will appear when they are created. Select the workflow groups that the workflow should be part of and then click next.
Now start adding the desks that will be part of your workflow. You can use existing desk (remember, these desks may be shared with other workflows), or new desks. Notice that there is no order assigned other than selecting a start desk. This is because Bricolage workflows do not have a built-in notion of a defined progression between desks. The only way to enforce such a progression is by giving different groups specific permissions that only allow them to promote assets to the next desk or demote them to a lower desk. If a user has permission to skip a desk, he needs to have the responsibility to apply all the review criteria expected at the skipped desk. Once all the necessary desks have been added, click save to save the workflow.
Permissions are critical to the function of workflows in Bricolage, and can be assigned at the workflow level and at the desk level. Permissions at the workflow level can be used to restrict an expedited workflow (with fewer steps) to certain users. Restricted workflows can also be used to process certain types of documents within a category. For example, there might be a legal workflow that is used for things like privacy policy, disclaimers, and other content assets with a distinct legal focus. Another use of a restricted workflow is to help focus a group’s attention on a specific desk.
To restrict permissions to a workflow, the workflow needs to be part of a workflow group. This is done on the workflow administrative profile. Additional groups can be added by selecting the Groups
link under the System
menu. Once the workflow is added to a workflow group, it will inherit the permissions set for the group. To edit the permissions on a workflow group, execute the following steps:
Select
Groups
from theSystem
menuFind the group either through search, navigating through the alphabet, or selecting
Workflow Groups
in the drop-down box.Click the
Edit
link for the workflow group for which permissions need to be granted to access its membersClick the
Permissions
button on the bottom right of the group profileAssign permissions to the user groups listed on the permissions page
Click the
Save
button
Permissions set at the desk level determine what kind of access a user has to the desk. Here is a breakdown of how permissions affect what a user can do:
READ: A user with READ permissions sees the desk listed, view its contents, and can move assets to the desk.
EDIT: A user with EDIT permissions can do everything that a reader can do, plus check out items to modify them and move them to other desks.
RECALL: (start desks only) A user with RECALL permissions can recall documents and templates from the library—that is, when they’re no longer in workflow but are still in Bricolage’s document library
CREATE: (start desks only) A user with CREATE permissions can create an asset on the desk.
PUBLISH: (publish desk only) A user with PUBLISH permissions can publish an asset (by selecting the publish check box on a publish desk and clicking the
Published Checked
button)
To edit a user group’s permissions to the assets on a desk, execute the following steps:
Select
Groups
from theSystem
menuFind the group either through search, navigating through the alphabet, or selecting
User Groups
in the drop-down box.Click the
Edit
link for the user group to which permissions need to be granted to access a desk’s contentsClick the
Permissions
button on the bottom right of the group profileSelect
Desks
from the select list at the top of the Permissions pageSelect the appropriate permissions (see above for a list of definitions)
Click the
Save
button
Consider the following example where you have authors who write articles, editors who review articles, and publishers who publish articles. Authors can only create articles and submit them for review. Editors can either promote an article to be published, or send it back to an author for revision. Publishers are responsible for the finished product so they can both review (in place of an editor) and push assets to production. In Bricolage, the permissions may look something like this.
Authors have EDIT permissions on the Write desk, READ permissions on the Review deskm and no permissions on the Publish desk.
Editors have READ permissions on the Write desk, EDIT permissions on the Review desk, and READ permissions on the Publish desk.
Publishers have EDIT permissions on Write and Review desks and PUBLISH permissions on the Publish desk.
Create a user group for the lesser-privileged users
or lusers
as they shall henceforth be known, then set the permissions for that group.
The lusers will also have to have READ
permissions to see All Sites
(or a custom group of sites) for them to see the any workflows at all.
You can restrict the lusers to certain categories and elements by creating custom groups of those objects. note that individual category permissions apply to to objects within those catgeories, and not to the categories themselves. I found that if I just set the permissions for categories and left All Categories
set to NONE,
they couldn’t see any of the categories; but if I set All Categories
to READ,
they could see all categories (d’oh!). I created a custom group of categories and set the permission to its to READ,
and set the individual category permissions to something relevant and that worked.
Consider the example below. There is a group of DJs who should be able to see just the start desks in the Story and Media workflows. They need to be able to do everything (except publish) to the stories within certain categories – this is what I set (anything not mentioned is set to NONE):
Everything we have spoken about so far assumes that users are regularly logging on to Bricolage and monitoring their desks for their assigments.
However, most users will not log into Bricolage unless they know there is work to do. This is what alerts are for. Using Alerts, you can create rules so that users are emailed when certain events occur. For example, an asset being assigned to a desk. For information on using Alerts, please see the Alert documentation.
Clinton Gormley wrote how to set up permissions to associate people with desks.