AI integration that fits the systems you already run
We connect models to Salesforce, ERPs, helpdesks, data warehouses, WordPress and legacy databases, choosing the pattern that matches how the work actually flows.
The hard part of AI integration is rarely the model call. It is deciding who waits, what happens on failure and who is allowed to trigger an action. Those three questions pick the pattern.
The same model, three places in the system. A: the user waits. B: a queue absorbs volume and failure. C: the model initiates, so the server's scopes are the safety boundary.
Who this is for
Teams whose AI pilot works in isolation and now has to live inside the systems the business runs on: the CRM, the finance system, the helpdesk, the warehouse. IT leaders who need a vendor that respects change control and will not bolt a model onto a production database over a weekend. And product teams adding AI to a platform that other systems already depend on. If the integration fails, the AI fails with it, so we treat the seam as the product.
The systems involved have owners who can grant scoped access and review data flows
Someone can say which actions must never be automated
There is a non-production environment to prove the seam before it touches live data
Targets
Systems we integrate most, and how
System
Usual pattern
Auth
Main risk
Our approach
Salesforce
Event-driven (Platform Events, Flow) plus tool access for assistants
Connected app, OAuth, per-user permissions
Governor limits and over-broad permission sets
Apex and LWC where logic belongs in the org; external workers for heavy model calls. See Salesforce integrations.
ERP and finance
Event-driven, batch windows
Service account, IP allowlist
Writing wrong values into the system of record
Read freely, write through validated staging with human approval on exceptions
Helpdesk and ticketing
Synchronous for assist, event-driven for triage
API key or OAuth app
Noisy automation annoying agents
Suggest first, act later; everything the AI adds is labelled
Data warehouse
Event-driven and scheduled
Read-only role
Sending whole tables to a model
Aggregate and sample before the call; embeddings built in-pipeline with AI data engineering
Legacy database, no API
Tool access through a generated API or read replica
Dedicated DB role
Locking or loading production
Replica or DreamFactory-generated REST layer; writes only via existing procedures
WordPress and CMS
Synchronous for editors, event-driven for publishing
Application passwords, REST
Unreviewed AI content going live
Draft status by default, editorial approval, structured data preserved
What we deliver
Integration delivered as a product
Connectors with contracts
Typed interfaces, versioned schemas, retries, idempotency keys and dead-letter handling. Written in Node.js, Python or PHP/Laravel to match your stack, by the same team behind our mobile, web and API services.
Data flow sign-off
A diagram of exactly which fields leave which system, where they are redacted, and which provider sees them. Reviewed with security before go-live.
Observability across the seam
A trace that follows a record from the source event through the model call to the write-back, with cost per record and failure alerts. See LLMOps monitoring.
Map the flow
Who triggers, who waits, what is written back, what must never happen. Pattern chosen.
Prove the seam
A thin path through the seam in a sandbox: one record in, one result out, traced.
Shadow writes first, then live for a cohort, then all. Rollback is a single switch.
What goes wrong
Example: a nightly job sends every new support ticket, including attachments, to a model and writes the category back. One night the provider has an outage; the job retries without idempotency, duplicates 4,000 categorisations and overwrites manual work. An event-driven design with idempotency keys and a dead-letter queue would have lost nothing. We treat that as the baseline.
Synchronous when a user is waiting for the answer. Event-driven when work can happen in the background and must be reliable at volume. Tool access through MCP when an assistant or agent needs to decide for itself when to read or act. Most real systems use two of the three.
Can you integrate AI with our legacy system that has no API?
Usually. Options include a database-level read replica, a thin API generated with DreamFactory, file or report exports on a schedule, or a modernisation step for the parts the AI needs. We pick the least invasive path that is still safe; see legacy modernisation.
How do you keep customer data out of the model provider?
By design: minimise what is sent, redact identifiers before the call, use provider terms that exclude training on your data, and run open-weight models in your own environment where residency rules demand it. Our AI data privacy practice signs off the data flows.
How long does an integration take?
A single system with a decent API typically takes three to six weeks including testing and monitoring. Event-driven pipelines across several systems, or anything touching an ERP, run eight to twelve weeks. The system's API and your change-control process set the pace more than the AI does.
Do you work with Salesforce?
Yes. Our team builds on Apex, Lightning Web Components, Flow and Agentforce, and integrates Salesforce with external models and systems. See Salesforce integrations.
Talk to us about your AI project
Tell us what you are trying to do, which systems are involved and what is in the way. We reply within one business day with an opinion and a suggested next step.