SDL Tridion Parent Publication Permissions Simplification

Here are some SDL Tridion patterns I like that fit a "don't overdo flexibility" mantra.
  • Minimize content publications
  • Minimize localization
  • Make multiple schemas but reduce redundant work through embeddable schema
  • Simplify selections by using Category and Keywords for text fields
Let's add one more: simplify permissions management. As promised, here's an implementation for a "brain-twisting requirement to manage permissions from a single parent publication." This can reduce the need to break inheritance or localize folders throughout the BluePrint and simplify your authorization model for the cost of some extra groups.

I really have to see and prove this out for more scenarios but so far this setup looks promising (i.e. test this out before going live).
  1. Use default rights groups as parents (e.g. Author, Editor, Chief Editor)
  2. Create subgroups for scope and permissions (e.g. Editor Global and Editor Local)
  3. Set these as children of the default groups, with scope set to a specific publication (level)
    • Editor Global is a member of Editor with 020 Content scope
    • Editor Local is a member of Editor with 040 Website scope
  4. Create "roll-up" groups such as All Authors and set these as children of the subgroups.
In your highest content publication, set folder permissions according to the following.

In this example, we want editors to see and edit components in this folder in 020 Content. Because the Editor Global membership scope to the Editor group is restricted to 020 Content,  both the Editor Global and its child group Editor All will have read and write permissions.

But we may not want editors write permissions in a lower publication. Because the Editor Local membership scope to the Editor group is restricted to 040 Createandbreak, both the Editor Local and its child group Editor All will have only read permissions.
For the "cost" of an additional roll-up group (and more subgroups, depending on how you handle scope versus permissions-based groups), you can:
  • Manage most author permissions in fewer (a single publication if you create most folders in 020 Content) publications
  • Set users to an "all" roll-up group and get combined publication scope and permissions--add a user to this group and they get the combined, yet separately managed, permissions, rights, and publication scope
  • Have the flexibility to mix-and-match subgroups if needed
Reminder: only change the "All Publications" scope setting for the subgroup membership. Leave the user membership, the roll-up group membership, and the "available for setting permissions" set to "All Publications."
See update below.* Manage your unique changes, not everything. 

Now, anyone have some good tip on session and user management to test this all out?
Update: the full setup can include "ACL" groups for even read and write permissions across similar folders. Each time you set up a global folder, you could place it as part of (maybe a same-named) group for each. It's a bit extra work in the setup, but troubleshooting and managing this means you can add full sets of permissions just be adding/removing membership.
With an "ACL setup" you'd set "All Publications" for everything. But if only doing roll-up groups, you may need to adjust the scope membership settings as needed (e.g. the Editor All would belong to Editor Local with scope just set to the "Local" publication and so forth).


  1. I partly agree with the statement above regarding minimizing redundant work through embeddable schema and here is why. The ItemFields API is tedious to use as a programmer. You have to type dozens of lines with loads of null checking just to read a field. This becomes more tedious when having to render/work with embeddable schemas. For this reason I often find it's easier to copy the fields in several schemas instead of going Embeddable. It results in having to write less annoyingly volumeous code.

  2. Having worked on Experience Manager templating recently, I can appreciate the challenges in working with embeddable schemas with DWT and TOM.NET. However, we still need embedded schemas whenever we have repeated sets of fields (linking to a component is not necessarily "the same," especially to authors).

    A content model, though guided by technical preferences, should be based on the relationships between pages, content, and fields.

    I'm sure there are plenty of ways to reduce, simplify, or refactor code to handle embeddable schemas, no? :-) Otherwise, we should let the closest product manager how we really feel about the API.


Feel free to share your thoughts below.

Some HTML allowed including links such as: <a href="link">link text</a>.