Workflow cycles, states, and status types

IXIA CCMS has a formalized workflow cycle that ensures that content development stays on track as various users exchange topics, maps, and images until the content is ready for publication.

Every content creation team, no matter how large or small, naturally follows a workflow of some sort. For example,

  1. Authors or contributors create content
  2. Subject matter experts (SMEs) review and approve the content
  3. An editor might revise the content
  4. A translation coordinator might submit source content to a language service provider (LSP) for localization, review the resulting translations, and import them back into the CCMS
  5. A user publishes the content and its possible translations as output of various types

Outside of a CCMS, this workflow can be hard to keep track of. One of the strengths of theIXIA CCMS is its ability to formalize your existing workflows into specific cycles and states that enable you to know at any time:

  • what kind of work is currently taking place on an object
  • who is currently responsible for the object
  • what should happen next to the object

Cycles

You can think of a cycle as a sector or partition of the CCMS.

CCMS Desktop includes five cycles: Authoring, Localization, Published, Deleted, and Project. CCMS Web includes Authoring and Translation as active cycles and Localization as a view-only cycle.

An object's cycle helps you see immediately whether the object is in its source language (Authoring) or whether it has been translated (Localization, Translation). Objects that have been deleted but are recoverable are in the Deleted cycle.

In CCMS Desktop, objects that have been "archived" are in the Published cycle, while projects are in the Project cycle.

An object cannot be in more than one cycle at a time. For example, when you localize a map, the map does not move from the Authoring cycle to the Translation cycle. Instead, a copy of the map is created in the Translation cycle.

States

Within each cycle, there are multiple states available for each object type. For example, in the default configuration, the Authoring cycle includes these states for topics: contribute, work, review, approval, and done. At each of these states, a designated role is primarily responsible (active) for the topic, and the topic can only move to one of the other states that are configured as "next" states. If a topic must always be reviewed, then the configuration can stipulate that a topic cannot move

Most of the time, the move from one state to another is initiated by the user at an appropriate time. Some moves can be automatic, initiated by other actions.

An object can only be in one state at a time.

Statuses

A object's cycle and state, written together, define its status, such as Authoring:review.

Note: The move from Authoring:work to Authoring:review, for example, is technically a state change, but it is more commonly referred to as a status change.
Figure: Sample documentation process cycles and states