/ /
Roles control what users can access and do within your workspace. DevRev provides separate role management for external users (customers) and internal users (team members). For conceptual background on the privilege model and how roles relate to groups and users, see Access control.
External user roles
External user roles define the permissions customers have when accessing your portal, creating tickets, and interacting with your workspace. These roles are applied to customers through customer groups, Customers, Customer Admins, and Verified Customers, so changes to a role affect all members of the groups assigned to it. For more on how groups work, see Groups.
To create a new role before configuring it, see User roles.
Configure customer role privileges
Select the role you want to configure (for example, Customers role).
Configure the role details:
Role name: The display name for this role.
Description: A brief explanation of what this role allows.
Ticket privileges
Control how external users interact with tickets:
In the Privileges section, expand Tickets.
Configure ticket access:
Create tickets: Allow users to submit new tickets.
View own tickets: Users see only tickets they created.
Create and view all tickets: Users can see all tickets in their workspace.
To add custom conditions for ticket fields, select Custom conditions and then Add field access.
Ticket field access control
Field-level permissions are a separate layer on top of object-level access, a user must have object-level access to a ticket before field-level restrictions apply. Field-level permissions apply to both internal and external roles and are configured within the same role configuration UI. For full details on configuring field-level access, including subtypes and inheritance, see Field Access Control.
To restrict which ticket fields external users can view or edit:
Expand Ticket fields under the Privileges section.
Select Clear to remove default access, then choose Custom.
Add specific fields individually, such as Severity, Source channel, Title, Description, and Tags.
For each field, configure read and write permissions using the checkboxes.
Conversation and contact privileges
Configure additional external user capabilities in the Privileges section:
Conversations: Allow users to participate in conversations and view conversation history.
Contacts: Control whether users can view and manage contact information.
Workspace: Define workspace-level visibility for external users.
đź“ť Note: The specific options available in this section depend on your workspace configuration. Verify the available settings in your environment when configuring these privileges.
Test external user permissions
After configuring role privileges:
Open your portal in a new browser window or incognito mode.
Log in as an external user with the configured role.
Attempt to create a ticket and verify:
Available fields match your configuration.
Field access restrictions work as expected.
Subtype-specific permissions apply correctly.
Check the created ticket from both external and internal perspectives to confirm field visibility.
Internal user roles
Internal user roles govern what team members can do within your workspace, including creating and managing work items, accessing customer data, and modifying workspace settings.
To create a new internal role, see User roles, which also covers assigning roles to individual users and groups.
Update role privileges
Modify existing internal roles to adjust team member permissions:
Select the role you want to update.
Configure privileges across different categories, including Tickets, Issues, Opportunities, Accounts, and Contacts.
Save your changes.
⚠️ Warning: Changing internal role privileges affects all users assigned to that role. Review changes carefully before saving.
Privilege resolution for users in multiple groups
When a user belongs to multiple groups that have different roles assigned, DevRev grants the highest applicable privilege across all of those roles. This means a more permissive role in one group can expand what a user can do beyond what a more restrictive role in another group would allow. Keep this in mind when designing role and group structures. For more detail, see Access control.
Best practices
Apply least privilege. Grant only the minimum permissions needed for users to complete their tasks, and add privileges as requirements emerge. Use the User roles page to review what each role currently allows before expanding access.
Test from actual user accounts. After configuring roles, log in as a user with that role—or use the portal testing steps above for external roles—to verify that permissions behave as expected rather than relying on configuration review alone.
Use clear role names and descriptions. The description field on each role is visible to administrators in Settings > User Management > Roles. Populate it so that future administrators understand the intended scope of each role without having to inspect every privilege.
Audit role configurations periodically. As your team and customer base evolve, roles that were appropriate at setup may grant more or less access than intended. Regular review against your current security and workflow requirements prevents privilege drift.
Create distinct roles for different customer segments. If different groups of customers need different access levels—for example, standard customers versus customer admins—configure separate roles and assign them to the appropriate customer groups rather than broadening a single shared role.
Was this article helpful?