7 Systems Manufacturers Connect to Salesforce First: ERP, EDI, and Shipping

Manufacturers rarely get useful CRM visibility by connecting Salesforce to every plant and back-office platform at once. The first integrations should follow the customer order. Sales needs to know what a customer can buy, whether the order was accepted, what inventory can support it, when production will finish, and when the shipment will arrive. That makes integration order a business design decision rather than an exercise in connecting as many applications as possible.

A Salesforce manufacturing integration usually starts with the systems that hold commercial and fulfillment truth. ERP is often first because it owns customers, products, orders, invoices, and financial status. EDI follows closely when large customers or distributors place orders through standardized transactions. Shipping, warehouse, order management, production, and product systems become important as soon as customer-facing teams need reliable answers without asking operations to check several screens. Salesforce now calls Manufacturing Cloud Agentforce Manufacturing, and its current manufacturing documentation describes the product as the successor to Manufacturing Cloud while keeping the manufacturing CRM data model and workflows in place.

Salesforce should carry only the operational facts that belong in CRM, with clear ownership and update timing for each one. A sound Salesforce manufacturing integration gives sales and service enough operational context to make accurate commitments while leaving detailed execution in the applications built to run it.

TL;DR

For most manufacturers, the first integration wave should follow the path from customer demand to delivery. ERP usually sits at the center because it carries the commercial order, product, invoice, and account data that sales teams need. EDI matters when orders arrive from trading partners. Shipping and warehouse systems matter when customers start asking where an order is and whether stock can support a promise.

The remaining systems become priorities when they control information that changes a customer commitment. An OMS can own order orchestration. MES can show production status when finished goods aren’t yet available. PLM or PIM can control product lifecycle and sellable product details. The right Salesforce manufacturing systems plan doesn’t require every field from each source. It requires a clear source of truth, useful business events, and a sync method that matches how fast the information changes.

A practical first-wave order is ERP, EDI, shipping or TMS, WMS, OMS, MES, then PLM or PIM. That sequence can change. A distributor with heavy EDI traffic may move EDI ahead of ERP work. A make-to-order manufacturer may need MES earlier. The list works best as a decision framework whose sequence changes by business.

Why Manufacturers Connect Operational Systems Early

Manufacturing CRM breaks down when account teams can see opportunities but can’t see what happens after the customer says yes. A quote may look valid in Salesforce while an ERP credit hold blocks the order. A rep may promise delivery from an inventory number that ignores allocated stock. Service may tell a customer that an order is shipping today while the warehouse still hasn’t released it. These gaps create manual checking and conflicting answers.

Salesforce already expects manufacturers to connect operational applications. Its Manufacturing Cloud integration guidance says existing ERP and OMS platforms can connect through APIs, the MuleSoft Accelerator for Manufacturing, or other middleware. That matters because the CRM record and the execution record often need to coexist. The design question is which system owns the transaction and which fields Salesforce needs to expose to the people dealing with customers.

A strong Salesforce manufacturing integration starts with customer-facing decisions. If a sales rep needs a field to quote accurately, answer an order-status question, or explain a delivery change, that field is a candidate for CRM. If the field exists only to run a machine sequence or post a warehouse movement, it usually belongs in the source application. This filter keeps Salesforce useful and prevents integrations from copying operational detail without a clear reason.

The first connected systems also tend to be those that cross department boundaries. ERP links finance, order management, and inventory. EDI links the manufacturer to external trading partners. Shipping links fulfillment to the customer promise. Once those flows are stable, the team can bring in more detailed production and product information where it changes selling or service decisions.

ERP: The Commercial Backbone

ERP is usually the first major source because it holds the transaction after the sale leaves CRM. A Salesforce ERP integration can connect account identifiers, sellable products, price references, orders, invoices, credit status, and inventory information. The exact object list depends on the ERP and the business model, but the guiding rule is simple: Salesforce should show the operational state that changes what sales or service can tell a customer.

Salesforce provides manufacturing integration templates that reinforce this pattern. Its MuleSoft Direct integrations for Manufacturing Cloud include customer sync, product sync, and sales order sync patterns between Salesforce and SAP, along with a sales rebate integration. These templates don’t mean every manufacturer needs SAP or MuleSoft. They show the kinds of records Salesforce expects to exchange with a manufacturing ERP.

