Integrations
Permissions: what the agent can and cannot do in each system
How access to each of your systems is granted, limited, approved and logged, with example permission sets for property, travel and insurance.
On this page
- Each system has its own integration account
- Read and write are granted separately, action by action
- Decisions that stay with your team are never connected
- Sensitive actions wait for a person's approval
- Example permission sets
- How credentials are held and rotated
- Every call is logged
- In practice
- What your team controls
- Related
The agent can do in your systems exactly what your team has granted, and nothing else. Access is set system by system and action by action, through accounts your administrators create and control. Decisions that belong to your people are never connected, sensitive actions wait for a person's approval, and every call the agent makes is logged. This page explains how that works, and shows what a typical permission set looks like in property, travel and insurance.
Each system has its own integration account
The agent connects to each of your systems through a dedicated integration account: an account created only for this connection, separate from any member of staff's login. Your administrators create it in your own system, in the same way they would for any other service that connects to it.
Because the account is yours, your team can see what it is allowed to do, review its activity in your system's own logs, and suspend it at any time. Suspending the account stops the connection straight away, without any change on the Telonic side. The agent then tells customers it cannot complete that kind of request and offers a person.
Read and write are granted separately, action by action
Access follows the principle of least privilege: the integration account has only the access the agent's role needs. Read access and write access are granted separately for each system. Within write access, each action is granted on its own, so an agent that can create a maintenance request cannot, as a result, change a unit's price.
An action that is not granted cannot be invoked. The agent is not asked to avoid it; there is nothing for it to call, however a customer phrases the request. Where the agent can act, the values it can use come from your rules.
It can offer the rebooking options a fare permits, or a voucher within your limit, and nothing beyond them. See Policies as limits.
Decisions that stay with your team are never connected
Some actions exist in your systems but are never made available to the agent. In insurance, the functions that assess liability, set a settlement amount, or approve or decline a claim are not exposed to the agent in any deployment. The same approach applies to the decisions you keep with your team in property and travel, such as a refund outside policy or a change to a payment plan.
The difference matters to anyone assessing risk. A rule that says "do not approve claims" depends on the system following it. An integration that has no approval function connected cannot approve a claim. See Decision boundaries.
Sensitive actions wait for a person's approval
Between what the agent does on its own and what it never touches, there are actions you want a person to check first. For these, the agent prepares the action with everything needed to approve it, and holds it until a named person on your team approves or declines. The customer is told what happens next and when.
You decide which actions need approval, and who approves them. A common pattern is to start with approval on more actions and remove it once your team is confident in how they are handled.
Example permission sets
Every deployment's permissions are agreed with your IT team during implementation. The examples below show typical starting points. The CRM in each is the system that holds that organisation's customer records.
Property: a developer's CRM, handover calendar and maintenance system
| System | Read | Actions granted | Needs approval | Not connected |
|---|---|---|---|---|
| CRM | Contacts, units, payment schedules | Create and update leads, add conversation notes | None | Change unit prices, change payment plans |
| Handover calendar | Available slots | Book and reschedule handover appointments | None | Delete other bookings |
| Maintenance system | Requests for the customer's unit | Create a maintenance request, add a note | None | Close or reassign requests |
| Payment provider | Payment status | Send a payment link for an amount due | Links for amounts not on the schedule | Refunds |
Travel and hospitality: a hotel group's reservation system and service desk
| System | Read | Actions granted | Needs approval | Not connected |
|---|---|---|---|---|
| Reservation system | Reservations, rates, availability, rate rules | Change dates within the rate rules, add requests to a stay | Upgrades, fee waivers | Refunds outside policy, rate overrides |
| Service desk | Tickets for the guest | Create a ticket, add a comment | None | Close tickets |
| CRM | Guest profile and loyalty tier | Add conversation notes | None | Change loyalty points |
Insurance: a motor insurer's policy and claims systems
| System | Read | Actions granted | Needs approval | Not connected |
|---|---|---|---|---|
| Policy administration | Policy, cover, excess, approved wording | None | None | Change cover, issue endorsements |
| Claims system | Claim status and outstanding documents | Create a claim (first notice of loss: the first report of a claim), attach documents, add a note | None | Assess liability, set a settlement amount or reserve, approve or decline a claim |
| CRM | Policyholder contact details | Add conversation notes | None | Merge or delete customer records |
How credentials are held and rotated
The credentials for each integration account are stored encrypted in your deployment, using AES-256 (the Advanced Encryption Standard, using 256-bit keys), and are never written into the agent's instructions or visible to the language model. Where a system supports OAuth (a standard that lets one system grant another limited access without sharing a password), it is used in place of a stored password.
Credentials are rotated (replaced with new ones) in line with your security policy, and immediately if either side suspects they have been exposed. In your own cloud account or on your own premises, credentials stay inside your environment, protected with keys you control. Every connection to your systems uses TLS (Transport Layer Security, the standard encryption for data in transit), version 1.2 or higher.
Every call is logged
Every call the agent makes to your systems is recorded in the audit trail: which system, which action, which record, when, for which conversation, and the result. Your compliance team can open any conversation and see exactly what the agent read and what it changed. Your own system's logs show the same activity against the integration account, so the two can be reconciled. See Audit trail and decision records.
In practice
Wadi Assurance, a motor and home insurer, sets the permissions for its claims deployment.
- The claims, compliance and IT teams meet with Telonic to agree what the agent will handle: first notice of loss, claim status and document collection.
- The IT team creates an integration account in the claims system with three actions: create a claim, attach a document and add a note. No action that changes a claim's status or reserve (the amount set aside to pay a claim) is granted.
- Compliance asks for approval on one action: any message to a policyholder that states a claim has been closed.
- Tariq reports a collision at 9pm. The agent creates the claim and attaches his photographs. When he asks whether the other driver's insurer will pay, the agent explains that his claims handler will decide that and tells him when to expect contact.
- At the quarterly access review, the IT team compares the integration account's activity in the claims system with the Telonic audit trail. They match.
What your team controls
- The integration account for each system, including suspending it.
- What the agent can read and write in each system, and which actions it can take.
- Which actions wait for approval, and who approves them.
- When credentials are rotated.