Security and data
Authentication and access
Sign-in methods, the role model, single sign-on, and how access is scoped between organisations.
#Sign-in methods
| Method | Availability |
|---|---|
| Email and password | All accounts |
| All accounts | |
| Your own identity provider | Enterprise accounts, by agreement |
Enterprise accounts can authenticate against their existing identity provider, Okta for example, so users sign in with the credentials they already have and access is governed by your existing joiners and leavers process.
If single sign-on is enabled for your organisation, use it as the only route. Password accounts and single sign-on identities are not automatically the same person, and a stray password account is an access route that survives your directory removing someone.
#Roles
Access is governed by a list of roles per user, drawn from admin, manager and user. A user holds several, and the surface changes to match, so one person does not need a second login to hold a second capacity.
Team membership carries its own role in addition, which is how a manager can manage one team while being an ordinary user elsewhere in the account.
Full detail in Users, teams and roles.
#What an administrator can and cannot reach
An admin role grants configuration (users, teams, knowledge, personas, products, scorecards, roleplays) and reaches the account's records across the whole company rather than one team: roleplay transcripts, call transcripts and scorecard results. It also permits resetting a user's coaching history.
Coaching conversations reach an administrator the same way they reach a manager, as summary and observations through a coach rather than as a transcript. See What you can see.
Reps will ask. Give them the real shape rather than a reassurance that will not survive contact: roleplays, call transcripts and scores are visible to their manager, and what they work through with their coach travels upward as what they are working on rather than as a transcript. Vagueness here costs you adoption, because people assume the worst version.
#Separation between organisations
Each organisation's account is scoped separately. Knowledge, personas, scorecards, roleplays and conversations belong to one account, and requests are scoped to the account of the signed-in user.
Where your deployment is delivered through a partner, you contract with that partner and the software is supplied to them. The same account separation applies.
#Leavers
Deactivate to remove access while retaining history. Delete when the person, their data or the account must actually be erased. Deactivation is reversible; deletion is not. See Data, retention and deletion.
Last updated 3 September 2026
View as Markdown