When most people talk about digital governance, they start with compliance. Audits. Risk management. All valid. But what they often forget is that governance is also about speed. When your editorial workflows are designed well, you do not just avoid mistakes you ship faster. With more confidence. And less internal noise. 

XM Cloud offers us a unique opportunity. It removes the infrastructure drag. It gives us flexibility in how we model content. But it does not hand us a governance model. That part is still ours to build. And in my experience, that’s where many Sitecore projects slow down not because the tech is lacking, but because the workflows are either unclear or overcomplicated. 

What You Get Out of the Box 

XM Cloud ships with a default workflow. Create, review, approve, publish. Simple enough. But in practice, most organisations outgrow it almost immediately. Regional teams need autonomy. Legal wants a checkpoint. The brand team needs to review tone. Suddenly, your workflow looks less like a straight line and more like a roundabout. 

What we learned very quickly is that the builtin workflow is a template, not a solution. You have to make it fit your business. And you have to be intentional about what gets added and why. 

A RealWorld Turning Point 

On one of our recent projects, the first golive deadline was tight. We kept the workflow minimal just enough to get content through the gate. But within weeks of launch, issues began to appear. Content went live with factual errors. Local teams published before central marketing had approved translations. And nobody knew who was supposed to fix what. 

The temptation was to lock it all down. Add more steps. More reviews. But that would have slowed us down even more. 

Instead, we brought everyone into a workshop. Authors, approvers, regional marketers, and even legal. We mapped the ideal journey of a single piece of content. Where it started. Where it paused. Who needed visibility. And when. From that, we built a revised workflow with three simple principles: clarity, visibility, and accountability. 

Principles That Make Workflows Actually Work 

The first principle was clarity. Every step had to have a purpose. No one could approve unless they added value. Review was not a box to tick it was a decision point. 

Second was visibility. We made sure content authors could see exactly where their work sat in the process. No more asking, no more guessing. If something was stuck, they could escalate it. 

And third, accountability. We assigned owners to each stage. Not roles. Names. That changed the dynamic completely. Everyone now understood what was expected and by when. 

What to Watch For 

The biggest mistake we see is teams designing workflows for exceptions, not the norm. They create elaborate approval chains because something once slipped through. But that punishes every future piece of content for a past mistake. 

Instead, design for your bestcase process. Then create a lightweight escalation model for when things go off track. Flexibility should be intentional, not accidental. 

Also, be careful with tool limitations. XM Cloud does not currently support branching workflows or multiple parallel approvals natively. You will need to use naming conventions, status indicators, and possibly extend workflows through integrations if your use case demands it. 

Editorial Velocity is a Strategic Advantage 

Too many people see workflows as governance overhead. But in truth, they are performance infrastructure. When done right, workflows reduce rework. They make teams faster by eliminating ambiguity. They protect brand quality. And they turn your CMS into a place where content actually flows. 

So before you add another approval step, ask yourself: is this helping us move faster with confidence? Or just slower with paperwork? 

Coming Up 

In Part 3, we will shift from process to protection. We will explore how to approach content security in XM Cloud including what is built in, what needs to be designed, and how to avoid common oversights around access, visibility, and publishing risk.