RMT Engineering Logo
Integrations

Contact Centre Integrations

The question that decides most evaluations is not what the platform does on its own. It is whether it talks to the CRM, the service desk and the carrier you already pay for. This page is the list. What is pre-built, which direction each connector runs, and what happens when the tool you run is not named on it.

  • Pre-built connectors for the usual tools
  • Two-way where it matters
  • A documented path for the rest
We reply within one business day. No newsletter.
100+ Connectors and custom actions
11 ITSM connectors, both directions
REST Universal adapter for the rest
The OptiML CX Platform connected to CRM, service desk and telephony systems
Direction, stated On every row of the table

Does it plug into what we already run

Nobody replaces the CRM in order to buy a contact centre. The finance system stays, the service desk stays, and the carrier contract has two years left to run. So the useful question is a narrow one: which of those does the platform reach on day one, which way does the data actually move, and what is the fallback for the in-house tool nobody outside your building has heard of — and there is always one. Two figures get quoted across these pages and they count different things, so it is worth separating them here. The 100+ figure is the workflow node palette: the actions a workflow can take. The 30+ figure belongs to the knowledge base: the sources an index can follow. Neither list contains the other. Everything below is grouped by category, with the direction the data runs and a link into the module that owns the connector.

A connector that only reads is half a connector

Deployments rarely come apart over the model. They come apart three weeks in, when it emerges that the service desk integration creates tickets but never learns that one was closed, so an agent tells a customer their request is still open on the day the engineer finished it. Direction is the thing to establish before signature — per connector, in writing. That is why every row of the table on this page carries one, and why the ITSM connectors are described as two-way rather than as integrated.

Pre-built for the usual tools

The palette runs to 100+ nodes across logic, data, communication, chat, CRM, ITSM, ERP and connectors, which covers most of what a contact centre is already paying for.

Two-way where it matters

The 11 ITSM connectors sync in both directions, with field mapping you configure and status transitions honoured each way. Every row of the specification table states its direction.

A documented path for the rest

Anything with a REST API connects through the universal adapter: config-driven JSON field mapping, credentials held as secrets, and no bespoke middleware for somebody to inherit.

By the numbers

Few Facts - at a glance

  • 100+

    nodes across logic, data, communication, chat, CRM, ITSM, ERP and connectors

  • 68

    CRM nodes covering Salesforce, HubSpot, Zoho and Pipedrive

  • 30+

    knowledge-source connectors, a separate list from the node palette above

The process

How It Works

From picking a connector to replaying the one that failed

Connecting a system is four steps, and it is the last two that decide whether anybody still trusts the integration in month three.

  1. Pick the connector, or the adapter

    Most of what a contact centre runs is already in the palette: CRM, service desk, ERP, telephony, calendar, commerce. Where yours is not, the universal adapter takes any REST-based tool instead. Either way the work is configuration rather than a bespoke middleware layer somebody has to maintain after the person who wrote it has moved on.

  2. Map the fields

    Field mapping is config-driven JSON: their field names to yours, and back again. On the ticketing side that includes status transitions, so an incident moved to awaiting-customer in the service desk arrives as the same state on the conversation rather than as a comment nobody opens.

  3. Hold the credentials properly, and plan for failure

    Credentials are held as secrets rather than pasted into a workflow step. Each node carries its own retry policy with exponential backoff and its own failure route, so a provider having a bad ten minutes does not take the rest of the run down with it.

  4. Watch the run, replay what failed

    Run history records the trigger, the branch taken, the payload sent, the response, the approver and the duration, step by step. Outbound webhooks are HMAC-signed, retried and logged, and whatever still fails lands in a dead-letter queue you can open and replay, rather than in a log nobody reads until a customer rings about it.

Features

Every capability you need in one module

1. CRM

Salesforce, HubSpot, Zoho and Pipedrive, read from before the conversation and written back to after it.

The node palette carries 68 CRM nodes across Salesforce, HubSpot, Zoho and Pipedrive. That is what a workflow uses to pull an account before an agent opens their mouth, and to update the record once the conversation is done. The outbound dialer writes its own outcomes back to the same four, idempotently on the call ID, so a write retried after a dropped connection updates the row it already created instead of leaving a duplicate for somebody to reconcile on Friday afternoon.

  • 68 CRM nodes across Salesforce, HubSpot, Zoho and Pipedrive
  • Read before the conversation, write after it
  • Dialer outcomes synced back, idempotent on call ID
Salesforce HubSpot Zoho Pipedrive

The 68 nodes live in Workflow Automation