A Salesforce ERP integration should start by assigning ownership. ERP often remains the source of truth for invoiced amounts, payment terms, credit blocks, inventory accounting, and fulfilled quantities. Salesforce often remains the source for leads, opportunities, account activity, and pipeline. Shared records such as products, accounts, and orders need explicit rules. Without them, both systems can accept edits and create conflicts that are hard to reconcile.

The order record deserves special care. Sales may create the opportunity and quote in Salesforce, but the ERP may create the formal sales order after pricing, credit, tax, and inventory checks. In another company, an OMS may own that step. The integration should preserve the ERP order number in Salesforce and map line-level status where account teams need it. A single header status such as “processing” can hide partial shipments or rejected lines.

A useful first version of Salesforce ERP integration usually carries less data than teams expect. Start with the records needed to answer common customer questions and support forecasting. Add fields only when a named process uses them. This keeps the mapping understandable and reduces the chance that Salesforce becomes a stale copy of ERP.

EDI: Trading-Partner Transactions

EDI is often the next connection when distributors, retailers, aerospace customers, healthcare buyers, or other large trading partners send standardized business documents. A Salesforce EDI integration can surface the status of those transactions without forcing sales users into the EDI gateway. The useful output is visibility into the business events that sales and service need.

The purchase order is a common starting point. X12 defines the 850 Purchase Order as the transaction set used for established business practice around placing purchase orders for goods and services. In a manufacturing flow, the 850 may enter an EDI platform, get translated into the manufacturer’s internal format, and create or update an order in ERP. Salesforce may need the customer PO number, requested date, ordered quantity, account, and processing status.

Acknowledgment matters because receiving a PO doesn’t mean the manufacturer accepted every line. X12’s 855 Purchase Order Acknowledgment supports a seller’s response to a buyer’s purchase order. A Salesforce EDI integration can use that event to show whether the order was accepted, changed, or rejected. That gives account teams a better answer than simply seeing that an inbound file arrived.

Shipment notice is another high-value event. X12’s 856 Ship Notice/Manifest can carry shipment contents, order information, packaging details, carrier information, and related shipment data. Salesforce doesn’t need all of that detail for every user. It may need the shipment reference, ship date, carrier, tracking identifier, shipped quantity, and exceptions that affect the customer.

Invoice status can close the loop. The X12 810 Invoice example shows invoice information tied back to a purchase order and line item. A manufacturer may keep the official invoice in ERP or finance systems while exposing the invoice number, date, amount, and status in Salesforce. The same principle applies to other EDI messages: expose what changes customer handling and keep transaction processing in the system designed for it.

The strongest Salesforce EDI integration designs also handle changes. A customer may revise quantity or delivery dates after the original order. X12’s supply-chain transaction flow notes that purchase-order changes and acknowledgments need timing rules because an outdated transaction can affect what gets shipped. Salesforce should show the latest accepted business state rather than treating the first EDI document as permanent truth.

Shipping And Transportation Systems: Delivery Visibility

Shipping becomes a first-wave connection when customer teams spend time asking logistics for status. A Salesforce shipping integration can expose carrier, ship date, estimated arrival, tracking number, delivered quantity, and delivery exceptions. Those fields are useful because they answer customer questions. Pallet scans, route-planning details, and internal freight calculations may stay in the transportation platform unless a sales or service process needs them.

The source of shipping truth varies. Some manufacturers store the final shipment record in ERP. Others use a TMS, WMS, parcel platform, or carrier integration. The Salesforce shipping integration should read from the system that owns the confirmed shipment state. Pulling the same status from several sources creates conflicting timestamps and makes exception handling harder.

A shipment also needs line-level context when an order can split. One customer order may leave from 2 warehouses or ship on different days because one item is backordered. Salesforce should represent the customer-visible result. A rep needs to know which lines shipped, which remain open, and whether the promised date changed. A single tracking field at the order header is too weak for that case.

