
Who is allowed to publish
A CMS for one person needs no permission system at all. Everything after that is politics encoded as software.
WordPress ships five roles and they are a decent map of a small publication. Subscriber reads. Contributor writes but cannot publish. Author publishes their own. Editor publishes anyone's. Administrator changes the site. The important one is contributor, because it encodes the idea that writing and publishing are separate acts performed by different people. That single distinction is most of what editorial workflow is.
Larger systems generalise it into rules: who can perform which action on which type of content in which state. The generalisation is correct and it is also where the usability goes to die, because a permission matrix with four dimensions cannot be rendered as a form that anyone enjoys.
The thing I have come to believe is that permission is not really about roles. It is about the document. Whether you may edit this depends on its state, on whether you wrote it, on whether it is scheduled, and only then on what your role is. Systems that model permission as a property of the user get halfway and then bolt on exceptions. Systems that model it as a function of user and document get further.
Expressing it as a function has a practical advantage: a function can say things a matrix cannot. Editors may edit anything, authors may edit their own drafts, nobody may edit something currently scheduled. That last one is a real requirement and there is no row in a permission table for it.
The cost is that a function is code and a matrix is data, which is the same tension as the content model, with the same trade. A checkbox grid can be edited by an administrator at three in the afternoon. A function is deployed.
Then there is workflow proper, which is the state machine on top. Draft, in review, approved, scheduled, published, archived. Most sites need about three of those and are sold seven.
Workflow is where enterprise CMSes justify their price and where most projects discover they did not want it. A two person team with a review step will route around it inside a month. A regulated bank genuinely cannot publish without two approvals and needs the audit trail to prove it. Same feature, completely different value, and the software cannot tell which situation it is in.
The part everyone underrates is the audit log. Not versioning, which is about content, but a record of who did what and when. It is boring to build, nobody asks for it in a demo, and it is the first thing anyone wants the day something goes wrong. If I were ranking these features by regret per hour of implementation, the audit log would be at the top and the approval workflow near the bottom.