How the dialer writes an outcome back

2. Ticketing and ITSM

Eleven service desks, synced both ways, with the field mapping and the status transitions under your control.

Two-way sync with ServiceNow, Jira Service Management, Zendesk, Freshdesk, Freshservice, BMC, Linear, Salesforce Cases, HubSpot Tickets, Dynamics and Zoho Desk. You configure the field mapping. Status transitions are honoured in both directions, which is the half most integrations skip: an engineer moving an incident to awaiting-customer changes the state on the conversation the agent had, rather than adding a note to a queue nobody opens.

  • Two-way sync, not ticket creation on its own
  • Configurable field mapping between their names and yours
  • Status transitions honoured in both directions
ServiceNow Jira Service Management Zendesk Freshdesk Freshservice BMC Linear Salesforce Cases HubSpot Tickets Dynamics Zoho Desk

Ticketing & Case Management, where the mapping is configured

The same connectors on an HR and IT service desk

3. Knowledge sources

Thirty-plus places your documentation actually lives, followed where it sits rather than copied into a second home.

The knowledge base connects to 30+ sources, among them Confluence, SharePoint, GitHub, Slack, Notion and Salesforce. This is a different count from the 100+ node palette, and neither figure sits inside the other: these are sources an index follows, not actions a workflow can take. A connected source is tracked rather than duplicated, which is what stops a page somebody corrected in March from still answering with January's wording.

  • Confluence
  • SharePoint
  • GitHub
  • Slack
  • Notion
  • Salesforce

How the Knowledge Base indexes and re-syncs a source

4. Telephony and messaging

Carriers and channels, on the accounts you already hold rather than on ours.

Telephony connects over SIP ingress and egress across LiveKit, Twilio, Telnyx and Vonage. SMS runs through Twilio, Telnyx or Brevo. WhatsApp is the Business Cloud API, with template management inside the platform, interactive buttons and lists, and media and commerce flows. Email connects multiple inboxes over OAuth, IMAP or SMTP, with outbound through SendGrid, Mailgun or Brevo.

  • Telephony: LiveKit, Twilio, Telnyx and Vonage, SIP ingress and egress
  • SMS: Twilio, Telnyx, Brevo
  • WhatsApp Business Cloud API, with template management in-platform
  • Email: multiple inboxes over OAuth, IMAP or SMTP, plus SendGrid, Mailgun and Brevo

Every channel on one conversation record

5. Business systems

The systems that hold the answer: the ledger, the catalogue and the diary.

ERP nodes reach SAP S/4HANA and NetSuite. Commerce is a real-time lookup against Shopify or WooCommerce, or against your own API where the catalogue lives somewhere else, so an order status is true at the moment it is said rather than as of last night's export. Calendars connect to Google Calendar or Microsoft 365 over OAuth, and a slot that gets offered respects the duration and the buffer the diary already enforces instead of double-booking somebody at four o'clock.

  • ERP: SAP S/4HANA and NetSuite
  • Commerce: Shopify, WooCommerce, or your own API
  • Calendar: Google Calendar or Microsoft 365 over OAuth, respecting duration and buffer

The ERP and HTTP nodes in Workflow Automation

A calendar connector doing the booking end to end

6. iPaaS and no-code platforms

For the automation your operations team has already built somewhere else.

Native triggers and actions in Zapier, Make, Workato, n8n, Pabbly, Pipedream, IFTTT and Tray. Eight platforms. Whatever your operations team already maintains in them keeps running, so adopting the platform does not open with a migration project nobody costed for. Outbound webhooks are HMAC-signed, which lets the receiving side verify that a payload really came from your tenant.

Zapier Make Workato n8n Pabbly Pipedream IFTTT Tray

Triggers, nodes and signed webhooks in Workflow Automation

7. Identity and observability

Two categories that run in opposite directions: identity comes in, telemetry goes out.

Single sign-on works across 8+ identity providers with SCIM provisioning, so joiners and leavers are handled by the directory that already handles them everywhere else. Access is governed by 300+ RBAC permissions with resource-scoped grants rather than one administrator tier that sees everything. Telemetry runs the other way: OpenTelemetry traces, Prometheus metrics and PII-redacted structured logs export into your own Datadog, Honeycomb or Sentry, so the platform is not a black box with a status light on the front of it.

  • SSO across 8+ identity providers, with SCIM provisioning
  • 300+ RBAC permissions with resource-scoped grants
  • OpenTelemetry traces and Prometheus metrics exported to you
  • PII-redacted structured logs into Datadog, Honeycomb or Sentry

