Connecting AI agents to CRM, ERP and APIs

01

Put a business service between the model and the system

A connector or MCP server describes available tools and how to call them. It does not replace authorisation or make a broad administrative operation appropriate for a customer-facing agent. Prefer capabilities such as “retrieve the current user's open service cases” over generic “run a query” access.

OWASP's REST security guidance supports access control at protected endpoints and validation of inputs. Enforce those checks even when a well-behaved agent normally produces valid requests.

Prefer supported APIs that retain system validation and audit behaviour. Where no suitable interface exists, investigate a controlled adapter or a human-assisted step. Do not quietly turn a missing API into permission to bypass the application's rules.

02

Write a contract for each tool

Distinguish “not found” from “not authorised” internally without leaking protected record existence to the user. Let the application map technical errors into an appropriate customer response.

Test tool descriptions with realistic requests. If two capabilities have similar names but different business consequences, make the difference explicit. The model should not need to guess whether an operation saves a draft or commits it.

03

Resolve identity and authoritative data before execution

Decide whether the integration acts on behalf of a signed-in person or through a dedicated workload identity. Resolve the user and tenant outside the prompt. A customer-provided account number is a lookup input, not proof that the customer may use that account.

OAuth-based integrations should follow current security practice, including limiting token privilege and intended recipients. RFC 9700 is the IETF's OAuth 2.0 security best-current-practice reference. The appropriate flow depends on the client and provider, so use the provider's supported implementation and test revocation.

For each field the agent needs, identify its authoritative source and freshness requirement. Do not let a copy in a CRM, an old document and an ERP record silently compete. Include the source and relevant timestamp in the tool result where that affects the answer.

04

Separate proposal, approval and execution

A write should have an explicit proposed payload, validation result and required authority. If a reviewer approves a change, bind that approval to the specific record, values and action. Revalidate the record state immediately before execution.

Plan for a request that succeeds but loses its response. Retrying blindly can create a second case, booking or order. Use the downstream API's idempotency capability where supported. Otherwise define an application-level operation identity, reconciliation and duplicate-prevention design with the system owner.

• Give each consequential operation a durable reference.
• Record pending, accepted, rejected and unknown outcomes separately.
• Check the authoritative system before retrying an uncertain write.
• Route unresolved outcomes to a person who can reconcile them.
• Do not describe a queued operation as completed.

For multi-system changes, define which partial states are acceptable and what repair means. Reversing a CRM update does not necessarily undo a message already sent or a physical dispatch already started.

05

Keep long-running work outside the conversation request

Some operations need a durable job rather than an open chat request. Return a reference, store progress and update the user through an allowed channel when a result is available. Make the job's state available to both the agent and support staff.

For event-driven integration, validate the event source using the provider's documented mechanism, account for duplicate delivery and decide how out-of-order updates are handled. An old status event must not silently overwrite a newer business state.

Maintain a mapping between conversation, task, operation and downstream record references. That lets a support person answer “What happened to this request?” without searching through unrelated transcripts.

06

A hypothetical CRM-to-ERP service request

A customer asks whether replacement equipment can be supplied. The agent retrieves the authorised customer context, asks for missing requirements and prepares a service request. An ERP lookup provides stock information; an operations person decides whether to reserve it.

The agent may create a CRM case and report its reference. It must not describe stock as reserved merely because the lookup found an available item. Reservation is a separate operation with its own authority and confirmed result.

If case creation succeeds but the ERP is unavailable, keep the case open with a clear pending dependency. Use the handover process to transfer that unresolved task, rather than rolling back the entire conversation or inventing availability.

07

Validate the integration as a business workflow

1. Test normal requests against a controlled non-production dataset.
2. Try a valid record belonging to another customer or tenant.
3. Revoke permission between lookup and execution.
4. Repeat the same operation after a timeout or worker restart.
5. Change the record while an approval is pending.
6. Simulate rate limits, stale data and partial downstream failure.
7. Check customer wording against the authoritative final state.
8. Prove that staff can investigate and resolve an unknown outcome.

Start with one bounded integration and expand after it behaves reliably. The duplicate-data-entry guide covers the wider data contract, while WhatsApp AI capabilities explains the customer-facing channel.

Questions

Frequently asked questions