dotCMS: Everything You Need to Know About Hybrid CMS Workflows
By Catherine Liang
Since partnering with dotCMS earlier this year, our consultants have been exploring its different functionalities. In this blog, we’ll quickly cover headless vs. traditional before diving into workflow functions, roles/user breakdown, workflow schemas, workflow steps, and 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 a 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 a traditional CMS?
In a traditional CMS, all the content, editing interface templates (the content you author), and database remain within a single environment.
Why combine them?
As dotCMS explains, a hybrid allows the freedom of a headless CMS with the full functionality and ease-of-use of a traditional platform.
Every CMS needs a workflow
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.
How to create 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.
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.
For additional insights, follows us on our socials.
Personalizing your Website with DotCMS
In this post, we’re going to walk through how easy it is to create personalized, targeted content for your website using the DotCMS content management system.
Content Bloom Partners with dotCMS
Content Bloom has recently found a fifth partner in dotCMS, an ultra-innovative headless CMS platform.
An AngularJS & Contentful Starter Kit
Awhile back our own John Winter had an article published in Forbes introducing some of the benefits of a headless CMS. I’ve been hearing quite a bit about some of the new “content as a service” providers so I thought I’d jump in and give one a go. I decided to throw together an Angular […]