The integration cadence should match the process. A daily batch may be fine for old shipment history, but it can be too slow for an active delivery exception. A Salesforce shipping integration may use event updates for shipment creation and exceptions while using scheduled jobs for less urgent history. This mixed approach keeps customer-facing status current without making every logistics field real time.

WMS: Inventory And Fulfillment Status

WMS becomes important when the warehouse holds fulfillment detail that ERP doesn’t expose quickly enough. For Salesforce manufacturing systems, warehouse data can answer questions about inventory availability, allocation, picking, packing, backorders, and release status. The challenge is deciding which warehouse measures are safe for sales users to treat as promise data.

Salesforce’s manufacturing guidance recognizes inventory and supply-chain applications as external sources. Its external manufacturing data guidance for Data 360 says manufacturers can bring in data from inventory management systems, supply-chain systems, and systems that store machine or production-line operations data. That supports a wider architecture in which CRM uses selected operational facts rather than trying to own warehouse execution.

Inventory on hand is rarely enough. A warehouse may physically hold 500 units while 420 are already allocated. Some stock may be on quality hold. Some may be reserved for production or a priority customer. If Salesforce shows only the raw on-hand value, sales can make a promise that operations can’t meet. The useful measure may be available-to-promise, available-to-sell, or another business-defined quantity.

Salesforce already has manufacturing data mappings that can hold fulfillment context. Its Manufacturing Cloud order-item mappings include fields such as available quantity, quantity fulfilled, requested dates, list price, and product references. The field model is only part of the work. The integration team still has to decide where each value comes from and how often it can change.

A WMS connection should also respect warehouse boundaries. Inventory may differ by plant, distribution center, or region. The Salesforce record should show the location detail that affects the customer promise without flooding users with every bin movement. That makes WMS one of the most useful connected manufacturing systems when stock position directly affects selling.

OMS: Order Orchestration

An OMS belongs in the first wave when it controls what happens between order capture and fulfillment. A manufacturer may have orders from direct sales, distributors, ecommerce, EDI, service parts, or partner channels. The OMS can decide how those orders are validated, split, routed, held, or canceled before ERP and warehouse execution finish the job.

Salesforce’s manufacturing documentation names OMS alongside ERP as a system that can integrate with Manufacturing Cloud. That matters because an ERP connection alone may not explain the real order state when orchestration sits elsewhere. Salesforce may need the OMS order ID, hold reason, allocation status, cancellation state, fulfillment path, and customer-facing promise date.

The OMS should remain the owner of orchestration rules if that’s its role. Copying those rules into Salesforce creates 2 decision engines. The CRM can initiate a request or display a result without recreating every rule about sourcing, split shipment, or channel priority. This boundary becomes especially important when a Salesforce manufacturing integration spans several fulfillment nodes.

A separate OMS isn’t universal. Some ERP platforms already handle order orchestration well enough for the business. In that case, creating another integration layer adds work without adding a new source of truth. The decision should follow actual ownership in the manufacturer’s existing stack.

MES: Production Status That Affects Commitments

MES moves higher in priority for make-to-order and engineer-to-order manufacturers because customer dates can depend on work still running in the plant. A sales rep may see zero finished inventory even though the required units are scheduled to complete tomorrow. Without selected production context, Salesforce can show an incomplete picture of the customer promise.

A Salesforce manufacturing integration with MES should focus on business events. Useful fields may include production order status, scheduled completion date, actual completion, quality hold, and a production exception that changes the promised date. Detailed machine telemetry usually belongs in MES, a historian, or an industrial data platform unless service or commercial teams have a direct use for it.

This is where Salesforce manufacturing systems need careful boundaries. MES may update often, while sales needs only meaningful changes. Sending every work-center update into CRM can create large event volumes with little user value. A better design can publish a change when production starts, completion is delayed, quality blocks release, or finished goods become available.

Production dates also need definitions. “Scheduled complete,” “available for shipment,” and “customer promise date” aren’t interchangeable. Production can finish while quality inspection or warehouse staging still prevents shipment. The integration should preserve those distinctions so account teams don’t turn a plant milestone into a delivery promise too early.

PLM Or PIM: Product Truth For Sales