Deployment & Hosting, where identity and telemetry are configured

8. Build your own

The catch-all, placed here rather than in a footnote, because a fair share of readers arrive at it.

If your tool is not named above, the universal adapter connects any REST-based tool through config-driven JSON field mapping, with credentials held as secrets. Around it sits the rest of the surface — a REST API with an OpenAPI description, cursor pagination, idempotency keys and rate-limit headers, 11 client SDKs, a CLI, an MCP server SDK, HMAC-signed webhooks with delivery logs and a dead-letter queue, and a Terraform provider covering agents, flows, knowledge sources, phone numbers, integrations, users and roles. The in-house system with three users and no documentation is the normal case in this category, not the awkward exception.

  • Universal adapter for any REST-based tool, with config-driven JSON field mapping
  • REST API with OpenAPI, cursor pagination, idempotency keys and rate-limit headers
  • 11 SDKs, a CLI and an MCP server SDK
  • HMAC-signed webhooks with retries, delivery logs and a dead-letter queue
  • Terraform provider for agents, flows, knowledge sources, phone numbers, integrations, users and roles

Where the adapter and the signed webhooks are built

The API, the SDKs and the Terraform provider

Written for the engineering team that has to own it

Use Cases

Where Integrations delivers value

Two-way ITSM sync with configurable field mapping

The service desk that is not up for replacement

An IT service desk running ServiceNow (illustrative)

Scenario

Change control will not permit a second ticketing system — and the position is not open to negotiation. Cases raised from conversations are created in ServiceNow with mapped fields, and status transitions come back the other way, so the conversation record shows awaiting-customer at the moment the engineer sets it rather than the following morning.

Outcome

Nothing gets replaced. The service desk stays the system of record, and the conversation stops being the part of the trail that goes missing when somebody audits it.

Real-time commerce lookup on Shopify or WooCommerce

An order status that is true when it is said

A direct-to-consumer retailer (illustrative)

Scenario

“Where is my order” arrives on WhatsApp several thousand times a week. The answer comes from a live lookup against the store rather than from an overnight export, so the dispatch status quoted at eleven in the morning reflects the parcel that was scanned at ten.

Outcome

The follow-up call asking why the status was wrong does not happen, because the status was not wrong. The same lookup serves voice and web chat without being rebuilt for each of them.

Native triggers and actions across eight iPaaS platforms

The automation nobody wants to rebuild

An operations team already running Make (illustrative)

Scenario

Two years of scenarios sit in an iPaaS tool, glued to a finance system and a spreadsheet somebody will fix properly one day. Rather than rebuilding them here, the platform publishes native triggers and actions into it, and signs the outbound webhooks so the receiving side can verify where a payload came from.

Outcome

The rollout stops being a migration. What the operations team maintains keeps running, and new work gets built wherever it belongs rather than wherever a contract says it has to be.

At a glance

Specification

The numbers and limits, without the sales copy

Specification for Integrations
Specification Detail
CRM Salesforce, HubSpot, Zoho, Pipedrive · 68 nodes · read and write, with dialer outcomes idempotent on call ID
Ticketing and ITSM ServiceNow, Jira SM, Zendesk, Freshdesk, Freshservice, BMC, Linear, Salesforce Cases, HubSpot Tickets, Dynamics, Zoho Desk · two-way, with configurable field mapping and status transitions
Knowledge sources 30+ connectors including Confluence, SharePoint, GitHub, Slack, Notion, Salesforce · inbound to the index, followed rather than copied
Telephony LiveKit, Twilio, Telnyx, Vonage · SIP ingress and egress, both directions
SMS Twilio, Telnyx, Brevo · inbound and outbound
WhatsApp WhatsApp Business Cloud API · inbound and outbound, with template management in-platform
Email Multiple inboxes over OAuth, IMAP or SMTP inbound · SendGrid, Mailgun or Brevo outbound
ERP SAP S/4HANA, NetSuite · read and write from workflow nodes
Commerce Shopify, WooCommerce, or your own API · outbound real-time lookup
Calendar Google Calendar, Microsoft 365 over OAuth · read availability and write the booking, respecting duration and buffer
iPaaS Zapier, Make, Workato, n8n, Pabbly, Pipedream, IFTTT, Tray · native triggers and actions, both directions
Identity SSO across 8+ identity providers with SCIM provisioning · inbound, with 300+ RBAC permissions and resource-scoped grants
Observability OpenTelemetry traces, Prometheus metrics, PII-redacted logs · outbound into your Datadog, Honeycomb or Sentry
Anything else Universal adapter for any REST-based tool · config-driven JSON field mapping, credentials held as secrets, direction set by the mapping
Configuration as code Terraform provider (agents, flows, knowledge sources, phone numbers, integrations, users, roles), REST API with OpenAPI, cursor pagination, idempotency keys, rate-limit headers, 11 SDKs, CLI, MCP server SDK
Delivery and failure HMAC-signed webhooks with retries and delivery logs, per-node retry with exponential backoff and a failure route, dead-letter queue with replay
FAQ

