Integrations
Custom actions: connecting systems not listed
How the agent connects to your in-house, regional and older systems, through any interface your organisation can expose.
On this page
Much of the work in a large organisation lives in systems no vendor list will ever include: a handover scheduling tool built in-house, a regional policy administration system, a reservations platform that has run for fifteen years. The agent connects to these through custom actions. If your organisation can expose a system through some kind of interface, the agent can look things up in it and act on it, under the same permissions and the same audit trail as any other connection. Custom actions are defined with you during implementation.
What a custom action is
A custom action is one defined operation the agent can perform in one of your systems, such as "find the handover appointment for this unit" or "add a note to this policy". Each action is written down with five things:
| Part | What it defines | Example |
|---|---|---|
| Name and purpose | What the action is for, in plain words | "Book a handover inspection" |
| Inputs | What the agent must supply, and in what form | Unit reference, preferred date |
| What it reads or changes | The records and fields involved, and nothing else | Handover calendar, one appointment record |
| Permitted values | The limits your rules set | Weekdays only, 9am to 4pm, at least three working days ahead |
| Result | What the system returns, and what the agent tells the customer | Confirmed slot and reference, or the next available slots |
Once defined, a custom action behaves exactly like a named integration. It is granted to the agent as its own permission, tested before go-live, and logged every time it is called.
The interfaces we connect through
Telonic connects to whatever interface your system already offers. The choice depends on what the system supports and what the agent needs to do with it.
| Interface | What it is | Suited to |
|---|---|---|
| API | An application programming interface: the documented way other software exchanges data with a system. Includes web APIs in the REST or SOAP styles (two common conventions for how such requests are written) | Looking things up and taking action during the conversation |
| Database view | A read-only window onto selected tables in your system's database, prepared by your team, showing only the fields the agent needs | Looking things up in older systems with no API |
| File exchange | Files passed between your system and your deployment on a schedule, over SFTP (secure file transfer protocol) or a similar secure channel | Reference data that changes daily rather than by the minute, and batches of updates written back |
| Automation platform | A tool your teams already use to link systems, such as Zapier or Make, which the agent can trigger. Configured during implementation | Starting an existing automation, or reaching a system the platform already connects to |
The technical detail
Each custom action runs from your deployment, in the region you choose, over an encrypted connection using TLS (Transport Layer Security), version 1.2 or higher. Credentials for the interface are stored encrypted in your deployment with AES-256, and the connection uses a dedicated integration account (an account created only for this connection) that your administrators control.
Where data arrives by file exchange rather than live lookup, it is only as current as the last file. We agree with you which questions it is suitable for, and the agent's answer reflects that: for example, "as of this morning, your claim is with the assessor".
Older and in-house systems
If a system has any kind of interface, the agent can work with it. Older systems often have more than people expect: a database that can offer a read-only view, a scheduled export another team already relies on, or an internal service written years ago that other applications already call.
We establish which of your systems are in scope before you commit, rather than at contract. For each one, we identify the interface, what the agent can do through it, and what your team needs to provide. Where no interface exists at all, we agree with your team the simplest way to make the data available, which is usually a task they already know how to do. See What we need from your IT team.
The same permissions and audit trail
A custom action carries exactly the controls of every other connection. Read and write are granted separately. An action that is not granted cannot be invoked.
Actions you mark as sensitive wait for a person's approval, and every call is recorded in the audit trail with its result. See Permissions.
How a custom action is defined
Custom actions go through the same stages as every connection: map, connect, test, go live and monitor. The map is where each action is written down and agreed with your process owners and IT team. The tests use conversations drawn from your processes, including the requests the action should refuse. See How a system gets connected.
In practice
Wadi Assurance, an insurer, runs home claims on a policy administration system built for it many years ago. The system has no API.
- Its IT team confirms the system's database can offer a read-only view of policy cover, excess and claim status. They create the view with only those fields, and an integration account that can read nothing else.
- For new claims, the insurer already uses a scheduled file import into the claims system. Telonic defines a custom action that writes each new first notice of loss into that import, in the format the system already accepts.
- Both actions are tested with conversations drawn from the claims team's own cases, including a policy with an exclusion the agent must explain from the approved wording.
- Noura calls about water damage. The agent reads her cover and excess from the view, takes the first notice of loss, and tells her when her claim reference will be confirmed.
- The claims team picks up her claim from the next import, complete, with the full conversation attached.
What your team controls
- Which of your systems the agent connects to, and through which interface.
- The definition of each custom action, including its permitted values.
- The integration account and its access, which your team can suspend at any time.
Related
- Integrations overviewIntegrations
- How a system gets connectedIntegrations
- PermissionsIntegrations
- Automation platformsIntegrations
- What we need from your IT teamIntegrations
Product names and logos are trademarks of their owners. Their mention shows systems Telonic connects to and does not imply partnership or endorsement.