CRM, ERP, PIM, WMS and website integrations: decisions to make before development

A request such as “connect the website to our ERP” sounds like a development task. It is usually a business, data and operating-model task first.

The same product may have a description in a product information management system, a price in an enterprise resource planning system and availability in a warehouse management system. A customer may exist in the CRM under one identifier and in the ERP under another. An order can succeed on the website while failing downstream. A vendor can change an interface after launch.

Development cannot resolve those decisions by itself.

An integration is not complete when two systems exchange data once. It is dependable when the right data moves under defined rules, failures are visible and someone owns the outcome over time.

Before an agency can responsibly recommend architecture, price implementation or promise feasibility, the organisation must define what the integration is meant to achieve, which systems and records are authoritative, how exchange should operate and what happens when reality departs from the happy path.

The short answer: define eight things first

For every proposed website integration, define:

The business outcome and user task it must improve
The participating systems, owners, vendors and environments
The source of truth for each material field
The data contract, identifiers and validation rules
The direction, trigger, frequency and exchange pattern
Authentication, authorisation, privacy and secret handling
Failure, retry, duplicate, exception and reconciliation behaviour
Monitoring, support, change and long-term ownership

If several of these remain consequential unknowns, a fixed implementation scope would create false certainty. That is a credible reason for paid Discovery or a focused technical validation phase. A missing contact-field label is not. The question is whether the unknown could materially change the data model, architecture, effort, risk or viability.

Start with the outcome, not the acronym

CRM, ERP, PIM and WMS describe broad system categories:

A customer relationship management system may manage contacts, organisations, opportunities, service activity and marketing status.
An enterprise resource planning system may govern accounts, commercial terms, finance, orders, products or other operational records.
A product information management system usually concentrates product descriptions, attributes, categories, media references and localisation.
A warehouse management system supports inventory and fulfilment activity within warehouse operations.

Actual responsibilities vary by organisation and product. A familiar vendor name does not tell an agency how the client’s instance is configured, which modules are licensed or which data people treat as authoritative.

Replace “integrate the CRM” with an outcome such as:

Create a qualified lead with valid consent and route it to the right team.
Show an authenticated trade customer the catalogue and prices assigned to its account.
Accept an order online without staff entering it again in the ERP.
Display useful availability without promising inventory that cannot be fulfilled.
Let a customer view a dependable order status without calling the service team.

This turns a technology request into a testable business requirement. It also exposes whether integration is the right intervention. Sometimes a process, data-quality or ownership problem should be corrected before systems are connected.

Identify the systems, owners and environments

Create an integration inventory before drawing an architecture diagram. For every system, record:

Business owner and technical owner
Vendor and implementation partner
Product, edition, modules and current version
Production, test and development environments
Available API, webhook, file or messaging interfaces
Authentication method and access-approval process
Documented limits, maintenance windows and vendor dependencies
Data sensitivity and relevant retention requirements
Existing integrations that may be affected
Support contact and change-notification process

Do not treat a marketing page that says a platform “connects with” another product as sufficient technical evidence. The required operation may be limited to a particular plan, connector, region, object, field or transaction direction. Current vendor documentation, appropriate access and representative examples are needed before compatibility can be validated.

An early environment check matters as much as documentation. A system with no safe test environment can change the testing, migration and release plan. A vendor that controls API access can become a schedule dependency. Neither issue should be discovered after interface design is approved.

Decide the source of truth field by field

“The ERP is the source of truth” is often too broad.

The ERP may own account terms and accepted orders, while the PIM owns product copy and attributes, the WMS owns fulfilment status and the website owns a temporary basket. The CRM may own the sales lifecycle but not the customer’s legal billing record.

Build a field-level authority map. For each important item, identify:

The authoritative system
The common identifier
Which system may create or update it
Whether downstream users can edit a copy
Validation and transformation rules
What happens when values conflict
Retention and deletion behaviour

Identifiers deserve special attention. Email addresses change and are not always unique. Product codes can contain leading zeroes. Customer numbers may differ across regions. Two systems may represent an organisation, location and contact as different record structures. Without an agreed identity strategy, integration can create duplicates while appearing to run successfully.

The same discipline applies to formats. Currency, tax treatment, units of measure, time zones, addresses, category structures, null values and status codes need explicit mappings. “Send the order” is not a data contract.

Map direction, trigger and timing

