Connecting AI to your ERP, CRM and data warehouse

Most useful AI work in a business needs data that lives in a handful of systems: orders and invoices in the ERP, accounts and pipeline in the CRM, history in the data warehouse. The model is the easy part. The hard part is connecting it so it sees the right records, changes only what it should, and leaves a trail your finance and IT leads can check.

What does connecting AI to an ERP or CRM actually involve?

Three layers sit between a model and your business data. The system of record is the application that owns the truth for a type of data, such as NetSuite for invoices or Salesforce for accounts. The integration layer moves data in and out of it. The AI workflow reads that data, reasons about it and proposes or takes an action.

Most integration problems come from the middle layer, not the model. Decisions about how data moves, under whose identity, and with what approval decide whether the project is safe to run.

Which integration pattern should you use?

There is no single right answer. Most production workflows combine two or three of these patterns.

An iPaaS (integration platform as a service) is hosted software for building and running connections between applications without writing every one from scratch. An event stream is a continuous feed of changes. Salesforce's version, Change Data Capture, publishes events for record create, update, delete and undelete operations.

Why direct database access is usually the wrong answer

Writing to an ERP's tables skips the validation, workflow rules and audit logic the application runs on every change. A record can look correct in the database and still break a posting, a tax calculation or a downstream sync. Reading directly is less dangerous but still bypasses field-level security and can put analytical load on a transactional system. For SaaS products such as NetSuite, Dynamics 365 and HubSpot, the vendor-supported route is the API anyway.

Read access, write access and approval before writes

Treat reading and writing as separate permissions with separate risk. A sensible progression looks like this:

1. Read only. The AI retrieves records and answers questions or prepares summaries. Nothing changes in the system of record.
2. Draft or staging. The AI prepares a change, such as a sales order or a contact update, in a holding area your team reviews.
3. Write with approval. A named person approves each change, with the source evidence in front of them, before the integration commits it.
4. Write without approval for low-risk actions. Only after the workflow has run with approval long enough to show a low error rate, and only for changes that are easy to reverse.

Consequential writes (credit limits, prices, payment terms, financial postings) should stay at step 3 indefinitely. The approval step also gives you evidence: every accepted or rejected proposal shows how well the workflow performs, which is the basis for testing AI before it touches your operations.

How should identity and permissions work?

Give each integration its own service account, a non-human identity used only by that integration, rather than borrowing an employee's login. Grant it the minimum objects and fields it needs, which is the principle of least privilege. If the workflow only reads invoices and writes draft sales orders, it should not be able to edit the customer master.

Keep credentials out of code and configuration files. AWS Secrets Manager and Azure Key Vault both exist to store secrets such as API keys and connection strings, and Secrets Manager can rotate credentials on a schedule.

Two further points catch teams out. First, service accounts can share limits: in Microsoft Power Platform, application users and other non-interactive users draw on a pooled tenant-level request allocation rather than getting their own. Second, a service account sees everything it is allowed to see, regardless of who asked the question. If employees with different access levels will use the same assistant, the workflow must filter results by the requesting user's permissions. Our guide to data security and governance for AI covers this in more depth.

Why data quality and master data decide the outcome

Master data is the shared reference data other records depend on: customers, products, suppliers, price lists, units of measure. When it is inconsistent, AI workflows fail in ways that look like model errors but are not.

Common problems to look for before scoping a build:

• The same customer under different IDs in the CRM and the ERP, with no reliable mapping between them.
• Product codes that changed over time, so historical orders reference items that no longer exist.
• Free-text fields used for information that should be structured, such as delivery instructions holding credit terms.
• Units of measure that differ between systems (cases in one, units in another).
• Warehouse tables that lag the source by a day without anyone saying so.

A model given two conflicting customer records will pick one confidently. Sampling a few hundred real records early is cheaper than discovering these issues in testing.

What this looks like in common systems

