help.axcms.netAxinom Logo
Save Save Chapter Send Feedback

Workflow Support


Although you won't find a graphical workflow editor, supports workflows in many ways. The basic building blocks for the workflows are:

  • Page Life Cycle
  • Publishing and Controller Workflows
  • Reports, Alerts and Filters
  • Versioning for Pages and Documents
  • Dependencies
  • Check-In/Check-Out Support
  • Tasks
  • Translation Interface

By combining these features, users can model many functional workflows. More specific workflows can be programmed in a project context using the extensibility model.

Page Life Cycle

Every publishable object (for simplicity, let's assume a Page) can be in one of these states, called Publication States:

  • Never Published
  • Published
  • Changed
  • Deleted

On this diagram you can see the life cycle of a Page as a state chart:

Fig. 1 State Diagram for Publication States

Fig. 1 State Diagram for Publication States

Publishing and Controller Workflows

In the simplest case, a single person performs all the tasks on the web site. In this case, this person creates a page and edits it until everything looks good (the new page is only visible in Management System, not the Live System). Then she clicks "Publish" and the page is published to the Live System.

Fig. 2 Simplest Publication Workflow

Fig. 2 Simplest Publication Workflow

In a more complicated model, the role of editor and publisher are separate. An editor can make changes, but cannot publish herself. There is a special role of a Publisher, who can publish. In this scenerio, when the editor has completed making changes to a Page, she will click "Request Publishing" instead of clicking "Publish". The page is then in the state "publishing requested". The Publisher can then review the requested page and publish it or refuse to publish and inform the Editor about the problems.


Fig. 3 Publication Workflow with Editor and Publisher

Fig. 3 Publication Workflow with Editor and Publisher

If more than one party needs to be involved in reviewing the Pages before they go live, the role of a Controller can be introduced. If a Controller is defined for a page, she has to approve the Page before it can be published by the Publisher. There can be one or multiple Controllers. Every Controller can approve the page from her own perspective, e.g. Corporate Identity, Legal, etc.

Fig. 4 Publication Workflow with Controller

Fig 4. Publication Workflow with Controller

Reports, Alerts and Filters

With Workflows it is important that every user is informed about the next steps she can/should take for every particular workflow. To facilitate this, offers 3 methods: Reports, Alerts and Filters.

A Report is something a User can subscribe to. Some reports are predefined. In addition, custom reports can be implemented in the project context. All reports are generated once per day and are emailed to the subscribers. Within, the standard, included reports include:

  • New pages
  • Pages ready to be published
  • Pages waiting for approval
  • Pages waiting to be published
  • Pages to be published
  • Objects to be checked in
  • New documents
  • Documents to be published
  • Link status
  • Assigned tasks

Alerts are similar to reports, but they are triggered immediately when something happens. For example, if an editor requests publishing, an Alert "Request Publishing" Alert is triggered for this page. The users, which have subscriptions to this Alert immediately get email notifying them of the request. Because Alerts, if applied globaly, can generate huge amounts of email traffic on a busy web site, there is the ability to restrict them. When subscribing to an Alert, you specify a Category for which you want to have Alerts. You are then informed only about the events from the objects in this category and below. Custom alerts are possible in a project context as well as the custom reports.

Both Alerts and Reports are part of the push-communication in - the user getting notifications from the system. There is also the capability for pull-communication. If a user logs into the management system, she can easily find the next relevant workflow steps. On Page and Document overview pages there is a box labeled "myStuff" which allows the user to filter for relevant objects (objects for which the user has permissions to perform the next action) and/or the objects with a particular pending workflow step ("need request publishing", "need publishing").

Fig. 5 myStuff-Box

Fig. 5 myStuff-Box

On the start page in the management system, a user can configure special boxes which also show the objects in a particular workflow step. For example: "All changed pages which need to be published and can be published by me".


Fig. 6 Custom Box for the homepage with a page list

Fig. 6 Custom Box for the homepage with a page list


A mature Content Management System keeps track of the versions of the content. This may be required for a variety of reasons:

  • Audit - be able to prove later at which time which version of the content was online
  • Archive - be able to historically look at the content and how it changed over time
  • Backup - be able to recover content if the content is accidentally changed or removed applies versioning to Pages and Documents. It differentiates between major and minor version changes. A major version is created when an object is published. A minor version is created on every object change. User can view all the previous versions and even restore any of them with one click.

Fig. 7 Version list for a page

Fig. 7 Version list for a page

Dependencies tracks dependencies between objects and reminds the user if needed. For example, if a user tries to publish a page, will show which images are embedded and not published yet, as well as relations, navigation nodes and all other objects the current page depends on. If a user tries to delete a document, it will show all other objects which depend on this document and will enquire whether the user really wants to proceed with deletion. A user can also review the dependencies at any time.  


Check-In / Check-Out supports collaborative work of many editors on the same Page. To prevent conflicts (for example, one user overwriting the content written by another) it uses Check-In/Check-Out concept. If a user starts editing an object in a page, that object is automatically checked-out for the current user. As long as the user edits the object, the others can see it, but cannot save back their changes. When the user has completed her editing, she checks it back in. It is only possible to publish a page when all content on the page is checked in. An Administrator can check-in forgotten objects, if the user who checked them out is not available.



Tasks are a simple, but handy tool for users to collaborate. One user can create a task and assign it to another user. Tasks have the properties of Name, Description, Due on, Created By, and Assigned to. What makes them particularly useful is that they fit into the general infrastructure:

  • Tasks can be classified like any other object
  • You can assign a task to any other object
  • You can see your tasks in a box on your customized homepage
  • You can subscribe to a report "My Tasks" and get alerted when new tasks are assigned to you
  • Tasks are considered evaluating dependencies
  • Tasks can be assigned just by emailing task description to the Instance.


Fig. 8 Task in

Fig. 8 Task in

Translation Interface

A typical task in a multi-language application is the translation of the content into different languages. supports external Translation Tools via a special API. Calling this API can be added into a normal publishing workflow. Just click on a Page, then "Translate page", select the target languages and "finish". Copies of the page are created and assigned to the selected languages. The content is exported as XML and forwarded to the translation API. As soon as the translated version is ready, AxCMS.Service picks it up and imports it into the Page. There is a reference implementation for Across Language Server, but any other translation engine is possible with a few customizations.