Questions,
answered

What people ask before they commit: which way each connector runs, where the credentials sit, and what happens when the tool they run is not on the list.

Still not sure?

Talk to a specialist and get a straight answer.

Ask our team

The universal adapter takes it, provided it has a REST API. Field mapping is config-driven JSON rather than code, and credentials are held as secrets rather than pasted into a workflow step. Around that sit a REST API with an OpenAPI description, 11 client SDKs, a CLI, an MCP server SDK and HMAC-signed webhooks, which between them cover most in-house systems. Send us the API documentation and we will tell you which of them it needs.

It depends on the connector, which is why the specification table above states a direction on every row instead of using the word integrated and leaving it there. The 11 ITSM connectors are two-way, with field mapping you configure and status transitions honoured in both directions. CRM is read and write. Commerce is an outbound lookup on demand. Observability runs outward only, into your own Datadog, Honeycomb or Sentry. Ask per connector before signature and you will get an answer per connector.

As secrets held by the platform and referenced by the node that needs them, rather than embedded in a workflow step where anyone who can open the workflow can read them. Who can reach them follows the same access model as everything else: single sign-on across 8+ identity providers with SCIM provisioning, and 300+ RBAC permissions with resource-scoped grants rather than one administrator tier that sees the lot.

It is retried. Outbound webhooks are HMAC-signed and carry delivery logs, and whatever still fails after the retries lands in a dead-letter queue you can open and replay. The same idea applies inside a workflow, per node: each one carries a retry policy with exponential backoff and a failure route, so one provider having a bad ten minutes does not take the whole run with it. Run history records the trigger, the branch taken, the payload, the response, the approver and the duration step by step, which turns which system swallowed it from an argument into a question with an answer.

Yes. The Terraform provider covers agents, flows, knowledge sources, phone numbers, integrations, users and roles, so adding a connector is a merge request your own people review rather than a support ticket somebody at RMT picks up when they get to it. The REST API ships an OpenAPI description with cursor pagination, idempotency keys and rate-limit headers, and there are 11 client SDKs, a CLI and an MCP server SDK around it.

No. The dialer writes its outcome back to Salesforce, HubSpot, Zoho or Pipedrive idempotently on the call ID, so a write retried after a dropped connection updates the row it already created rather than making a second one. The REST API accepts idempotency keys for the same reason. It is worth testing during a pilot, because the failure mode only shows itself once something has gone wrong on the network, and by then the duplicates are already in the CRM.

Keep exploring

Additional supporting modules

Native modules that share the same record, knowledge and governance

Platform module

Workflow Automation

The 100+ node palette, the 50+ triggers and the signed webhooks. Most connectors on this page are reached from here.

Explore
Platform module

Ticketing & Case Management

The 11 ITSM connectors, the field mapping and the status transitions that make the sync run both ways.

Explore
Platform module

Knowledge Base & RAG

The 30+ knowledge-source connectors, and what happens to a document once it has been indexed.

Explore
Platform module

Deployment & Hosting

Identity, telemetry and configuration as code: SSO with SCIM, exported traces and the Terraform provider.

Explore
Talk to a specialist

Bring the list of systems this has to touch

Send the list before the call: the CRM, the service desk, the carrier, the finance system, and the one nobody enjoys talking about. We will mark each one pre-built, adapter, or genuinely not possible, and state the direction it runs. The third column is usually short. It is never empty, and it is a good deal cheaper to find in week zero than in week three.

  • 30 minutes
  • Your system list, marked up
  • No slide deck unless you want one

Book your slot

Leave your email and our team will come back to you within one business day.

or reach us directly
Call our team Email us

Your details stay private. We never share them.

This website uses cookies.

Cookies are small text files that allow us to create the best browsing experience for you on our site. By continuing to use this website or clicking "Accept & Close", you are agreeing to our use of cookies. To understand how we use cookies or how to manage them, please see our cookies policy.

Ask OptiML

Powered by RMT Engineering