Each platform has its own integration surface and its own limits. The figures below come from vendor documentation as published in September 2026; confirm them for your edition and contract.

• NetSuite. Integrations typically use SuiteTalk REST web services or RESTlets. Oracle governs these with an account-level concurrency limit that applies to web services and RESTlet requests combined and depends on your service tier and SuiteCloud Plus licenses. You can allocate part of that limit to specific integrations under Integration Governance.
• SAP. SAP lists its APIs, prepackaged integrations and business services on the SAP Business Accelerator Hub. Start there to confirm whether a released API covers the objects you need before considering anything custom.
• Dynamics 365. Customer engagement apps such as Dynamics 365 Sales run on Microsoft Dataverse. Dataverse applies service protection limits per user, per web server: by default 6,000 requests within a five-minute sliding window, returning a 429 error with a Retry-After value when exceeded. Daily Power Platform request allocations apply on top.
• Salesforce. Enterprise Edition orgs get 100,000 API calls per 24 hours plus an allocation per license (1,000 per Salesforce license), enforced against all API calls to the org, not per user. Professional Edition needs API access enabled.
• HubSpot. Private apps on Professional and Enterprise tiers can make 190 requests per 10 seconds per app. The daily limit (625,000 on Professional, 1,000,000 on Enterprise) is shared across every app in the account.
• Snowflake, BigQuery and Microsoft Fabric. Warehouses suit read-heavy AI work because queries do not load the transactional system. Google describes BigQuery as a fully managed data platform; Fabric stores data in OneLake and can mirror data from sources including Snowflake and Azure SQL Database.

A background job that syncs 200,000 CRM records nightly and an assistant making live lookups for 50 users will compete for the same allocation. Size the design against the limits, not the other way round.

Illustrative example: Consider a regional FMCG distributor that receives purchase orders from retailers as email attachments. An AI workflow extracts the order lines, matches retailer item codes to the NetSuite item master using a mapping table held in the warehouse, and checks prices against the agreed price list. It creates a draft sales order and flags lines where the code, price or unit of measure does not match. A customer service coordinator reviews the draft, and orders above the customer's credit threshold also go to the credit controller. Only approved orders are written to NetSuite through its API, and every step is logged against the order number.

How do you keep an audit trail?

When someone asks why a record changed, you should be able to answer in minutes. For every AI-assisted action, log:

• The source records and documents the workflow read, by ID.
• The model and prompt version used.
• The proposed change, field by field.
• Who approved or rejected it, and when.
• The API call made and the response the system returned.

Store these logs in an account your organization controls, apply the same access rules as the underlying data, and set a retention period that matches your records policy. Log the integration's identity in the system of record too, so native audit history shows clearly which changes came from automation.

What to check before you commit to an integration

Run these checks before agreeing scope, timeline or budget:

1. Confirm a supported API covers every object and field the workflow needs, for both read and write.
2. Estimate call volumes and compare them to rate limits and daily allocations, including other integrations already running.
3. Check whether API access, an integration user or extra capacity requires a higher edition or add-on license.
4. Identify who can grant the service account its permissions, and how long approval takes.
5. Sample real records for duplicates, missing values and mismatched IDs across systems.
6. Confirm a sandbox or test environment exists with realistic data.
7. Review the vendor's terms on third-party access and on sending data to AI services.
8. Note blackout periods such as month-end close, when integration changes should not go live.

Any of these can change the design. Finding them in week one is cheap; finding them after the build is not.

How Kastling approaches ERP and CRM integration

We start by understanding the work before choosing the technology, and we connect existing systems rather than replacing them. For AI and operations projects, a separately scoped paid audit usually reviews the systems, APIs, permissions and data quality described above before we propose a design. Data access and ownership are agreed up front, and a named person on your side stays in control of consequential writes.

Builds are tested against real business scenarios in a non-production environment first. This work sits within our AI & Cloud Infrastructure service; if you are deciding where the AI layer should run, see model-agnostic AI architecture.