For each data flow, answer three separate questions:

Direction: Which system sends, and which receives?
Trigger: What event or schedule starts the exchange?
Timing: How current must the receiving system be for the business outcome to remain dependable?

Common exchange patterns include:

A synchronous request when the user needs an immediate answer
A webhook or event when a meaningful change occurs
An asynchronous message or queue when work should continue without holding the user interface open
A scheduled batch for information that does not need immediate exchange
A controlled file transfer where a legacy system offers no appropriate API
A hybrid design, which is common in real operating environments

The pattern should follow the business requirement and actual platform constraints. Microsoft’s architecture guidance describes asynchronous messaging as a way to decouple producers and consumers, but it also introduces questions around ordering, duplicate handling, eventual consistency and operations. It is not automatically superior to a direct request. Microsoft Azure Architecture Center

Ask what a user should experience while downstream work is pending. An order confirmation must not imply that every dependent system has completed its work if only the website step has succeeded. Honest statuses such as received, validating, accepted or requires attention can be safer than presenting false immediacy.

Define business rules outside the connector

An integration often exposes disagreements that previously lived in spreadsheets, inboxes and staff knowledge.

Examples include:

Which account price wins when several rules apply?
Can a product be displayed when inventory is unknown?
When is an order accepted rather than merely received?
What happens when an address cannot be validated?
May a contact opt in to marketing during a transactional process?
Which team approves a new trade account?
Can staff override a value, and where is that override recorded?

Write these as business rules with named owners. Avoid burying policy inside undocumented code. A future system change, staff transition or dispute becomes far easier to manage when the rule and the person authorised to change it are explicit.

Design security and privacy into the flow

Every new connection expands the paths through which identities, permissions and data must be controlled.

At minimum, define:

How systems authenticate one another
Which operations each identity is authorised to perform
Where credentials and secrets are stored and rotated
Whether data is protected in transit and at rest
Which personal or commercially sensitive fields cross the boundary
What is recorded in logs and what must be redacted
How access is revoked when people, vendors or systems change
How consent, retention and deletion obligations propagate

The OWASP API Security Top 10 identifies risks such as broken object-level authorisation, broken authentication, unrestricted resource consumption and unsafe consumption of third-party APIs. It is a risk-awareness resource, not a substitute for threat modelling or system-specific review. If OAuth is used, the current security practices in RFC 9700 should inform technical design alongside the vendor’s supported implementation.

Australian organisations should also assess personal-information handling against their own obligations. The Office of the Australian Information Commissioner recommends a privacy-by-design approach in which privacy is considered from the start rather than added after implementation. OAIC: Privacy by design

Design for failure before the happy path

Networks time out. Records contain invalid values. APIs apply limits. Vendors deploy changes. A downstream system can accept a request and reject the transaction later.

For each flow, decide:

Which failures should retry automatically, and with what limit?
How will duplicate messages or repeated requests be made safe?
Where do invalid or unprocessable records wait for attention?
What can the user continue doing while a dependency is unavailable?
How is a partial transaction identified and corrected?
How are records reconciled between systems?
Who receives an alert, and what evidence will they need?
What is the escalation path when a vendor owns the failing component?

Retries without duplicate protection can create repeated orders or contacts. Alerts without business context can generate noise. Logs without correlation identifiers can make one transaction difficult to trace across several systems.

The Australian Cyber Security Centre’s event logging guidance recommends centralised access to logs, consistent timestamps and documented event-logging policies. The precise implementation depends on the systems and risk profile, but observability should be scoped as part of the integration rather than left for a production incident.

Test the operating reality, not only the endpoint

A successful demonstration with one clean record proves little about daily operation.

An integration test plan should cover representative volumes and data, valid and invalid records, duplicate requests, timeouts, rate limits, permission failure, downstream outage, changed reference data and interrupted processing. It should also verify user-facing statuses, business reconciliation, log redaction and alert routing.

Release planning should answer:

Is historical data being migrated or only new activity exchanged?
Will the old and new processes overlap?
How will cutover records be reconciled?
What constitutes a release blocker?
Can the integration be disabled without disabling the whole website?
What is the rollback or safe-hold position?
Who signs off business correctness, not merely technical connectivity?

Production credentials should not be used as a substitute for a test strategy. Where no suitable test environment exists, the risk and a controlled validation approach need explicit agreement.

