Infor ION Connect for Salesforce: Field Mapping, Bi-Directional Sync, Custom Objects, and Error Handling Explained

If you already have ION moving documents between Salesforce and your Infor ERP, you have probably hit one of four walls: a mapping that quietly breaks after a Salesforce layout change, a sync loop where the same record bounces between systems, a custom object with no standard BOD to carry its data, or a document stuck failed with no obvious next step. This article works through each at the configuration level, assuming you already understand how ION functions as the integration layer between Salesforce and the rest of the Infor stack and just need the configuration detail.

How Field Mapping Actually Works Between ION and Salesforce

Infor does not ship a packaged Salesforce connector the way it does for M3 or LN; there is no Salesforce-specific adapter in the connection point catalog. What you are actually running is the generic ION API connection point pattern, REST or SOAP over OAuth 2.0, with Salesforce BODs and field mappings your implementation team defined for this tenant. Every mapping is bespoke, which is why layout changes break things silently rather than throwing a clear error.

BOD structure and where Salesforce fields land in the DataArea

Every BOD moving through this integration, whether it originated in Salesforce or the ERP, is a VerbNoun document with an ApplicationArea and a DataArea. The ApplicationArea carries routing and sender metadata and the BODID; writing Salesforce field values there instead of into DataArea elements is a mistake in early builds. The DataArea is where the actual noun content sits, structured under the verb and noun names that define the document type, for example SyncCustomerPartyMaster or ProcessSalesOrder. ION does not auto-map new Salesforce fields; every field correspondence is something a person modeled, so a renamed field can desynchronize a mapping without raising any error. The mapping keeps running. It just stops carrying the data you expect.

Building the mapping in ION Connect Mapping and the graphical mapping modeler

You build and maintain these transformations in ION Connect, under Mappings, using the graphical mapping modeler. As Infor’s documentation on ION Connect Mapping explains, creating mappings requires understanding the structure of both source and target documents, and for anything beyond direct field correspondence you need working knowledge of XML and XSLT. For a one-to-one field, you drag the source element onto the target; for concatenation or picklist translation, you drop into a script step instead. A currency field with a locale-specific decimal separator will not silently coerce into the numeric type expected, and the mapping fails at validation, still worth testing after any change to a mapped field’s type.

The mapping itself is attached to a document flow riding on connection points. As Infor’s documentation on connection points and document flows describes, connection points provide the information ION needs to connect to an application’s message inbox and outbox, with the specific BOD documents each can send or receive selected explicitly, and the same connection point is typically reused across several flows.

What a mapping cannot do

As Infor’s documentation on document mappings states, a mapping cannot combine two BODs into one, and cannot split one BOD into multiple BODs. If your scenario genuinely needs fan-out, one Salesforce Opportunity update becoming two separate downstream documents, that requires a parallel flow, where the document is duplicated to two branches, each carrying its own distinct mapping.

The same documentation is explicit that mappings are not supported for reply BODs, meaning Acknowledge or Show documents, because reply BODs are sent directly from the receiver of a request BOD back to the original sender, outside the document flow model. Change the document type inside a mapping attached to a request BOD, whether Process or Get, and the sender receives an Acknowledge for a document type it was not expecting; change the verb away from Process, and the sender does not receive an Acknowledge at all, which from the Salesforce side looks like the integration silently stopped confirming records.

Bi-Directional Sync Between Salesforce and the ERP System of Record

Two-way sync is where most operational pain in this integration lives, because the architecture has to answer a question Salesforce and the ERP both implicitly assume they own: who is allowed to change this field last.

Document flow design for two-way sync

ION’s verb set gives distinct semantics for moving data, and conflating them is the most common design mistake in bi-directional builds. A Sync BOD informs a receiving application that a business object changed elsewhere and should be updated to match. A Process BOD requests that the receiving application perform an action, the correct verb when Salesforce needs to create or change a record in the ERP. A Get BOD, as Infor’s documentation on registering custom BOD schemas frames it, is a request to retrieve business objects using query-style selection, and its reply is a Show BOD, the only BOD type permitted multiple noun instances in a single document.

The practical pattern for two-way sync in ION Desk is two separate, independently triggered flows: one carrying Process or Sync BODs outbound from Salesforce to the ERP, and a second carrying Sync BODs back. Direction is a property of which connection point sends and which receives, so two directions of travel for the same noun are, mechanically, two flows.

Avoiding sync loops and defining system of record per field

A sync loop happens when an update written to Salesforce by the inbound flow gets picked up by Salesforce’s own change detection, a workflow rule or platform event, and republished outbound to the ERP, which writes it back, which Salesforce detects again. ION does not prevent this; its job is to move the document you tell it to move, with no native concept of an update having already originated from itself.

