Connect CRM, HRM and ERP around one accountable handoff
A won opportunity is not yet an authorized project, a staffed delivery plan or an invoice. This guide follows that handoff through a fictional service business, showing what to connect, where AI can help and which decisions should remain explicit.
Published guide · Illustrative implementation
1. Choose one handoff and its outcome
Imagine DemoCompany Services has won a maintenance contract. Sales needs an operations manager to review the scope and a finance owner to authorize project setup. Start with a narrow output: a proposed ERP project linked to the accepted commercial record and an eligible project owner. Sending an invoice, changing pay or assigning people to shifts remains outside this first workflow.
CRM supports customer relationships and sales activity. HRM is the management of people; HRIS names software supporting employee records and administration. ERP connects transactional processes such as finance, procurement and operations. These categories overlap, and a product may cover several. Map actual responsibilities before choosing connectors. The example below illustrates decisions to agree with owners, not a universal allocation of fields.
2. Name the authoritative fields and identifiers
For this example, CRM customer C-104 maps to ERP customer E-208 through an approved cross-reference. Neither a matching company name nor an email address is sufficient to create that link automatically. A renamed customer must retain its identity; two similarly named customers must remain distinct. Ambiguous matches go to a person who can inspect the original records.
Record field definitions, accepted values, direction of updates and conflict ownership. A sales note cannot silently replace a finance-approved billing address. Keep source identifiers, record versions and retrieval times alongside the proposal. If ownership changes, review the mapping before resuming writes. The practical deliverable is a small, inspectable mapping register, not a promise that every database becomes one source of truth.
| Record | Example authority | Permitted use |
|---|---|---|
| Customer and accepted scope | CRM and approved contract | Link the customer; draft delivery requirements. |
| Billing details and project code | ERP / finance owner | Read approved values; request project creation. |
| Employee status and manager | HRIS / HR owner | Confirm permitted eligibility fields only. |
| C-104 ↔ E-208 | Reviewed mapping register | Connect stable IDs without copying unrelated records. |
3. Build a small read path before writes
Let the reviewer see a case assembled from permitted records first. The connection needs supported API access, a test environment or approved sample, and an owner for each integration. Confirm pagination, update timing, limits and available change notifications. A successful connection test does not prove that every required record is present or current.
Keep employee salary, medical information and unrelated personnel documents outside this project-setup case. Authorization must be enforced by the application and source systems for the current user and action. Search indexes, cached excerpts and exported notes need the same boundaries. Show unavailable data as unavailable; do not disclose restricted contents to explain why access failed.
4. Separate interpretation, approval and execution
AI might extract draft deliverables from an approved scope and explain which source supports each one. Exact checks should validate customer IDs, required fields and allowed project types. Document content is evidence, not an instruction to grant permissions. Anthropic’s workflow/agent distinction is useful here: a predictable approval path need not become an autonomous planning loop.
Show the reviewer the proposed destination, changed fields, supporting records and unresolved questions. Bind approval to that proposal and its relevant source versions. Recheck them before execution: a changed contract or billing destination sends the case back for review. Permit only the approved write. Approval to create a project does not authorize an invoice, a staffing decision or an external message.
5. Design recovery before enabling execution
A timeout is not proof that a write failed. The ERP may have created the project before its response was lost. Microsoft’s Retry guidance distinguishes transient failures from persistent faults and asks designers to consider repeated side effects. Use bounded retries for suitable temporary failures; a permission error or invalid mapping needs correction, not an endless loop.
Give each logical action a stable key and retain its outcome. Use the destination’s duplicate-prevention support where available; otherwise reconcile using a supported operation reference before retrying an uncertain write. Do not claim exactly-once delivery merely because a key exists. If project creation succeeds but the CRM link fails, record partial completion and repair that link without creating another project. Assign an owner to unresolved cases.
6. Test decisions and failures, not just connectivity
Agree expected outcomes with sales, HR, finance and operations before building. Use authorized examples and separate development cases from evaluation cases. Measure incorrect mappings, duplicate writes, missing evidence, reviewer effort and recovery time. Set acceptance limits from the actual consequences and baseline; this fictional example provides no savings or accuracy result.
- Valid customer link and approved scope: the reviewer can inspect every proposed field and its source.
- Ambiguous customer or missing required field: no project is created; the case names the unresolved input.
- Restricted employee record: no protected content appears in retrieval, the answer or logs.
- Source changed after approval: execution stops and the revised proposal requires review.
- Timeout, repeated event or partial completion: the same business action is reconciled without an additional project.
- English and Arabic documents: names, identifiers, dates and cited passages retain their meaning; uncertain extraction is flagged.
- Lost connection or disabled integration: the team can use the agreed manual process and reconcile pending work later.
7. Agree what implementation hands over
A bounded engagement should deliver the workflow and mapping register, access design, connector scope, evaluation cases, approval rules and recovery procedure. Specify hosting, data retention, monitoring, licensing and support responsibilities before rollout. Confirm platform entitlements and supported interfaces; this guide does not assert a ready-made GTC connector for every product.
Start with a small approved scope and inspect real exceptions before expanding. Keep operational ownership after launch: someone must review mapping changes, failed cases, access changes and regression results. Company AI Brain is our term for connected evidence and controlled workflows around such decisions. It supplements the agreed systems of record; it does not replace their authority.