PLM or PIM is the seventh system category because manufacturers often keep product truth outside CRM. PLM may own engineering lifecycle details, revisions, and product status. PIM may own commercial descriptions, attributes, digital assets, and channel-ready information. ERP may still own the sellable SKU. The Salesforce manufacturing integration has to decide which source supplies which product fields.

Salesforce supports product structures that can reference external information. Its Manufacturing Cloud product documentation includes fields for product family, external data source, availability date, discontinued date, and end-of-life date. These fields matter when a seller needs to know whether a product can still be quoted or supported.

Current Salesforce guidance also states that manufacturers can integrate product information management and ERP systems with Manufacturing Cloud and use MuleSoft for external record movement. That makes PIM a logical source when product attributes are maintained outside CRM. It also supports a clear product-governance model instead of allowing manual edits in several systems.

PLM data needs more filtering. Sales may need an approved revision, lifecycle state, configuration rule, or replacement product. It usually doesn’t need every engineering change record. A good Salesforce manufacturing systems plan brings over the product facts that affect quotation, order acceptance, warranty, or service while leaving design history in PLM.

Product synchronization should also account for timing. A new SKU shouldn’t become sellable in Salesforce before the downstream systems can accept it. Likewise, a discontinued product shouldn’t disappear if service still needs its history. Product lifecycle rules should determine how creation, sale eligibility, retirement, and support status move between systems.

What Data Should Move Into Salesforce

The right integration scope is smaller than a full replica of the manufacturing stack. A Salesforce manufacturing integration should expose the facts needed for customer-facing decisions and preserve references back to the source records. That means the team should define data by business use rather than by asking each system owner to send every available field.

A Salesforce manufacturing integration also needs stable external identifiers. A Salesforce ERP integration should use them for shared commercial records. The ERP customer number, sales order number, invoice number, and line identifier give the integration a way to update the same records instead of creating duplicates. The same rule applies to EDI transactions and shipment references. Business keys need to survive retries and reprocessing.

A Salesforce EDI integration should also convert technical message states into plain business states. “850 received” may be useful to an integration team, while a seller needs “customer PO received” or “order awaiting validation.” The technical status can still be retained for support, but customer teams need a field that matches their process.

For Salesforce shipping integration, dates need defined semantics. Store whether a date is requested, promised, scheduled, estimated, actual, or delivered. Mixing those meanings in one field creates misleading reporting. The same discipline should apply to quantities such as ordered, allocated, produced, shipped, and invoiced.

Real-Time Vs Scheduled Synchronization

Not every manufacturing record needs instant updates. A Salesforce manufacturing integration should assign sync speed according to the cost of stale data. Sync frequency should follow the cost of stale data. If a 4-hour delay can cause a rep to promise stock that has already been allocated, inventory needs faster updates. If an old invoice history table changes only during nightly finance processing, a scheduled load may be enough.

Real-time or near-real-time updates make sense for events that change an active customer commitment. That can include order rejection, credit hold, major quantity change, shipment creation, delivery exception, production delay, or cancellation. A Salesforce shipping integration often benefits from this approach because customers notice late or split deliveries quickly.

Scheduled synchronization fits slower-moving reference data and history. Product catalogs may update every few hours or nightly depending on the business. Old invoices can load in batches. Forecast snapshots may follow planning cycles. The point is to match the cadence to the decision rather than using one schedule for every Salesforce manufacturing systems connection.

Salesforce supports both request-response and asynchronous integration patterns. Its integration pattern guidance explains that asynchronous messaging can queue work when a receiving application is busy and that Change Data Capture or Platform Events can support event-based communication, while middleware is useful for orchestration and message quality needs. This gives teams several options without requiring every interface to use the same mechanism.

A mixed architecture is common. Salesforce ERP integration may use APIs for a user-triggered credit check, events for order changes, and a nightly job for invoice history. Salesforce EDI integration may react to translated business events from an EDI platform rather than polling message tables. The design should make failure recovery visible whichever method is used.

Integration Architecture: APIs, MuleSoft, And Events

Architecture should reflect process ownership. Direct APIs can work well when 2 systems have a clear contract and limited transformation. Middleware becomes more useful when data must move through several systems, formats differ, retries matter, or one business event triggers several downstream actions. File exchange can still be valid for stable batch processes where latency isn’t important.

