Role-Based Access: Who Should See What in Your Chat Dashboard

Your chat dashboard holds things with different levels of sensitivity. Conversations contain customers' words and contact details. Settings control what your assistant says. Billing pages hold your plan and invoices. AI provider keys can spend money. Not everyone on your team needs to see or change all of it. The receptionist who replies to visitors does not need to change your billing plan; the accountant who downloads invoices does not need to read customer conversations; a contractor updating your knowledge base should not be able to delete the whole workspace. Role-based access control, or RBAC, is the practice of giving each person a role that grants exactly the access they need. This guide explains the idea, describes the roles typically used in a workspace such as Crescelo's (owner, admin, billing manager, support agent and viewer), gives a sample matrix, shows how to assign roles using least privilege, how to handle joiners and leavers, how to use an audit trail and how to review access regularly. Check the exact permissions in your own dashboard, since they can be refined over time.

Why roles matter

• Privacy: fewer people see customers' conversations.
• Safety: fewer people can make destructive or costly changes by mistake.
• Accountability: named accounts with roles show who did what.
• Compliance: data protection rules expect access limited to those who need it.
• Resilience: if one account is compromised, the damage is limited to what that role can do.

The roles

In Crescelo's workspace, owners and admins have full access, and other roles are limited to the areas that suit them, for example billing pages for billing managers. Some actions require a specific role, and master administration of the platform is a separate, protected role held by the platform operator.

A sample role matrix

This is a suggested pattern for planning, not a statement of exact permissions. Confirm what each role can do in your dashboard before relying on it, and test by signing in as each role.

Apply least privilege

1. Start every new person at the lowest role that lets them do their job.
2. Raise access only when there is a specific need, and lower it when the need ends.
3. Keep owners to one or two people.
4. Give contractors the narrowest role and remove it when the project finishes.
5. Prefer separate accounts over shared logins; never share a password.
6. Review the sensitive areas separately: provider keys, billing and exports.

Joiners, movers and leavers

In Crescelo, sessions are checked against the account's current role and workspace on each request, so demoting or removing a member takes effect immediately, not when their session expires.

Add two-factor authentication

Roles limit what an account can do; two-factor sign-in reduces the chance of someone else using it. Prioritise owners and admins, since their accounts can change everything. See securing your chatbot account for setup steps.

Use the audit trail

• Review the log of important actions monthly: changes to settings, sources, keys and members.
• After any incident, check who did what and when.
• Investigate unexpected changes promptly, and ask the person who made them.
• Use it to improve roles: if a support agent keeps needing an admin action, decide whether they need that access or a process change.

Review access on a schedule

Put the review in the calendar, since access tends to accumulate silently. Link it to your regular chat analytics review.

Data isolation is the other half

Roles decide what a person can do inside a workspace. Isolation decides that nobody outside it can see in. A trustworthy platform does both; see multi-tenant data isolation for the platform side.

Common mistakes

• Making everyone an owner.
• Sharing one login.
• Leaving contractor access in place.
• Never reviewing roles.
• Giving support staff access to keys and billing.
• Assuming roles replace two-factor sign-in.

A worked example

A dental practice has six people using the dashboard: the practice owner, an office manager, two receptionists, a part-time marketing freelancer and the practice's accountant. The owner keeps the owner role and turns on two-factor sign-in. The office manager becomes an admin, because they maintain the assistant's documents. The receptionists get the support agent role, so they can read conversations and take handovers but cannot change instructions or see keys. The freelancer is a viewer for the month of a campaign and is removed afterwards. The accountant is a billing manager and never sees a conversation. Each person can do their job, and nobody can reach anything they do not need.

Handle exceptions deliberately

Sometimes a person needs more access than their role allows for a specific task, such as a receptionist who must update opening hours before a holiday. Rather than promoting them permanently, change the setting yourself or grant a higher role temporarily and record when to remove it. Put the removal in the calendar. Temporary access that is never withdrawn is the most common way roles drift away from least privilege over time.

Frequently asked questions

See how your data is protected, the human handover feature and pricing.

Further reading

• Google Search Central: creating helpful, people-first content: What Google looks for in useful pages.