Take the 2-minute tour ×
Webmasters Stack Exchange is a question and answer site for pro webmasters. It's 100% free, no registration required.

What is the ideal publishing workflow within an enterprise CMS?

Background: Company size is 1,000. There are approx 20 Managers that must approve their respective department content before publishing. There are 3 User Roles:

  1. Webmaster Admin (support)
  2. Publisher (managers)
  3. Editor (staff)

At the moment an Editor make their change and then submits this for review. During this time, the content is locked for editing. A Publisher receives an email of "work waiting to be released" and can review the work through a test web address then either approves or rejects this work.

This process works most of the time but there are some exceptions. Sometimes a large scale project requires that content changes must be updated and tested well before they are published. For example, a product is being renamed publicly in 2 months time so this means that content is updated well in advance and is tested internally. These pages then remain in this stage for the 2 months until they are needed to be released. This means that ~50 pages are locked for editing, meaning any other content on that page cannot be updated during this time - causing disruption and frustration for content owners.

Now, I know this mustn't be too a unique problem but I am puzzled at how to deal with it.

share|improve this question
1  
What is your situation - are you building an enterprise CMS, or using an existing one? I find it hard to see the exact question here –  Pekka 웃 Oct 5 '11 at 10:24
    
Hi Pekka, we have an existing enterprise CMS and we can control the publishing workflow. –  rlsaj Oct 5 '11 at 21:37

2 Answers 2

up vote 2 down vote accepted

I don't think there is an all-encompassing answer to this. Workflow can be as simple or complex as needed to match the governance model required by the enterprise.

--

I've personally sat through some gnarly looking demos of workflow designers that are capable of involving multiple levels of approval, external processes and branching logic. In fact, these workflows get so advanced there are visual tools that help administrators discover where in the workflow an item is stuck.

My personal opinion is that workflow should always be as simple as possible. Internal engagement and adoption is the initial hurdle that needs overcome with a CMS deployment. Layering bureaucracy on-top of the CMS just makes people feel afraid of it and less likely to use it.

That being said, workflows (and even complex workflows) become a necessary evil in a complex organizations. A poorly timed press release could have dire consequences in certain settings. In these cases, I still favor "as little workflow as possible". If management is comfortable with a simple 1-step or 2-step approval, then this is ideal.

--

On the topic of forking content, I'm unaware of a CMS that does this well. For our own CMS we support WWF (Windows Workflow Foundation), but the content repository is versioned on a single track. It's easy to roll-back, but without custom coding we don't support forking or merging.

We've overcome similar challenges in the past by creating hidden sections of the web site and duplicating content from the existing page (this could be done through the UI or API). The new changes can then be developed privately and the existing content can continue to be maintained.

When it came time to switch we just switched some URL's to hide the existing content and then make the new content use the existing URL's. Any merging would need to be done manually. I'm not sure if this is the best solution, but it worked.

--

I'm interested in the idea of forking & merging content in a CMS though. I'll be interested to see if anyone has better suggestions.

share|improve this answer

If this was programming you'd create a branch which would then later merge with the main tree. Without knowing the details of your CMS I'd create a copy of the relevant part of the site for those 2 months and make and test the changes there. This never gets published to the live site.

Then when going live happens you have to change the original pages to use, say, the new product name. If the product name is the smaller change you change the original page to use the name. If the changes made to the original pages were smaller you copy the test page to the original page and reapply the changes made to the original.

With source code there are tools to help with this merging, but you may have to do it by hand comparing the two pages.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.