MuleSoft is one option in the Salesforce ecosystem, especially for manufacturers that need orchestration between Salesforce and ERP. The existing manufacturing templates for customer, product, and sales order synchronization can reduce design work, but teams still need to map their own identifiers, status values, security rules, and exception paths. A template doesn’t remove the need to decide who owns the record.

Events are useful when systems shouldn’t wait on each other. Salesforce Change Data Capture guidance describes CDC as the continuous synchronization stage of data replication and notes that external systems can receive near-real-time record changes. In a Salesforce manufacturing integration, that can help when another platform needs to react to a Salesforce account, order, or other supported record change without repeated polling.

The reverse direction needs equal care. ERP, EDI, WMS, MES, and shipping platforms may publish events through their own message brokers or middleware. Those events can be transformed into a Salesforce update or a platform event. The integration layer should also capture a correlation ID or external transaction ID so support teams can trace one customer order across systems.

Avoid point-to-point sprawl. If Salesforce connects directly to ERP, WMS, TMS, MES, PIM, and an EDI gateway with separate custom logic for each, changes become expensive to test. A shared integration layer can centralize transformations and retry logic where that complexity exists. Small environments may still be fine with a few direct APIs. The architecture should match actual complexity.

System-Of-Record Rules And Failure Handling

Every shared object needs a named owner. A Salesforce manufacturing integration works better when that ownership is written down before field mapping starts. “Both systems own it” usually means no one knows which update should win. For the ERP connection, the team might decide that Salesforce owns prospect and opportunity data while ERP owns the formal customer financial record and invoice. Account fields can then be split by attribute rather than treating the whole account as one master record.

The same rule applies to the EDI connection. The EDI gateway may own receipt and technical validation of the partner message, while ERP owns the formal sales order created from it. Salesforce should show both states only when users need both. Otherwise, one business status can summarize the transaction and keep technical troubleshooting data in integration logs.

Failure handling should be designed before go-live. If Salesforce submits an order request and ERP creates the order but the response times out, a blind retry can create a duplicate. The integration needs idempotent keys, reconciliation, and a way to tell whether the original transaction succeeded. Support teams also need a queue of failed messages with enough context to act.

The shipping connection has its own failure risks. A carrier event may arrive before the corresponding order line has been created in Salesforce. A shipment may be canceled and recreated under a new tracking number. A late event may overwrite a newer status. Sequence rules and timestamps have to be part of the design.

Reconciliation is the final control. Teams should periodically compare key counts and totals across Salesforce manufacturing systems, especially orders, order lines, shipments, and invoices. Reconciliation doesn’t need to copy the whole database. It needs to detect missing or inconsistent records before customers or finance teams discover them manually.

A Practical First-Wave Integration Sequence

The first wave should follow the commercial process and the systems that already own it. For many manufacturers, the Salesforce manufacturing integration sequence below works because each step adds customer-facing context without asking Salesforce to run plant execution.

Start with ERP if it owns the customer financial record, products, formal orders, and invoices. A working Salesforce ERP integration gives CRM users the backbone needed for order visibility. Next, connect EDI when trading-partner orders are material to the business. Salesforce EDI integration should surface accepted business states and exceptions rather than raw transaction payloads.

Add shipping or TMS when delivery status drives service calls or account management. A Salesforce shipping integration should answer where the shipment is, what shipped, and whether the date changed. Bring in WMS when inventory allocation and fulfillment status aren’t reliable enough from ERP alone. That gives sales a better basis for delivery commitments.

OMS comes next when it owns routing, holds, or split fulfillment. MES moves earlier for make-to-order businesses where production status changes promised dates. PLM or PIM joins the first wave when product lifecycle and commercial attributes are maintained outside ERP. These Salesforce manufacturing systems should enter the plan because they own a needed business fact, not because the architecture diagram has space for them.

The sequence can change without breaking the model. A high-volume distributor may need EDI before deeper CRM work. A plant with long lead-time custom production may need MES before shipping. A company selling configurable products may need PIM or PLM early because sales can’t quote correctly without approved attributes. Prioritize the system that closes the most important customer-information gap.

