Security and data protection
Access control and single sign-on
How your team signs in, how access is limited by role for people and agents, what is logged, and how Telonic's own engineers reach your deployment.
On this page
Conversation data is sensitive, and the smaller the circle of people who can see it, the safer it is. Telonic lets your team sign in with the accounts it already uses, gives each person and each agent only the access its role needs, and logs every access and change. Access by Telonic's own engineers is limited, time-bound and logged, and in your own environment it needs your approval each time. This page explains each of those controls.
Signing in with your own identity provider
Your team signs in to the Telonic console (the web application your team uses to review conversations, records and reports) through single sign-on with your own identity provider (the system that manages your staff's logins). Single sign-on means people use their existing work account, and your identity provider confirms who they are. Telonic supports SAML 2.0 (a standard for passing sign-in confirmation from an identity provider to an application) and OpenID Connect (a newer standard that does the same job).
Sign-in requires multi-factor authentication (a second check beyond a password, such as a code or an approval on a phone). Because sign-in happens at your identity provider, your own password rules, multi-factor methods and sign-in policies apply to Telonic as they do to your other systems.
Access by role
Each person has only the access their role needs, a principle known as least privilege. Roles are agreed with you during implementation, and your administrators assign them. A role can be limited further, for example to one business unit or one brand, so that a team sees only its own conversations.
| Role | What it can do | Typically held by |
|---|---|---|
| Administrator | Assigns roles, and changes limits, topics, escalation and handover rules, approvals and retention through the controls your team holds | The owner of customer experience systems, with IT |
| Supervisor | Reviews conversations and handovers for their team, and approves actions the agent has held for approval | Contact centre and team leaders |
| Reviewer | Reads conversations and quality scores in the Conversations and Quality views, and marks conversations for follow-up | Quality assurance team |
| Analyst | Uses the Overview and Insights views and reports, with personal information redacted by default | Customer experience analytics |
| Auditor | Reads the audit record and decision records, without the ability to change anything | Compliance, risk and internal audit |
Access for agents
Each agent also has only the access its role needs. Its access to your systems is granted system by system, with read access and write access granted separately. Actions that make decisions belonging to your team, such as approving a claim, are not connected to the agent at all. See Permissions and Decision boundaries.
What is logged
Access and changes are logged: sign-ins, role assignments and changes, changes to limits, rules, approvals and retention, the conversations and records people open, exports, and deletions. Each entry records who, what and when.
Entries are added to the log and never changed. Your auditors can read it through the auditor role. See Audit trail and decision records.
When people join, move or leave
Access follows your identity provider. A new starter can sign in once they have a work account and an administrator has assigned them a role. When someone moves team, an administrator changes their role. When someone leaves and their account is disabled in your identity provider, they can no longer sign in to Telonic.
We recommend reviewing role assignments on the same cycle as your other systems. Your administrators can see who holds each role at any time.
Access by Telonic engineers
Access by Telonic staff is limited to named engineers who operate and support your deployment. They work from the UAE or from the country you choose, their access is granted for a limited time for a specific task, and every access is logged. Telonic engineers sign in with multi-factor authentication, and their access is removed when the task is complete.
In your own cloud account or on your own premises, each access needs your approval. You are told which engineer needs access, for what task and for how long, and the access ends when the approved period ends.
In practice
Sahel Crest Properties, a Dubai developer, sets up access before going live.
- Its IT team connects Telonic to the company's identity provider using SAML 2.0. Sign-in requires the company's usual multi-factor check.
- The head of customer experience is an administrator. Two sales team leaders are supervisors, limited to the developer's two brands respectively.
- The quality team holds the reviewer role, the marketing analysts the analyst role, and the internal audit team the auditor role.
- When a sales executive leaves, IT disables her work account, and she can no longer sign in to Telonic.
- Internal audit checks the audit log each quarter and confirms who changed which limits and when.
What your team controls
- Which identity provider and sign-in standard are used, and your sign-in policies.
- The roles, and who holds each one.
- The business units or brands each role can see.
- In your own cloud account or on your own premises, approval of each Telonic engineer access.