Ever since partnering with dotCMS last year, our consultants have been exploring its different functionalities. In this blog, we’ll cover how headless Content Management systems and traditional CMS work. We’ll then dive into a quick and easy technical walkthrough which includes:

• Workflow functions

• Roles/user breakdown

• Workflow schemas

• Workflow steps

• Workflow actions and sub-actions.

In order to understand the power of a hybrid content management system (CMS) like dotCMS and its workflows, it’s important to understand the ways a headless and traditional CMS differ and how combining the two can create the ultimate platform.

What is headless CMS?

A headless CMS is a back-end only content management system built from the ground up as a content repository, making content accessible via RESTFUL API for display on any devices. It has an interface to add content and RESTFUL API (JSON, XML) to deliver content wherever you need it.

Headless only cares about storing and delivering content. The API makes your content available through any channel, on any device, and writes your website/mobile application using any programming language by combining your custom tools and development process without re-authoring your content in any way.

Side note: Be sure to check out John’s piece for the Forbes Technology Council on the benefits of a headless CMS.

What is traditional CMS?

In a traditional CMS, all the content, editing interface templates (the content you author), and database remain within a single environment.

Can you combine CMS platforms?

As dotCMS explains, a hybrid allows the freedom of a headless CMS with the full functionality and ease-of-use of a traditional platform.

Does Your CMS need a workflow?

The short answer is yes.

Workflows are crucial to business success. They are designed for creation, approval, and release of content. The workflow manages all of the processes to improve efficiency and a proper content strategy is key to publishing content as it dictates the direction of workflows. CMS rely on having people like authors, editors, or marketers to take content from ideation to publication.

Simple steps for creating a workflow using dotCMS

To start a new project, admins will reach out with a strategy on overall content direction and then CMS admin/managers design the workflow and assign responsibilities to various roles. (This is similar to that of a RACI chart.)

For example, an author will be responsible for creating content and information and a manager or stakeholder will be accountable for reviewing content in a staging environment to mitigate risk and ensure updates are correct before publishing to live.

Workflow in dotCMS is very easy to use. Let’s break it down.

We are able to create different workflows for different content types. For blog content, we want it to go through silos before publishing, but for other content, such as heroes, it will not be necessary to go through the business department for confirmation. With dotCMS, we are able to create an isolated workflow that is just for blog content. However, in order to create your workflow processes, singular user roles and permissions must first be granted to individuals.

How to modify user permissions

dotCMS admin can add or modify user accounts by giving them access to different objects or creating user groups. The dotCMS permission system enables admin to control user access to all dotCMS content and backend functionalities through the use of individual user permissions and roles.

There are two ways admin can modify users’ access and permission.

• The “Users” navigation bar

As an admin, you’ll be able to create accounts and give access to your front and back-end developers. In addition, admins can assign specific roles and permissions to the user under roles/permission bars.

We mentioned earlier that within the roles bar, each user can be assigned to a specific role and permissions.

• The “Roles & Tools” navigation bar

As you can see in the image below, different roles have different access within the dotCMS console and can be customized by admin, adding another level of flexibility to creating new roles for a project.

Keep in mind there are limitations when it comes to various roles. For example, a “content editor” has the permissions to edit, publish, and view content and content types. However, users who are assigned a content editor role are only able to see the content model.

Each role can have one or more “child” article but because it follows reverse permission inheritance, access will vary. It’s as if parental control has been switched on and the safety locks set in place.  Meaning, the “parent” role auto-receives all permissions assigned to the child role and so the group is only permitted to see what the parent sanctions.

Back to workflows

As we mentioned earlier, dotCMS provides a default system workflow with the ability to build custom workflows based on given requirements. Custom workflows are ideal if you need to specify the way content moves through the dotCMS system and want full transparency from initial creation and publishing to archival and deletion.

Since dotCMS enables us to create distinctive workflows for different content types, it makes risk mitigation and control over content much easier. In the image below you’ll see the view of all workflows created inside of a domain. For example, the workflow “Blogs” includes all the steps for blog-type content.

As shown above, workflow “Content Bloom” is designed for a content type “Demo Workflow Content-Type”. Any content that belongs to this type will go through the “Content Bloom” workflow.

Within a workflow are different steps. Within those steps are actions that will be done during each step.

As we can see in the image below, there are 5 steps in this workflow. Inside each step are actions. The greyed-out text beside each action indicate the upcoming step after any given action.

For example, in step “New Content” there is an action named “Save” with “Draft” greyed out. This means after the action “Save” is done, the workflow goes to the step “Draft”.

Action information, permissions, and sub-actions can be modified inside of each action. The image below shows the details of each action. Admin defines next steps after the action, as we mentioned above, and can modify the assigned permissions to an individual user or a group of users.

Something really cool? A pop-up window appears to allow you to add any custom logic inside of an action that you want executed.

Let’s talk about sub-actions.  There are two types of sub-actions – with parameters and without parameters.

There is a list of sub-actions that are built-in functions. For example, “Save the Content” action does not have parameters, it simply saves the content in the dotCMS console. On the other hand, as we can see in the image below, the “translate content” sub-action is one of the sub-actions with parameters.

Users are able to translate the content into any other language supported in the console.

Of course, dotCMS supports a lot of languages but you need to add it into your console for your site to support it. To add a language, we simply go to the language menu and add a new language with language code (i.e., DE) and its description (i.e., German). With the built-in translate content sub-action, it only supports Google translation API but there is always an option of building our own sub-actions via plugins.

Just like with actions, custom sub-actions are also available in dotCMS. You can implement any logic via a plugin (for example OGSi plugin) or via velocity scripts.

Content Bloom is the largest dotCMS partner in North America, check out our dotCMS services page to learn more.