Your ERP does not have to be your CRM: integrate, complement, or replace?

In 60 seconds: If the ERP reliably records customers, orders, inventory, invoices, collections, and accounting, keep it as the transactional system. When sales lacks a pipeline, owner, or next step, assess three paths: configure existing features, add a CRM, or build a lightweight layer for automation, agents, and integrations. Assign one owner to each type of data and use a shared customer identity. Start with reads, links to source records, and an error queue. Allow writes only after testing permissions, deduplication, audit logs, retries, and recovery. Replace the ERP only when an assessment finds transactional gaps that configuration and integration cannot solve.

A company can invoice, control inventory, and record collections in its ERP while still losing opportunities because nobody knows the next step. That situation points to a sales follow-up problem. On its own, it does not show that the ERP is the wrong system.

The distinction narrows the decision. SAP defines ERP as software for core processes such as finance, procurement, manufacturing, and supply chain, along with other business areas. A CRM concentrates prospects, opportunities, and interactions. Dynamics 365 Sales documentation, for example, describes opportunity stages and activities such as calls, emails, meetings, and tasks. Products overlap, but their responsibilities are not identical.

Which system keeps each type of data

Assign one source of truth to each data type before choosing a tool. A common distribution looks like this:

Data	System that keeps it	What the other layer may copy or query
Billable customer, terms, and credit limit	ERP	Identifier, display name, and the status needed for selling
Product, approved price, and inventory	ERP	Availability view and catalog reference
Order, invoice, payment, and balance	ERP	Summary status and a link to the original document
Lead, opportunity, stage, and probability	CRM or sales layer	ERP customer reference when one exists
Owner, next step, and follow-up date	CRM or sales layer	Outcome returned to the commercial history
Calls, meetings, messages, and sales notes	CRM or sales layer	References that operations needs to consult

The integration layer may keep identifiers, synchronization checkpoints, and an event queue. It should not become a third complete customer profile. If a billing address changes, the process must say where to correct it and how to propagate it. Letting people edit it freely in two systems creates conflicts that are hard to audit.

Signs that the gap is follow-up, not another ERP

Review a manageable sample of recent opportunities. The gap is usually in sales follow-up when orders and invoices are reliable, but several of these symptoms appear:

• opportunities live in spreadsheets or personal chats;
• the team has no shared pipeline or stage definition;
• an active opportunity has no owner, next action, or due date;
• sales learns too late about an overdue invoice or inventory constraint;
• the latest contact is unavailable to the rest of the team;
• management builds the forecast by asking each seller.

Some transactional symptoms do justify an ERP assessment: inconsistent balances, inventory without traceability, recurring corrections during close, inadequate access controls, or required processes the system cannot support. Document those separately. Combining them with a missing pipeline leads to a migration with both problems still unresolved.

Decision matrix

Option	Good fit when	Advantage	Cost or limit to validate
Configure the ERP	It already has sufficient opportunities, activities, ownership, and alerts	Fewer systems and less synchronization	The sales experience may be limited; check module, license, and version
Add a CRM	Several sellers follow a stable process that needs reporting and channel history	Established commercial model, history, and ecosystem	Implementation, adoption, licenses, shared identity, and synchronization
Build a lightweight automation and agent layer	The bottleneck is narrow and existing tools do not cover it well	Small scope and an experience tailored to the workflow	The company owns maintenance, monitoring, security, and recovery
Replace the ERP	Important transactional capabilities fail and an assessment shows that configuration or integration is insufficient	May correct an unsuitable operational foundation	The largest change, data migration effort, and operational risk

No row wins for every company. Ask for a demonstration using real data and exceptions. For any specific ERP, validate its API, webhooks or exports, permissions, limits, version, license, and vendor support. A documented integration for one product does not prove that another edition or installation has the same capabilities.

As a bounded example, Microsoft documents that Business Central can connect with Dataverse and Dynamics 365 Sales through synchronization, virtual tables, webhooks, and other mechanisms. Its integration overview also separates query and synchronization scenarios. That is evidence about those products and configurations, not a promise that applies to every ERP.

A flow that avoids another silo

Suppose an opportunity needs follow-up while the ERP keeps availability, the order, and the invoice:

1. The integration reads authorized changes from the ERP and the sales record.
2. It resolves identity through a stable ERP ID and an explicit cross-reference table. Email, phone number, or name can identify candidates, but they do not replace that link.
3. A rule identifies opportunities without a next action, blocked orders, or invoices that change the commercial context.
4. The layer creates an alert or task with an owner, due date, reason, and links to the source records.
5. The seller works from the CRM, Teams, or another interface and records the outcome.
6. The integration returns each result to the appropriate system: activity and next step to the sales record; an approved order, confirmed payment, or accounting data to the ERP through its authorized process.
7. A technical history stores correlation ID, version, source, destination, actor, timestamp, and result. Failures enter a visible queue with an owner.

For identity and duplicates, decide what happens while a prospect is not yet a billable customer. It may live only in the CRM until it reaches an agreed condition. When creating it in the ERP, save the returned ID and prevent repeated creation with an idempotency key. Dataverse duplicate detection rules illustrate both matching criteria and their limits. A probable match should be reviewed before sensitive histories are merged.

Permissions, traceability, and recovery

Separate read and write permissions. The service that prepares alerts may need to see an opportunity, balance, and inventory while having no permission to change prices, post payments, or alter credit limits. Apply the scope by role, company, record, and field that each system supports. Dataverse, for example, uses roles, privileges, and access levels; assess every platform against its own security model.

Record who read or changed what, including before and after values when appropriate. Dataverse auditing covers data changes and user access, but administrators must enable it, set retention, and control who can inspect the logs.

Design recovery before enabling writes:

• assign a unique ID to every event and reject duplicates;
• retry only transient failures, with a limit and increasing delay;
• send permanent failures to a queue with enough context to correct them;
• keep a checkpoint so processing can resume without repeating actions;
• reconcile source and destination states on a schedule;
• document how to pause the automation and continue manually.

Azure’s guidance on the Retry pattern warns that retrying a non-idempotent operation can execute the same effect twice. A failure after order creation must therefore not create another order when processing resumes.

Pilot: reads first, narrow writes later

Run the read-only pilot for enough cycles to observe normal work and exceptions, using one segment, one owner, and one alert type. Show the source, update time, and reason for every case. Measure coverage, duplicates, false positives, time to next action, and exceptions without an owner. Compare the results with a baseline collected before the pilot.

Before writing, test unmatched accounts, duplicate customers, time zones, concurrent changes, stale data, API limits, and partial outages. The first write should be reversible and low impact, such as creating or completing a sales task. Orders, payments, credit, inventory, and approved terms need stricter validation and, in some cases, human approval.

If the pilot candidate is still unclear, use the framework for deciding what to automate first in a business. Keep management queries in the separate design for an ERP-connected executive assistant. Once the next step is governed, the flow can feed WhatsApp and Teams follow-up without scattering history across conversations.

Kiia would start with a data map and a sample of real cases. That review usually shows whether configuration is enough, a CRM is warranted, or a small layer can close the gap. The decision then rests on evidence from the process, the integration, and its recovery behavior.