Salesforce–Infor CSD/SX.e Integration: Implementation Guide
A Salesforce–Infor CSD/SX.e implementation connects customer-facing work with distribution operations. Start with customer and ship-to mapping, warehouse context, pricing ownership and a complete order workflow. Duet360 provides prebuilt, packaged business processes and a fixed implementation fee for agreed out-of-the-box functionality. Verify the interfaces and permitted actions for your release.
1. Choose the first distribution workflow
Begin with a problem sales and distribution teams can recognize. Examples include checking the right warehouse’s availability, reviewing a customer’s order status or sending an approved order request from Salesforce.
Define the business result and its owner. For an order handoff, the result should establish whether the correct company accepted the order and which reference Salesforce users can use to follow it.
Identify the CSD/SX.e product, release and deployment.
List the companies, branches, warehouses and Salesforce teams in scope.
Choose a first release with clear boundaries and measurable outcomes.
Record approvals, exceptions and the people who will sign off acceptance.
2. Confirm the supported interface and messaging setup
CSD/SX.e and CSI/SyteLine have different operational models and configuration requirements. Do not copy a manufacturing integration specification into a distribution project.
Infor’s current CSD/SX.e documentation describes BOD setup for ION integrations, including master-data activation and initial-load sequencing. Where that route is selected, confirm the required nouns, document flows and connection settings. Confirm the actual Duet360 interface and operation set during discovery.
If an API operation is part of the agreed workflow, document it separately with its permissions and response behavior. The presence of an ERP API or BOD in vendor documentation does not establish that every Duet360 package includes that operation.
Agree the inbound and outbound messages or operations for the selected process.
Record company, customer, ship-to, warehouse and document identifiers.
Confirm required fields, authentication, network access and service ownership.
Define how delivery, processing errors and final business acceptance are reported.
3. Map customers, ship-to locations and companies
A single Salesforce account may relate to several ERP customer or ship-to records. Define those relationships explicitly. Name matching alone can send a price or order to the wrong commercial context.
Decide which application owns customer creation, address changes, contacts, payment terms and other agreed attributes. Include company identifiers in matching rules where the same customer number can exist in more than one operating entity.
Sold-to and ship-to: stable matching keys and ownership of changes.
Company and branch: routing rules and permitted access.
Products and units: item identifiers, cross-references and conversions.
Terms and status: which values Salesforce should display and which remain controlled in CSD/SX.e.
Record changes: how inactive, merged or corrected records are handled.
4. Keep customer-specific pricing in context
Agree which system owns the sell price and discount decision. Record the customer, ship-to, item, quantity, unit, currency and relevant location context required to obtain the correct result.
Infor documents customer and ship-to pricing settings and optional warehouse-related pricing dimensions. Confirm which rules are enabled in the actual installation. A list price displayed in Salesforce must not be mistaken for the final customer-specific selling price.
Define when a price is refreshed and how users see its age.
Agree who can change a price or discount and which approval is required.
Test quantity breaks, changed units and ship-to-specific scenarios.
Recheck the approved values before an order handoff where the agreed process requires it.
5. Define warehouse inventory and availability
Availability needs a precise business definition. Decide which warehouse or branch a Salesforce user is viewing and what the displayed quantity means. Identify any relevant allocation, transfer or replenishment context that the selected interfaces can provide.
Agree the refresh frequency and show users how to interpret delayed information. Seeing inventory in Salesforce does not, by itself, reserve stock or confirm a delivery promise. Reservation and order acceptance belong to the agreed ERP workflow.
6. Configure the prebuilt order process
Duet360 includes prebuilt, packaged business processes designed to deliver predictable business outcomes. Apply that foundation to the selected distribution workflow rather than treating integration as a disconnected list of field transfers.
A practical first release can validate the customer, ship-to, item, unit, approved price and warehouse context before the order request proceeds. The agreed process then returns the supported acceptance status, order reference and later shipment or invoice information.
Customers retain full flexibility to adapt their business processes. Identify the required rules and approvals, confirm the available ERP operations, and separate standard configuration from additional implementation work.
7. Plan initial loads and ongoing updates
Agree which records must exist before transactions begin. Infor’s ION documentation calls for master-data setup and a defined initial-load order. Use the integration guide for the selected release instead of assuming all documents can be loaded together.
Record a cutover point and reconcile counts and identifiers after the load. Decide how updates received during the load are handled. Confirm that later changes reach the correct Salesforce record without creating duplicates.
Prepare representative customers, ship-to locations, items and warehouses.
Resolve missing references and conflicting identifiers before acceptance testing.
Agree the data window, update sequence and reconciliation owner.
Plan how to recover an interrupted load without duplicating business records.
8. Test distribution exceptions as well as the happy path
Run complete scenarios with sales, operations and finance users. Follow each request to its final ERP result, then confirm what Salesforce displays.
A technical message receipt is different from business acceptance. Test the meaning of each status and error for the configured process. Before retrying an order request, determine whether CSD/SX.e already created the transaction.
A valid customer and ship-to produce the expected warehouse and price context.
An incorrect ship-to, unit or product reference produces an actionable exception.
A changed customer price follows the agreed revalidation and approval rule.
Unavailable stock and partial fulfillment are represented accurately.
Delayed responses, service interruptions and repeated messages follow the configured recovery rules.
Shipment and invoice references return to the correct Salesforce account and order.
9. Include logs, Data Quality and support ownership
Duet360 logs are accessible to authorized users in Salesforce, and the product includes a comprehensive Data Quality component. Show users where to review integration activity and data issues before go-live.
Name the owner of customer or pricing corrections, the technical escalation contact and the person authorized to reprocess a failed request. Retain the source and target references needed to trace the business outcome.
10. Agree the fixed-fee implementation scope
Duet360 implementation is based on a fixed fee for its out-of-the-box functionality. This is a major differentiator: the agreed standard implementation starts from packaged business processes with a defined implementation fee.
Confirm the included processes, interfaces, companies, warehouses, mappings, data preparation and acceptance tests. Document exclusions and the treatment of additional requirements, recurring subscriptions, third-party licenses and enhanced support.
Standard onboarding is planned for four weeks, subject to scope, access, data readiness and customization. Confirm the schedule after discovery. Start production with controlled transactions, reconcile the first results and keep the named support owners involved.
Existing SX.e customer evidence
Levitt-Safety’s published case study covers Salesforce, Infor SX.e and IFS service data. It describes a shared view of customer activity and more coordinated recurring service scheduling across sales, distribution and service teams.
This is evidence for the systems and scope named in that customer project. It does not establish that every CSD release or IFS service integration is included in a standard package.
Prepare for your implementation discussion
Discuss your Salesforce–Infor integration with Endowance to confirm fit and the agreed standard scope. Manufacturers using CSI/SyteLine should use the separate manufacturing implementation guide.
Your CSD/SX.e release, deployment and operating companies.
The warehouses, branches, customers and ship-to scenarios that matter.
How customer-specific pricing and availability work today.
The first order or visibility workflow, sample records and known exceptions.
Target timing, acceptance criteria and additional requirements.
Your CSD/SX.e implementation questions, answered.
Is CSD/SX.e implementation the same as CSI/SyteLine implementation?
No. The products have different business structures, interfaces and configuration requirements. CSD/SX.e planning centers on distribution customers, ship-to records, warehouses, pricing and fulfillment. Validate the specific release and agreed operations.
Does the implementation use BOD messages?
Infor documents BOD-based ION integrations for CSD/SX.e. Confirm the messaging route, nouns, document flows and any separate API operations included in the actual Duet360 implementation. Do not assume the CSI message specification applies unchanged.
Can Salesforce show customer-specific prices and warehouse availability?
The agreed integration can provide the supported pricing and inventory information. Confirm customer and ship-to context, warehouse, quantities, units, refresh behavior and permissions. Displayed stock is not a reservation unless the selected ERP process makes one.
Can we begin with read-only order and invoice visibility?
A scoped visibility process can be a focused first phase. Define the source records, access and refresh behavior. Separately assess order submission, approvals and any ERP write operations.
Is the implementation fee fixed?
Duet360 implementation uses a fixed fee for agreed out-of-the-box functionality. Confirm the standard processes, mappings and exclusions in the proposal. Additional requirements, recurring charges and third-party licensing must be scoped clearly.
How should rejected or delayed orders be handled?
Review the Duet360 logs in Salesforce, correlate the source record and ERP reference, and establish the final business state. Assign ownership of data correction and technical investigation. Confirm whether an order already exists before reprocessing.
Comments