Role Based Access

What is Role-Based Access?

Role-Based Access (RBA) allows account Owners to define exactly what each user role (Admin and Member) can view and do inside the platform. Instead of only turning entire modules on or off, Owners can configure granular, tab-level permissions so each team member sees only what they need.

This system improves data security, reduces operational friction, and aligns QuickReply with enterprise-grade permission standards.

Why Use Role-Based Access?

Businesses often manage teams with different responsibilities, such as support agents, team leads, campaign managers, and analysts. Without granular access control, members may see sensitive conversations, analytics, reports, or integrations they should not handle.

Role Based Access will be present in the Security Tab and Access Control for the owner

Role-Based Access helps you:

  • Protect sensitive information by limiting visibility.

  • Speed up onboarding with pre-configured permissions.

  • Improve accountability by restricting access to specific features.

  • Reduce accidental changes by limiting high-risk actions

  • Reduce dependency on support/tech teams for permission adjustments.

How Role-Based Access Works

RBA is built using a Parent–Child permission structure:

Parent Permissions

These represent main modules like:

  • Conversations

  • Live View

  • Prospects

  • Team

  • Analytics

  • Campaigns

  • Broadcast

  • Journeys

  • AI Builder

  • Data Sources

  • Integration

Toggling a parent enables visibility of the module.

Child Permissions

These represent granular actions or internal views under each module. Examples:

  • All Chats View

  • My Chats View

  • Unassigned Chats

  • Drip Campaign View

  • Journey View

  • Download Report

  • Export Contacts

  • Download Campaign Stats

When a parent is enabled, child options automatically expand for configuration.

Smart Rules

To maintain logical consistency:

  • If a child permission is selected, the parent auto-enables.

  • My Chats is always enabled (pre-ticked and non-editable) for both roles.

  • If Priority/Starred is unselected, the view hides from the user, but starring in chat still remains functional.

  • Custom Views respect RBA and follow the same permission logic.

Only Owners can modify the Role-Based Access settings.

Last updated

Was this helpful?