Key takeaways on roles and access rights
- Raisetalk draws a clear line between two questions: what a user is allowed to do (their permissions) and which data they are allowed to see (their scope). The first depends on their role, the second on their place in the org chart.
- Three default roles cover most organisations: Administrator, Operational manager, Advisor. Ready to use, with no configuration at all.
- Need to go further? A Roles screen lets you build custom roles: one label per language, a permissions matrix to tick, and role assignment delegated to the right owner.
- Two established security models, combined: RBAC (permissions by role) and ABAC (visibility based on position in the org chart). One decides who can do what, the other who sees which data.
- A role is never deleted: it is deactivated. Access is cut immediately, the role can no longer be assigned, and nothing of the history is lost.
Quality is everyone's business, not just the managers'
Quality monitoring is often thought of as a managers' tool: you install the platform, a few team leads log in, and advisors are kept away from their own data. That's a waste. An advisor who sees their conversations analysed, their strengths and their areas for improvement, progresses faster than an advisor debriefed once a month. This is where skills development really happens, as close to the front line as possible.
Involving everyone, however, means answering one simple question cleanly: who has access to what? Without a clear answer, two bad habits set in. Either you share a single account across the whole team, and traceability disappears. Or you open everything to everyone, and an advisor ends up viewing their colleagues' assessments, or the company's billing.
The right answer is neither "everything closed" nor "everything open". It's giving each person exactly their scope of responsibility: no more, no less. That is precisely what Raisetalk's Roles screen handles.
Three default roles, ready to use
Every organisation starts with three roles, designed to cover the vast majority of needs without the slightest adjustment.
| Role | For whom | What they can do | What they see |
|---|---|---|---|
| Administrator | The person or people in charge of the tool | Everything: settings, analysis grids, users, billing, and role management | The entire organisation |
| Operational manager | Team managers | Follow and create conversations, assess, steer their teams, receive managerial alerts | Their team and the teams attached below |
| Advisor | Front-line staff | View their conversations, their assessments and their feedback | Their own data only |
This split is enough for most companies. An administrator configures and steers, a manager leads their teams, an advisor works on their own conversations. The default roles have labels managed by the application in each language, and the Administrator is a system role: its permissions cannot be changed and it can never be deactivated, to avoid locking yourself out of your own tool.
Building a custom role as the organisation grows
Past a certain size, three roles are no longer enough. A "strategic manager" who steers without touching the grids, a "quality lead" who handles disputes without administering accounts, a "level 2 support" agent: every organisation has its nuances. Rather than forcing them into a mould, Raisetalk lets you create custom roles.
From the Roles menu, reserved by default for administrators, you create a role in a few moments:
- One label per language, so that everyone sees the role in their own language. The technical key itself is generated automatically from the French label: nothing to enter.
- A permissions matrix to tick, organised into clear families: Conversations, Grids and analyses, Automations, Reporting and discovery, Support, Organisation. You enable exactly what the role should be able to do, family by family.
- Assignment delegation: each role generates its own assignment permission. You decide who, in the organisation, can grant this role to a user. A regional manager can thus manage the roles of their region without becoming an administrator of the whole company.
The Administrator column stays read-only: this system role keeps all its permissions, by design. For every other role, the matrix is your dashboard of authorisations, readable at a glance.
Deactivate a role, never delete it
A role carries users, a history, assessments. Deleting it would leave holes. Raisetalk therefore does not allow it: a role that has become useless is deactivated.
Deactivation has immediate and unambiguous effects:
- Users with that role can no longer log in, and their current sessions are cut on the next request.
- The role can no longer be assigned to new users.
- It no longer receives team alerts.
Reactivation restores access just as quickly. The Administrator, once again, is the exception to the rule: it cannot be deactivated. The result: you adjust your organisation without ever fearing you'll lose data or lock yourself out.
Under the hood: RBAC and ABAC, the duo that secures the whole
Two access control models are the industry reference. Raisetalk relies on both, because they answer two different questions.
RBAC (Role-Based Access Control) answers "who can do what". Permissions are not attached to a person but to a role. You assign a role to a user, and they inherit all its permissions; you evolve the role, and everyone who carries it follows. This is exactly what the permissions matrix handles: assess a conversation, manage a grid, access reporting, handle a support request. One permission, one box, one role.
ABAC (Attribute-Based Access Control) answers "who sees which data". Here, access no longer depends on the role alone but on an attribute of the user: their position in the org chart. By default, everyone sees the data of their team and of the teams located below them in the hierarchy. A manager sees their managerial scope; the same role, placed higher in the org chart, sees more widely, without anything being reconfigured. The Advisor, meanwhile, is deliberately restricted to their own data alone, wherever they sit in the tree.
The combination is what makes the system both simple and safe. The role decides the actions; the org chart decides the data scope. You don't have to recreate a role per team: a single "Operational manager" role suits all your managers, each one seeing only their own scope. It's this coupling that lets you involve every member of staff without ever exposing data to the wrong recipient.
This scope-based logic actually extends beyond the company. For our integrator partners, such as SYD Digital Care, isolation by scope guarantees that one client instance never sees another's data, including through the Support module.
Getting started
- Log in to your Raisetalk workspace with an administrator account.
- In the menu, open Roles: there you'll find your three default roles and their users.
- Check that each member of staff carries the right role. For most teams, the three default roles are enough.
- Need a custom role? Click New role, name it in your languages, and tick its permissions in the matrix.
Giving each person their fair scope is the condition for quality to become everyone's business, and no longer just that of a few managers. The detail of the permissions, family by family, is described in the Roles and permissions documentation of your workspace.