The mitigation has to happen on both ends. On the Salesforce side, any outbound trigger needs a guard condition excluding changes from the integration user. On the ION side, define field-level system of record explicitly, in writing: for every field, one system owns it, and the other side’s outbound mapping does not carry that field. A field with two-way write contention is the actual root cause behind nearly every sync loop ticket, and the fix is removing it from one direction’s mapping entirely.

This is also where why real-time data exchange between ERP and CRM systems reduces operational costs becomes specific rather than abstract: the savings only materialize if the sync is trustworthy, and a sync loop erodes that trust fast enough that users start re-entering data manually in both systems.

Reply BODs and why you cannot model them in a data flow

Acknowledge and Show BODs are not flows you build; they are automatic replies to Process and Get requests, routed back to the original sender outside the document flow canvas. You cannot attach a mapping, filter, or error handling logic to the Acknowledge that comes back after Salesforce sends a Process BOD. What you can do is get the Process BOD right on the way out, since the Acknowledge’s content is entirely a function of what the receiving system does with it.

This has a direct consequence for action codes. As Infor’s ION Development Guide explains, when a Process BOD with action code Add is sent, the unique identifier does not exist in the system of record yet, so Document Id is not populated on the outbound request; it appears once the record is created, in the resulting Acknowledge. Action code Change has to populate both Document Id and Variation Id, and Infor does not use action code Delete in Process BODs.

Custom Object Integration: Building Custom BODs for Salesforce Custom Fields and Objects

When a standard BOD does not cover a custom Salesforce object

Standard nouns like CustomerPartyMaster or SalesOrder cover the fields Infor anticipated when defining the OAGIS-based schema. A custom Salesforce object, or a heavily customized standard object with fields that have no analog in the standard schema, has nowhere to land. Stuffing custom values into unused elements of a standard noun saves time during the build and costs more at every subsequent ERP upgrade. The supported path is registering a genuine custom noun.

Defining a custom noun schema and registering it in the ION Data Catalog

A custom BOD needs a noun that already exists in the ION Registry, and the BOD XML has to comply with standard Infor message semantics, a root element of type VerbNoun, with the same ApplicationArea and DataArea structure as any standard BOD. You define the schema by adapting a file template, and as Infor’s documentation on custom BOD definition shows, the template uses a sample noun name you replace throughout with your actual name. With an XML-type template instead, you provide a name and a sample file, and ION generates the schema automatically, the faster path with a clean example payload.

Once defined, the custom noun is imported into the Data Catalog, where it becomes usable within ION, though it only becomes usable across the broader ION Service once adopted by the receiving Infor application. Registering the schema is necessary but not sufficient; the ERP side also has to be configured to recognize it. This is also where the same validation and error-logging discipline used in large-scale data migration projects pays off: test against representative records, including null and maximum-length values, before going live.

IDXPath and why the document ID definition matters for custom nouns

Every custom noun schema needs an IDXPath defined, the path identifying where the document’s unique identifier lives within the DataArea, typically a path to a DocumentID element under the noun’s header section. This is not cosmetic: ION uses IDXPath to track the specific business object instance across documents that reference it, so pointing it at the wrong element, a name field is a common mistake, breaks document tracking and recovery in ways that do not look like an IDXPath problem on the surface. The template also defines an optional DescriptionXPath and, depending on noun type, a StatusXPath worth populating so the status field stays visible to ION’s monitoring tooling.

Error Handling and Recovery for Salesforce-ION Document Flows

How ION classifies failures

As Infor’s documentation on error management for the ION API connection point lays out, the connection point classifies every response by status code into one of three buckets. Any 2xx code is success, and the data flow continues. Status codes 401, 500, 503, and 504 are connection errors, and on receiving one the connection point automatically retries the request. Every other status code is a document-specific configuration error, which does not get the same automatic retry.

This explains a recurring source of confusion: a 400 or 404 returned from the Salesforce REST API will not retry the way a 500 would, because ION classified it as a configuration problem with the document rather than a transient connection issue.

Retry behavior and Document Recovery

Document Recovery is the tenant-level function governing everything transmitted through the ION API connection and web services gateway, accessed from Administration, Connectivity, Document Recovery in ION Desk. As Infor’s documentation on Document Recovery describes it, every document is sent to its destination several times before the system marks it failed, covering temporary web service unavailability. That documentation, written for the Locally product library specifically, describes a default wait of around two hours before retrying. Verify this against your own product library.

