Choose roles and access levels
Use practical examples to choose the right system role and permissions for each team member.
Choose access based on the person's responsibilities. A job title alone does not determine their role: most people need access to specific tasks rather than broad administration.
We recommend the User role for most members. Assign Admin only to a person the Owner deeply trusts with broad control of the organization, and only when that person needs that control. An IT or operations job title is not a reason to give someone Admin.
Set up access-level profiles before inviting your team. These work like your organization's custom roles: named sets of access levels that you can reuse for people with similar responsibilities.
Use this guide when inviting your team or reviewing an existing member's access.
What are organization access levels?
Organization access levels are the access levels configured for each member in My → Users → Edit → Access Levels, either directly or through an access-level profile. They control that member’s access to features within the organization; they are not a setting shared by every member.
Some features also have resource-specific access levels. For CMS, site access levels are configured separately for each site in App → CMS → Site Settings → Access & Roles. A User needs both CMS: Access in their organization access levels and the appropriate site access levels.
Choose the system role first
| System role | When it fits | How access works |
|---|---|---|
| Owner | The person responsible for the organization. | Broad access to enabled organization features and owner-only responsibilities, including assigning other members' system roles. Ownership is established separately; it is not a role to select in an ordinary user invitation. |
| Admin | An exceptional assignment to a person the Owner deeply trusts with broad control, where that control is necessary. | Access levels do not restrict this role. Some owner-only actions remain unavailable. |
| User | A team member who needs selected tasks or limited access. | Assign access levels for the categories they need. A category left as None grants no feature-specific access through that category. |
An Admin role does not enable features outside the organization's subscription. If someone only needs to manage one area, start with User and the relevant access levels.
Examples of role choices
These are examples to help you decide, not automatic assignments. The appropriate levels depend on the actions included in the categories available to your organization.
| Person and responsibility | Suggested role | Access to consider |
|---|---|---|
| Organization owner responsible for the account | Owner, through the ownership process | Keep ownership with the accountable person. Use User with a suitable access-level profile for most colleagues. |
| A person the Owner deeply trusts and explicitly authorizes to administer the organization broadly | Admin, as an exception | Assign only when broad control is necessary. For limited responsibilities, use User with an appropriate profile instead. |
| Content editor who writes and updates website content | User | Content-related access for the required tasks and specific CMS sites. Site configuration is needed only if the person also manages those settings. |
| Reviewer who only needs to inspect content | User | Levels that allow viewing in the required areas, with access to the relevant sites. Check that editing actions are not included. |
| Finance colleague who handles bills and payments | User | The billing actions needed for that work. Do not grant unrelated content or organization administration unless their responsibilities require it. |
For example, two people working with CMS may need different access: an editor needs to update content, while the person maintaining site configuration needs the corresponding settings access. Neither job automatically requires Admin.
Why the available categories differ
The feature-specific access-level categories shown in a user's permission configuration depend on the organization's active subscriptions and the features they enable. Built-in categories can also appear without a subscription.
For example, an organization with CMS enabled can see its applicable CMS categories. An organization without CMS enabled will not see those feature-specific categories. Two organizations may therefore offer different category lists.
If an expected category is missing:
- Confirm the active organization.
- Review Subscriptions on My Platform using the Organization setup checklist.
- Ask your Industrix administrator to confirm that the expected feature is enabled.
Changing a person's role or choosing an access-level profile cannot add a feature that the organization does not have.
Use access-level profiles as custom roles
We recommend setting up profiles early, before inviting users. Create profiles around recurring responsibilities, such as Content editor, Content reviewer, or Finance. This makes later invitations easier and keeps access selections consistent.
The person's system role remains User. Their profile supplies the access levels for their work; it does not create a new system role or grant Admin access. When inviting someone, select the relevant profile and review the resulting selections. Configure individual category levels directly when the person needs a different combination.
Follow Set up access-level profiles to create your organization's profiles. Updating a profile later does not automatically change access already applied to users; review existing users separately when responsibilities change.
Read the actions included in each level. Category levels are independent: access to content does not automatically provide access to site settings or billing. Leave unrelated categories as None.
Access to a specific resource may also be needed. A User with CMS content permissions may still need a grant for the particular site. See Understand your access for the complete distinction.
Keep subscription, license, and permissions separate
- Subscription: features available to the organization.
- User license: a person's entitlement to a feature when individual licensing applies. Current subscriptions do not require individual user licenses.
- Permissions: actions the person can perform through their role, access levels, and any required resource grants.
After choosing access, return to Invite your team to send the invitation and confirm that the person can perform the intended work.