Assign ownership for operation and change

Launch begins the operating phase. Name an owner for service health, an owner for data correctness and a decision-maker for business-rule changes. They may be different people.

The operating model should state:

What is monitored and during which service window
Alert thresholds and severity definitions
First response, escalation and vendor responsibilities
Runbooks for common incidents and reconciliation
Access-review and credential-rotation responsibilities
Dependency and API-version tracking
Change, testing and release approval
How support, maintenance and enhancements are requested and funded

An integration can remain technically online while producing stale prices, misrouted enquiries or unmatched orders. Operational monitoring therefore needs both technical health and business signals.

Keep warranty, maintenance, support and enhancements distinct. Correction of an eligible delivered defect under an agreed warranty is not the same as routine maintenance, incident support, a vendor-driven compatibility change or a new workflow. The governing project agreement should define the applicable boundaries.

What Discovery should produce

When uncertainty is material, paid Discovery should reduce it before implementation is committed. The outputs should be proportionate to the decision and may include:

Agreed outcomes and priority use cases
Current-system and stakeholder map
Data authority and flow diagrams
Interface and environment findings
Material business rules and exception paths
Security, privacy and non-functional requirements
Technical proof for high-risk assumptions
Phased scope, dependencies and ownership model
Implementation options, risks and a credible next decision

Discovery does not guarantee that the original connector idea will be recommended. It may identify a simpler configuration, a process change, staged integration, data remediation, vendor dependency or reason not to proceed. Australian Government digital guidance similarly describes Discovery as work to understand the problem, users, constraints and evidence before moving into delivery. Digital.gov.au: Discovery stage

A public Emote example: Sutton Tools

Emote’s public Sutton Tools case study illustrates why integration belongs inside the product and operating discussion.

The public case describes more than 21,000 products, an ERP integration, multi-region implementation and an Expert Tool Selector. In that setting, the visible product experience, product data, inventory process and recommendation journey could not be treated as unrelated workstreams.

The lesson is not that every catalogue needs the same architecture. It is that the user experience becomes credible only when the underlying data and operational responsibilities are credible. Current requirements, current documentation and current system access must still govern any future recommendation.

Questions to answer before requesting a development estimate

Bring these answers, or identify them as open decisions:

Which customer or staff task should improve?
Which systems and vendors participate?
Who owns each system and can approve access?
Which system is authoritative for each material field?
What identifiers connect the records?
Which direction, trigger and level of freshness are required?
What security, privacy and retention constraints apply?
What should happen during invalid data, duplicates or outages?
How will correctness be tested and reconciled?
Who monitors, supports and changes the integration after launch?

An agency can help resolve unknowns. It cannot responsibly price them as though they are already settled.

Frequently asked questions

Can an off-the-shelf connector remove the need for Discovery?

Sometimes it can reduce development. It does not remove the need to confirm objects, fields, direction, rules, licensing, limits, environments and ownership. A well-documented, low-risk connector may fit ordinary implementation scope; consequential unknowns may still warrant paid Discovery.

Does every integration need real-time synchronisation?

No. The required freshness should follow the user and operational consequence. Scheduled, event-driven, asynchronous and real-time patterns each have appropriate uses and trade-offs.

Can an agency confirm feasibility from vendor names alone?

No. Feasibility depends on actual editions, configuration, interfaces, permissions, data, limits, environments and business rules. Current documentation and appropriate access are required.

Is the API the whole integration?

No. The API is one interface. The integration also includes data meaning, identifiers, validation, business rules, security, failure handling, reconciliation, monitoring and ownership.

Who owns an integration after launch?

Ownership is shared across business, system and delivery responsibilities, but every duty needs a named party. The project agreement and operating model should make those boundaries explicit.

Define the operating responsibility before the connector

A dependable integration begins with a useful outcome and an honest view of the operating environment. It specifies who owns the data, how records move, how access is controlled, how failures are recovered and who remains responsible when systems change.

That work may confirm a straightforward integration. It may reveal a need for paid Discovery, a phased release or a different solution. Each is more credible than fixing an architecture and implementation promise around unknowns.

If your website needs to exchange material customer, product, order or operational data, book an initial meeting with Emote. We will clarify the business outcome, known system constraints and consequential unknowns, then recommend the smallest credible next step. No architecture or implementation is committed before the evidence supports it.