What is consistent is the recovery mechanism itself: failed documents are visible on the Document Recovery main page, with a Next Run field showing the next automatic retry, and from there you select Inquiry, choose the document, and click Resubmit.

Monitoring document flow health in ION Desk and Event Management

Document Recovery handles failed sends. Event Management catches exceptions in documents that got through but carry values worth flagging, since a document can be a complete technical success and still carry data someone needs to know about. As Infor’s ION Desk User Guide describes for ION Desk’s management screens, monitors evaluate published documents against conditions you define and report exceptions as alerts routed to a distribution list, and from ION 12.0.6 onward this extends to alarm templates for the Alarms mobile app.

For file-based connection points, present when documents are staged through an intermediate file drop, a failed After Read Action, for example a rename that does not complete, moves the file to a defined Error Location rather than dropping it silently. The pattern across ION’s error handling is consistent: failures get routed somewhere identifiable.

Practical Checklist for Maintaining This Integration

• Before changing a Salesforce field referenced in an active mapping, check whether it appears in the mapping source schema, since ION will not warn you of a rename.
• Document, in writing, which system owns each field on both sides of the sync, and confirm the non-owning side’s mapping excludes it.
• For every custom noun in use, confirm IDXPath points to a guaranteed-unique identifier, not a display name.
• When a document fails, check the actual response status code, since codes outside the 2xx and 401, 500, 503, 504 sets are configuration errors and do not auto-retry.
• Use Document Recovery, under Administration, Connectivity, Document Recovery, as the first stop for anything stuck failed on the ION API or web services gateway side.
• Set up at least one Event Management monitor on business-critical flows so a business-incorrect document still gets flagged.
• Before modeling a one-to-many transformation, confirm a parallel flow is needed, since a mapping cannot split one BOD into multiple BODs.
• Re-test custom noun schemas against representative records, including null and maximum-length values, before activating a production flow.

Frequently Asked Questions

Can a single ION mapping convert one Salesforce BOD into two separate target documents?

No. A mapping transforms the contents of a document or converts it to another document type, but it cannot split one BOD into multiple BODs, or combine two BODs into one. The supported approach for fan-out is a parallel flow, with a separate, specific mapping in each branch.

Why does my Salesforce-to-ERP sync create a loop where updates bounce back and forth?

This is almost always a missing system-of-record decision, not a flaw in ION, which has no built-in concept of which side last legitimately changed a field. The fix is defining, per field, exactly one owning system, removing that field from the other direction’s outbound mapping, and adding a guard on the Salesforce side so integration-originated updates do not retrigger an outbound publish.

What happens if ION receives a Process BOD for a record that does not have a Document Id yet?

That is expected behavior for action code Add, not an error. Document Id is not populated because the unique identifier does not exist in the system of record until the record is created there; it appears in the resulting Acknowledge once creation completes.

Why is my custom BOD being rejected with a Confirm BOD instead of processing?

As Infor’s documentation on sending data to a web service explains, automatic transformation requires the incoming BOD to contain exactly one noun instance; zero instances or more than one results in rejection and a Confirm BOD. Check whether your mapping is bundling multiple instances into a single document. Sending multiple together requires the advanced transformation path with a custom XSLT.

How long does ION wait before retrying a failed document, and can that interval be changed?

Documented behavior for the Locally product library describes a default wait of around two hours before a failed document is retried, with the retry count configurable. Confirm the actual interval in your own environment rather than assuming it matches documentation written for a different product library.

Can I model error handling for an Acknowledge or Show BOD the same way I model it for a Process BOD?

No. Mappings, and flow-level error handling attached to them, are not supported for reply BODs, since Acknowledge and Show BODs are sent directly from the receiver of the original request back to the sender, outside the document flow model. Error handling happens by getting the request BOD, the Process or Get, correct on the way out.

What is the maximum length for a custom BOD noun and verb name?

As Infor’s ION Development Guide recommends, a noun name should not exceed 30 characters, a verb name should not exceed 11 characters, Acknowledge being the longest standard verb at that limit, and a full BOD Type name should not exceed 100 characters.

Where do I go to manually resubmit a document that ION has marked as failed?

Document Recovery, under Administration, Connectivity, Document Recovery in ION Desk. Select Inquiry, choose the failed document, and click Resubmit to force an immediate retry rather than waiting for the next automatic attempt shown in the Next Run field.

If you are working through one of these problems right now, the fastest path is usually to isolate which layer it actually lives in: the mapping itself, the document flow’s directional design, the noun schema, or the connection point’s error classification. For the architectural decisions sitting above any single document flow, a broader technical framework for structuring connection points and testing integration health is the next place to look.