Understanding roles and groups
A user’s access in Storyteq CMP is determined by two separate things: their role and their group membership. Roles control which platform features a user can use; groups control which portal pages they can see and how they take part in projects and workflows. This page explains how the two work together and when each is needed.
Roles: access to platform features
A role controls what a user can do across the platform’s feature areas, such as creating adaptations, building templates, running reviews, using integrations, viewing analytics, accessing portals, and administering users.
Roles are assigned per user, and within a user, per domain, when you create or edit the user. They come as fixed presets that you can fine-tune; adjusting any permission in a preset changes its label to Custom. For the full list of presets and what each grants, see User role presets and permissions.
Two labels are worth clarifying, because they do not mean what they appear to:
-
The Assets role domain refers to adaptations created in Adaptation Studio, not to DAM assets.
-
The Administration role grants user and group administration only, not access to the whole admin panel.
Groups: page visibility and workflow
A group controls two things: which portal pages its members can see, and how members take part in projects and workflows.
For page visibility, a page can be locked to a group so that only members of that group can see it. This is how you show particular content to a specific audience, such as a portal intended only for one brand team.
For projects and workflows, a group acts as a unit whose members can be notified or given permission at a stage of a workflow, for example so that everyone in the group is notified when a brief is ready for review. Notifications depend on the relevant service being enabled in the group’s settings, which can be turned off during testing to avoid unwanted emails.
Group membership can also be what grants access to certain sections of Administration, such as templates, taxonomy, or lenses.
When a user needs a group
Not every user needs to belong to a group. A group is required only when one of the following applies:
-
A portal page has been restricted to a specific group, and the user needs to see it.
-
The user takes part in projects and workflows.
-
The user needs an Administration section whose access depends on group membership.
How roles and groups work together
A user’s full access is the combination of their role and their group membership: the role determines which platform features they can use, and group membership determines which pages and restricted areas they can reach.
For example, a user who builds templates needs a role that grants access to Adaptation Studio, plus membership of a group that grants the relevant Administration access. A user on a single brand team might be placed in that brand’s group so they see only that brand’s portal, while a user who works across brands is placed in several groups.