An AI system connected to CRM or ERP should have explicitly permitted actions, independently enforced user scope and a clear approval boundary. Distinguish reading information, proposing a change and committing a transaction. A model understanding a request does not establish authority to update customer records, approve spending or send information outside the organisation.
Let’s plan your AI business integrations.
Bring your requirements and the decisions you need to make. We’ll help you clarify the scope, explore the trade-offs and plan the next step.
Start with a business action inventory
List actions in operational language: find an order, draft a follow-up, propose a customer merge or create a purchase request. Record the requesting user, affected records, possible consequences and recovery route.
Avoid granting a general database connection when a narrow business function is sufficient. The integration should validate required fields and permissions at execution, rather than trusting generated text or the fact that a user opened the chat interface.
Use an action and approval matrix
| Capability | Suggested first boundary | Evidence to request |
|---|---|---|
| Find an order | Read permitted records only | Cross-account refusal |
| Summarise an account | Restricted sources and output audience | Source and disclosure review |
| Draft a follow-up | Proposal pending human acceptance | Editable draft and recipient check |
| Amend a customer field | Validated action under assigned authority | Before/after values and approval |
| Create a business request | Existing business workflow | Stable reference and acknowledgement |
| Approve a consequential transaction | Separately authorised process | Enforced approval and attributable result |
The matrix is a scoping aid. Your organisation must decide the actual authority and consequences for each action.
Test the gap between proposal and execution
Suppose the assistant proposes updating a delivery address. Between proposal and approval, the order is dispatched. The execution step should recheck the current transaction and permitted change, not assume an earlier suggestion remains valid.
Give the user a reviewable proposed change with the affected record and relevant values. Define what happens if approval is withdrawn, times out or applies to a different version of the request.
This hypothetical example illustrates a stale-state problem. It is not evidence that any specific model or connector handles it correctly.
Make retries and interruptions accountable
Assign a stable action identifier and retain the external acknowledgement. A timeout after a successful write should not cause a second transaction on retry. Define pending and failed states that the responsible person can understand.
Set tool-call, elapsed-time and spend limits appropriate to the task. At a limit, stop or escalate according to an agreed rule. Repeated failure should not grant broader permissions or switch to an unrestricted tool.
Treat retrieved records as data
Emails, notes and attachments may contain instructions that attempt to redirect the model. They do not grant authority to change the workflow or disclose another record. Test malicious and accidental instruction-like content against the same access boundary.
OWASP's authorization guidance supports independently checking permissions and limiting access. Applying a prompt template alone is not evidence that those controls exist.
Questions buyers ask
Should the assistant use an administrator account?
Define a scoped service identity and user-context checks appropriate to the architecture. Broad access should not be the default solution to integration friction.
Is human approval enough?
Approval is one control. The proposed action must also be understandable, current, authorised and correctly executed.
Prepare the integration workshop
Bring an action list, business roles and interrupted-transaction examples. Pair the CRM–ERP integration guide with the agent decision framework before scoping AI development.