External Systems
The systems your operation already runs on, connected as actions inside a workflow: read a record, write an outcome, trigger a follow-up. No separate pipeline, and no sync step before an agent can use them.
Book a demo200+ native integrations
Pre-built connections to the CRMs, ERPs, ticketing platforms, databases and communication tools enterprise operations run on. Each is exposed to a workflow as a specific action rather than a general-purpose connection.
- CRM and salesSalesforce, HubSpot and others: read contacts, log outcomes, update deal stages.
- ERP and operationsLive inventory, order status and fulfillment data, pulled mid-conversation.
- Ticketing and supportServiceNow, Zendesk and others: read tickets, create cases, escalate to queues.
- DatabasesMongoDB, Redis and other layers, for pricing engines and internal reference data.
- CommunicationTeams, Slack and email, for handoffs and notifications where your team already works.
- Maps and logisticsGoogle Maps and domain-specific APIs, for routing, location and carrier lookups.
Scoped access
An integration reaches a workflow as a named action, like read this record or write this outcome, so an agent only ever touches what the step requires. Credentials are configured per deployment and never shared across tenants.
Read contact record
Scheduled sync
Polling tables keep Context synchronized with external APIs on a schedule you set, with cursor and offset pagination for large datasets and managed credentials applied automatically, so enterprise data stays live rather than copied once.
Every 15 min
Next 14:15
Cursor
500 per page
Managed
This deployment
Pre-loaded and live data
External systems can push a record in before a session starts, so the agent opens already knowing. What isn't known until the conversation is underway, like a reference number or a live shipment status, is looked up at the step that needs it.
Contract
CV-40219
Plan
Cover Plus
Warranty
Active
Appliance
Combi, 2019
Last visit
18 Jun
City
Chicago
When can an engineer come?
Engineer slots, ServiceNow
Looking upThursday, 14:00 to 16:00Knowledge bases
Documents, policy references and SOPs are ingested and retrieved semantically against what's happening in the live interaction, not through hardcoded lookups. An update propagates to every agent using it without touching a workflow.
The display says E12 and the heating is off.
Top up to 1.2 bar. If E12 returns twice, book an engineer.
FAQs
We can do either, depending on the pattern. Polling tables keep a synchronized copy in Context on a schedule, which is what makes enterprise records queryable alongside the data your agents produce. Anything that has to be current at the moment of the conversation (a live shipment status, an inventory count) is read directly from the source system at the step that needs it.
Both, and it's configured action by action. An integration is exposed to a workflow as a specific scoped action, so one workflow might only read a contact record while another logs an outcome or updates a deal stage. Write access exists where a step explicitly requires it rather than being granted at the connection level.
Configured per deployment, applied automatically to the integrations that need them, and never shared across tenants. A workflow references the action, not the secret, so credentials aren't embedded in prompts or workflow logic and can be rotated without touching the workflows that depend on them.
The step handles it rather than the conversation hanging. Retry counts and intervals are set on the node, and a fallback path defines what happens after the final attempt: continuing on a default, logging the failure, or routing to a person. The agent keeps the conversation coherent while the workflow deals with the failure.
If it has an HTTP endpoint, a webhook node connects it, and that configuration becomes a reusable component any other workflow can import. If it has no API at all, then a browser agent operates it the way a person would, navigating, extracting and writing back.
