CRM ERP Workflow Integration Services

Deal-won trigger in Salesforce (via Apex trigger or Flow), HubSpot (via HubSpot Workflow webhook action), or Pipedrive (via Pipedrive webhook) initiates an ERP order creation call to the connected ERP system: SAP via BAPI_SALESORDER_CREATEFROMDAT2 (RFC function module); Oracle ERP Cloud via the Order Management REST API (POST /orderManagement/orders); NetSuite via SuiteTalk REST (POST /record/salesorder); Microsoft Dynamics 365 Business Central via the Business Central OData v4 API. Field mapping is defined during the scoping phase and documented in a mapping specification: CRM deal fields map to ERP order header and line fields (account ID to customer reference, deal line items to order line SKU and quantity, negotiated price to order price override, shipping address to delivery address). Pre-order validation runs before the ERP call: required fields checked (product line items not empty, shipping address present, customer exists in ERP -- with customer creation triggered if not), and business rule validation (order value above minimum order threshold). On successful ERP order creation, the ERP order number is written back to the CRM deal as a custom field (or an associated object/note) so the sales rep sees the ERP reference and can quote it to the customer. On ERP creation failure: the error message is logged, an alert is sent to the operations team via Slack or email with the deal link and the error detail, and the deal is flagged in the CRM for manual follow-up rather than silently failing.

Order status events from the ERP -- picking initiated, packing complete, dispatched with tracking number, delivered -- are consumed via ERP webhook (SAP Business Eventing or SAP CDS Event Mesh; Oracle ERP Cloud Business Events; NetSuite SuiteScript event handler; Dynamics 365 Business Central webhook subscription) and written to the corresponding CRM account and deal record. Status updates appear as activity timeline entries in the CRM (Salesforce Activity, HubSpot Timeline Event, Pipedrive Activity) so the sales rep has a complete chronological view of the order lifecycle from deal-won to delivery without opening a second system. Tracking number push: when the ERP records a dispatch with a carrier tracking number, the tracking number is added to the CRM deal and optionally triggers a customer-facing notification via the CRM email workflow or a Twilio SMS (depending on your customer communication preference). Delivery confirmation from the carrier (via AfterShip or EasyPost webhook on delivery scan) closes the fulfilment status in the CRM deal record with the delivered timestamp. Exception routing: when the ERP flags an order as delayed (supplier shortage, warehouse hold, carrier exception) or when a delivery fails (failed delivery attempt, refused delivery, returned to sender), the customer success manager assigned to the account in the CRM receives an automatic task with the exception detail and a suggested customer communication template -- the CSM is notified before the customer calls.

Invoice creation in the ERP triggers a sync to the CRM account record: invoice number, invoice date, due date, amount (gross, net, VAT), line item summary, and payment status (outstanding, part-paid, overdue, paid) are written to a custom object or associated record in the CRM (Salesforce Financial Account, HubSpot custom object, Pipedrive deal-linked note). The sales or account manager can see the full invoice history for an account from within the CRM without ERP login, making renewal conversations and upsell qualification conversations possible without a finance system detour. Payment received event from the ERP (triggered by the ERP posting the customer payment against the invoice) updates the invoice status in the CRM to paid with the payment date and payment method. Overdue invoice alert: when an invoice passes its due date without payment, an alert is created in the CRM as a task assigned to the account manager with the invoice details, the number of days overdue, and the customer's payment history (percentage of invoices paid on time in the last 12 months) so the account manager has context before making the chase call. Credit exposure visibility: current outstanding balance and credit limit from the ERP displayed on the CRM account record -- so the sales team knows before offering a new order whether the customer is at or near credit limit, preventing orders that will be blocked by the ERP on submission.

Customer account and contact data synchronised bidirectionally between CRM and ERP using event-driven triggers rather than scheduled batch jobs -- changes propagate within seconds of the originating event rather than overnight. New customer created in CRM synced to ERP customer master at the point of first order: company name, registered address, VAT/tax ID, payment terms, and credit limit request are passed from CRM to ERP customer master (SAP Customer Master via DEBMAS IDoc or CREMAS IDoc; Oracle Customer Hub REST API; NetSuite Customer POST /record/customer; Dynamics 365 BC Customer Card via OData v4 POST). ERP-originating updates reflected in CRM: credit limit changes posted by the finance team in the ERP update the CRM account field within 60 seconds via ERP webhook; billing address and payment terms changes sync from ERP to CRM on the assumption that finance owns these fields as system of record. Duplicate detection using configurable match keys -- company name normalised (Levenshtein distance threshold), VAT/tax registration number exact match, email domain match -- before any new record creation; suspected duplicates are surfaced to an admin review queue rather than auto-merged. Conflict resolution rules configured per field: ERP wins for financial fields (credit limit, payment terms, VAT number); CRM wins for relationship fields (account owner, deal stage, communication preferences); last-write-wins for address fields with timestamp comparison. Contact sync covers the key relationship contacts: billing contact, technical contact, and primary commercial contact synchronised bidirectionally; CRM contacts added as ERP contact persons under the customer master account; ERP contact updates (new billing contact designated by finance) reflected in CRM. Customer hierarchy support: parent/child account relationships in CRM (group holding company with subsidiary accounts) mirrored in ERP customer hierarchy for consolidated credit limit management and group invoicing. Merge event handling: when a CRM account merge or ERP customer consolidation is performed, the surviving record identifier is propagated to both systems and historical transaction references on the merged record are repointed so reporting continuity is maintained.