A successful Salesforce manufacturing integration ends the first wave with clear ownership, useful status, and supportable interfaces. Sales should be able to answer common order and delivery questions from Salesforce while operations keeps using the systems built for execution. That is a better measure of integration quality than the number of interfaces completed.

FAQs

What System Should A Manufacturer Connect To Salesforce First?

ERP is often first because it usually owns customer financial records, products, formal sales orders, invoices, and inventory-related data. The right starting point can differ if EDI, MES, or another platform controls the information that most affects customer commitments.

Why Is Salesforce ERP Integration Important For Manufacturers?

Salesforce ERP integration gives sales and service teams visibility into operational records created after a deal moves beyond CRM. It can expose order numbers, fulfillment status, credit information, invoice status, and selected inventory data without asking users to work inside ERP.

What Data Should Move From ERP To Salesforce?

Typical data includes ERP customer IDs, product references, sales orders, order lines, fulfillment quantities, invoice status, credit status, and selected availability information. The integration should move only fields that support a defined Salesforce process or customer-facing decision.

What Does Salesforce EDI Integration Do?

Salesforce EDI integration exposes useful trading-partner events inside CRM. It can show that a customer purchase order arrived, whether it was accepted or changed, whether a shipment notice was issued, and whether an exception needs account-team attention.

Should Raw EDI Messages Be Stored In Salesforce?

Usually no. Raw EDI payloads are better kept in the EDI or integration platform unless there is a specific audit or support need. Salesforce users usually benefit more from business statuses, key document numbers, dates, quantities, and exception details.

Does Salesforce Need A Direct Connection To A Shipping Carrier?

Not always. If ERP, WMS, or TMS already owns confirmed shipping status, Salesforce can receive the customer-facing shipment state from that system. A direct carrier connection makes sense only when it is the authoritative or most useful source for the required process.

What Should A Salesforce Shipping Integration Include?

Salesforce shipping integration commonly includes carrier, tracking number, ship date, estimated delivery, delivered status, shipped quantity, and exceptions. Split shipments may also require line-level links so users can see which products have shipped and which remain open.

When Should WMS Connect To Salesforce?

WMS should connect when warehouse data changes selling or service decisions and ERP doesn’t provide enough detail or speed. Useful examples include available inventory, allocation, backorder status, and pick or pack progress tied to an active customer order.

Does Every Manufacturer Need An OMS Integration?

No. Some manufacturers handle order orchestration inside ERP. A separate OMS connection is useful when that platform owns holds, sourcing, split orders, cancellations, allocation, or other order decisions that Salesforce users need to understand.

When Does MES Data Belong In Salesforce?

MES data belongs in Salesforce when production status affects a customer commitment. Scheduled completion, a production delay, finished-goods availability, or a quality hold can be useful. Detailed machine execution data usually stays in plant systems.

Should PLM Or PIM Be Connected Before ERP?

Usually ERP comes first, but product-heavy businesses can move PLM or PIM earlier when approved product attributes, configurations, or lifecycle status are required to quote correctly. The order should follow the data needed for the first customer-facing process.

Should Salesforce Manufacturing Integrations Run In Real Time?

Only where stale data creates a meaningful risk. Order rejection, shipment exceptions, or production delays may need fast updates. Product reference data and older invoice history may work well with scheduled synchronization.

Is MuleSoft Required For Salesforce Manufacturing Integration?

No. Salesforce can integrate through APIs or other middleware as well. MuleSoft becomes useful when the company needs shared transformations, orchestration, retries, monitoring, or several connections that would be hard to maintain as separate point-to-point interfaces.

How Do Manufacturers Prevent Duplicate Orders Across Systems?

Use stable external identifiers and idempotent processing. The integration should keep the source order ID, line ID, and transaction reference so retries update or confirm the existing record instead of creating another order after a timeout or partial failure.

How Many Salesforce Manufacturing Systems Should Be Included In The First Wave?

There is no fixed number. The 7 systems in this framework cover common commercial and fulfillment sources, but a manufacturer should include only the systems needed to support its first customer-facing processes and reliable order-to-delivery visibility.