When we transitioned to Sitecore XM Cloud, we knew we were moving more than just code. We were changing the very fabric of how our teams work, how decisions get made, and who gets to touch what. The familiar comfort of legacy role structures vanished, and with it went the shortcuts we had come to rely on. 

In the old world of Sitecore XP, many of us got by with informal rules and generous admin access. It was easier to give everyone full access than to deal with the politics of privilege. We accepted some messiness in the name of speed. But in XM Cloud, that approach falls apart. Suddenly, your roles need structure. Your permissions need a rationale. And your team needs to understand why it all matters. 

This is not a technical hurdle. It is a leadership decision. And it is often made too late. 

What Changes in XM Cloud

XM Cloud introduces a cloud-native, API-first, multi-tenant architecture. With that comes a new scale and complexity. Teams are no longer working in isolation on a single stack. They are part of a larger ecosystem — developers, designers, authors, testers, marketers, and third-party agencies all collaborating in one composable environment. Giving blanket access is no longer just lazy; it is dangerous. 

We encountered this head-on during a recent multi-brand implementation. Initially, roles were unclear. Everyone had too much access. Editorial teams made changes in places they should not have. Developers spent more time reversing accidental edits than writing new code. What began as a permissions issue became a trust issue. 

So we paused. We reassessed. And we rebuilt the role model from scratch. 

Lessons from the Rebuild 

The first thing we learned was that job titles rarely map to permissions. A marketing coordinator in one region needed the ability to publish in three languages. A counterpart in another market only needed read-only access. We could not assume anything. We had to interview users, observe workflows, and understand who did what — and why. 

Second, we discovered that over-permissioning is not just a security risk. It erodes accountability. When too many people can publish, no one feels responsible. The result is slower delivery, not faster. 

Third, we saw how important it was to separate authorship from publishing. Even in lean teams. That separation introduced a pause. A moment to review, to validate, to ask whether the content was right — not just whether it was complete. 

And finally, we committed to never assigning permissions to individuals. Only to groups. It made onboarding easier, ensured consistency, and allowed us to scale across markets without reinventing the wheel each time. 

The Real Risk of Getting It Wrong 

Poor role design shows up quietly. Editors get frustrated but do not complain. Developers are asked to fix things they never broke. Content goes live before it is ready. And eventually, the system becomes unmanageable. 

But when roles are done well, the platform disappears. People stop talking about permissions and start focusing on outcomes. Collaboration improves. Content velocity increases. Trust returns. 

A Better Way Forward 

If I could offer one piece of advice to anyone starting their XM Cloud journey, it would be this: treat roles and permissions like a product. Design it. Test it. Evolve it. Do not assume the defaults will serve you well. They rarely do. 

Roles are not a checkbox. They are how your people engage with your platform. And they deserve the same thoughtfulness you bring to any customer-facing experience. 

Coming Up 

In Part 2, we will move from roles to workflows. We will examine what XM Cloud offers out of the box, where the gaps are, and how to create governance models that actually support velocity — not just control it.