Quote generated in CRM or CPQ with product and pricing data pulled live from ERP price list at the moment of quote creation -- not from a price list that was synced last night -- so the sales rep never quotes a superseded price. Price list pull mechanism: Salesforce CPQ (Steelbrick) calls a custom Apex REST endpoint that proxies the ERP pricing API (SAP Condition Records via RFC_READ_TABLE or /SAPSRM/RPO_BE_CATALOG_ODP_GET; Oracle Order Management Price Lists REST; NetSuite Item Pricing via SuiteTalk SOAP search; Dynamics 365 BC Sales Price API via OData v4); the ERP returns the customer-specific pricing (contract price, volume tier, currency, effective date range) and the CPQ populates the quote line with the validated price. Customer-specific pricing honoured: contract pricing negotiated at the account level in the ERP is applied automatically when the sales rep creates a quote for that customer -- no manual lookup, no risk of quoting list price for a customer with a negotiated rate. Quote-to-order conversion: when the customer accepts the quote and the sales rep marks the deal as Won in CRM, the accepted quote version is passed to the ERP order creation endpoint (SAP BAPI_SALESORDER_CREATEFROMDAT2 with ZBAPI_SALESDOCUMENT_CHANGE for quote reference; Oracle Sales Order Create REST; NetSuite Sales Order POST with quote reference in custbody field; Dynamics 365 BC Sales Order POST with reference to the originating quote). The ERP order is pre-populated from the accepted quote: customer reference, delivery address, line items (SKU, quantity, unit of measure), negotiated pricing, payment terms, and requested delivery date -- no re-entry, no risk of transcription error. Quote version management: each revision of the quote is versioned in the CRM with a version number and the field-level changes recorded (price change, quantity change, terms change); when the customer accepts a version, the accepted version number is recorded on the ERP order as an external reference, creating an audit trail linking the ERP order to the specific quote version that was accepted. Approval routing: quotes above configured value thresholds route through an approval chain before the customer receives the quote (not before the order is created) -- approval at £10k manager level, £50k director level, with the approver seeing the deal context, the margin %, and the discount applied relative to list price; approved quotes are locked from further editing until a new version is initiated. Multi-currency quoting: quote is created in the customer's billing currency with currency rate pulled from ERP at the time of quote creation; currency rate recorded on the quote so margin calculations are consistent even if the rate moves before the order is placed.

Event-by-event logging records every CRM trigger, outbound ERP API call, ERP response payload, and processing outcome to an append-only event log -- structured JSON per event including the originating CRM record ID, the ERP endpoint called, the HTTP status code, the ERP response body (truncated at 10KB for large payloads), the processing duration in milliseconds, and the outcome (success, validation failure, ERP error, transient error, retry scheduled). The event log is searchable by CRM record ID, ERP order number, event type, and date range so the operations team can reconstruct the full history of any integration event without needing production database access. Error classification separates transient failures from permanent failures: transient failures (HTTP 503, connection timeout, ERP unavailability during maintenance window) are retried with exponential backoff (initial retry at 30 seconds, then 2 minutes, 10 minutes, 1 hour, 4 hours; maximum 5 retries over 6 hours) before being moved to the dead letter queue. Permanent failures (field validation error, customer not found in ERP, duplicate order reference) are moved immediately to the dead letter queue without retry -- retrying a validation failure without fixing the underlying data produces the same failure on every attempt and wastes processing cycles. Dead letter queue review interface: each DLQ item displays the original CRM record, the failure reason, the ERP error detail, and the recommended resolution action (create the customer in ERP, add a missing required field on the CRM deal, correct the shipping address format); the operations team can correct the data and re-queue the event for reprocessing from the DLQ interface without engineering involvement for common data errors. Alert routing: failed integrations that move to DLQ generate an immediate Slack notification or email to the configured operations channel with the deal link, the ERP error message, and the recommended resolution; transient errors that exhaust retries generate a P2 alert; a complete integration flow outage (zero successful events in 15 minutes during business hours) generates a P1 alert via PagerDuty or configured on-call routing. Integration health dashboard: real-time view of events processed per hour, success rate per integration flow (deal-to-order, fulfilment sync, invoice sync, account sync), current DLQ depth, average processing latency per flow, and ERP API response time trend. SLA reporting: weekly summary of integration success rates, DLQ volumes per category, and average resolution time for manual interventions -- giving the operations manager a factual basis for prioritising data quality improvements in the CRM or ERP that are causing integration failures.