Custom portal roles let you define exactly which administrative permissions a user has in the knowledge base portal. Use them when the default roles — Owner, Admin, Contributor, and Reviewer — do not match your team's requirements.
When to create a custom portal role
- A Contributor needs access to a specific feature (such as event notifications) without gaining full Admin access.
- You want to create a read-only admin role that can view settings but cannot change them.
- Different team members need different subsets of portal permissions that don't map to any default role.
Before you begin
You must have the Owner or Admin portal role.
How to create a custom portal role
-
Navigate to Settings () > Users and security in the left navigation bar in the knowledge base portal.
-
In the left navigation pane, navigate to Roles and permissions.
-
Click the New portal role button at the top right of the Portal role tab.
The Create portal role panel opens.
-
Enter a name for the new role and add a description.
-
From the list of features, select the View and Update checkboxes for the desired features based on your requirements.
-
Click Create role.
Portal role permissions reference
Each feature has two permission levels: View and Update.
| Feature | What it allows |
|---|---|
| Project settings | Access and modify overall project settings, including basic configurations and preferences |
| Team auditing | Monitor and manage team activities, track events and changes within the project |
| Event notifications | Set up and manage notifications about project activities; configure notification channels and email domains |
| API tokens | Access and manage API tokens for integrating with external systems and automating tasks |
| Extensions | Manage extension services that enhance knowledge base site functionality |
| Backup & restore | Set up and manage backup and restoration processes |
| Site domain | Manage the custom domain for the knowledge base site |
| Custom CSS & JavaScript | Access and manage custom CSS and JavaScript scripts to customize appearance and functionality |
| Integrations | Access and manage integrations that connect the project with other tools and services |
| Cookie consent | Access and update the cookie consent policy |
| Announcements | Manage smart bars and announcements on the knowledge base site |
| Ticket deflector | Manage ticket deflectors that direct users to relevant content before they submit support tickets |
| Knowledge base widget | Set up, access, and manage knowledge base assistants |
| Roles, accounts & groups | Access and manage users, readers, and groups, along with their roles |
| Site visibility | Modify reader access settings (Public, Private, or Mixed) |
| IP restrictions | Manage which IP addresses can access the knowledge base site |
| Enterprise SSO | Access and manage SSO and JWT configurations |
| Billing & invoice | Access and manage billing services, including invoices and subscriptions |
Example: Providing view-only access to specific categories
This example shows how to give a user view-only access to specific categories in the portal without giving them editing or publishing permissions.
Create a custom content role
- Navigate to Settings () > Users and security in the left navigation bar in the knowledge base portal.
- In the left navigation pane, navigate to Roles and permissions.
- Go to the Content role tab and click New content role.
- Enter a name and description for the custom content role.
- Check the View option for Categories only.
- Click Create role.
Assign the custom content role to the user
- Navigate to Settings () > Users and security in the left navigation bar in the knowledge base portal.
- In the left navigation pane, navigate to Users and groups.
- Click Add > User. The New user dialog opens.
- Enter the user's email and select a project role.
- In the Content role & access section, select the custom content role you created.
- In Content access, select Category and choose the specific categories you want to grant view-only access to.
- Click Create user.
Best practices
- Give custom roles descriptive names that reflect what they are for — for example, "Support Lead — Announcements Only" rather than "Custom Role 1".
- Grant the minimum set of permissions needed. Add more permissions only when the user needs them.
- Use View without Update when you want a user to be aware of a setting without being able to change it.
- Review custom roles periodically to ensure they still reflect your team's current structure.