How Limio Updates Salesforce Data
The Salesforce Data Integration lets Limio Commerce create data flexibly in the Salesforce data model. The data will typically be generated on a new order and updated via further subscription changes, such as upgrades and cancellations.
This is useful if you already have a CPQ system in place and need Limio to provide online commerce data to Salesforce.
Note: Limio provides a separate add-on, Limio for Salesforce, which allows customer service, customer success and sales team to manage orders and subscriptions directly in Salesforce. Go to learn more about Limio for Salesforce.
Limio's integration with Salesforce is managed via a plugin which is triggered during Limio's event-based Order Orchestration process. The current version of the Limio Salesforce plugin is v3. This integration allows you to:
Create a Salesforce Accounts for acquisition flows where your identity solution does not create data in Salesforce natively
Choose to create a Person Account or Business Account for new orders
Use Salesforce duplicate rules to avoid Accounts duplication
Activate Salesforce Platform Events to modify flexibly your Salesforce data with no code
Let's explore those one by one.
Getting started with the Limio Commerce Salesforce Plugin
To use the Salesforce integration, you will need first to integrate your existing Salesforce environment with your Limio Commerce environment.
If you wish to use certain options explained in this document, for example using Account & Contact, provide the information in your support request.
Account/Contact objects creation in Salesforce
Create Salesforce Account for new orders
To support unauthenticated acquisition flows and authenticated acquisition flow where the identity provider (e.g. Auth0, AWS Cognito, Microsoft Azure etc...) does not create Salesforce objects at the time of registration, this Limio plugin has the capability to create a Salesforce Account when an order is processed.
When an order is being processed, the Limio plugin for Salesforce will check if there is an existing crm_id on the user identity:
If it finds a match, Limio reuses that Salesforce Account and processes the order against it. No new Account is created and no error is shown. This is the normal path for a returning customer.
If not, Limio creates a new Salesforce Account (and Contact, for business accounts).
An error is only surfaced to the customer in one case: Limio attempts to create a new Account, Salesforce's duplicate rules match an existing record, and duplicate handling is not enabled in the plugin configuration. See Salesforce Duplicate Rule Check below.
You can see the mapping of Limio fields to Salesforce here: Account and Contact Mapping.
Salesforce Duplicate Rule Check (optional)
It is possible to set up duplication rules in Salesforce, which can match various criteria and perform predefined actions. For example:
A common action is matching Limio data against email/first name/last name and, if it matches, blocking the user from purchasing.
Or, matching an email on a user who is not logged in, and adding the order data to their existing Salesforce Account.
You can match on more or less data as you desire. The rule configuration is defined in Salesforce internally, and Limio will respond to the result of the rule by either associating the order to the account or erroring.
Enabling duplicate checks: The Salesforce V3 plugin requires the duplicateRule flag to be enabled in the plugin configuration. Without it, when Salesforce reports a duplicate match Limio raises an error instead of adopting the matched Account. Contact support@limio.com to enable this on your environment.
How duplicate rule results are handled:
Block
The order is rejected and the customer sees an error on checkout.
Allow (with alert)
Limio associates the order with the matched existing Account and processes it successfully.
No match found
Limio creates a new Account as normal.
If your Salesforce duplicate rules are set to "Allow" but orders are still being blocked, verify that duplicateRule is enabled in your Limio plugin configuration. Without it, Limio's default behaviour is to error when a duplicate is detected rather than follow the Salesforce rule action.
If a duplicate rule blocks an order unexpectedly, check the process event log in Limio (Settings > Process Events, or via the Limio Object API using the order ID) — the pluginErrorOutput field will reference the specific Salesforce duplicate rule that fired.
Transfer Ownership
Note: This feature requires Duplicate Rules to be enabled.
When handling unauthenticated or anonymously authenticated checkouts, the transferOwnership flag allows subscriptions and their related objects to be linked to a Limio identity.
If transferOwnership is enabled, and a user with an existing Salesforce account completes a checkout—whether authenticated or anonymously authenticated—this feature will check for a duplicate rule match. If a match is found, the subscription and related objects will be transferred to the Salesforce account associated with the detected crmID.
This ensures that customer data is correctly linked to the right account, even in cases where checkout occurs without full authentication.
Choose to create a Salesforce Person Account or a Salesforce Account & Contact
By default, the plugin will always create a Salesforce Person Account, but if you are a b2b enterprise then you may wish to enable the feature to create a Salesforce Account and Salesforce Contact. Please note, that currently this is an on/off capability so you can either always create personal accounts or always create business accounts.
Some key differences between personal and business accounts:
Personal Account
Business Account
Salesforce account record will be created with first name + last name as the account name
Salesforce account record will be created with companyName as the account name (or fall back to first/last name if the company name is not present)
Creates a salesforce account and uses that as the salesforce contact
Creates the salesforce account and contacts separately
Salesforce contact record created with PersonEmail
Salesforce contact record created with Email
crm_id will be the salesforce personal account id
crm_id will be the salesforce business account id
All other objects creation in Salesforce
Work with Salesforce Platform events (optional)
To use Salesforce Platform Events, you need to use the Salesforce plugin. A couple of important consideration for Platform Events:
You can decide to send events for all Limio orders or specific order types (e.g. just new orders).
Limio will include the Limio identity and external identity of the customer in the event payload.
Limio will also append __c in all key values in the object for each order or event type.
By default, any platform event that is sent will contain all the custom values that Limio sends on all order types. This means you don't need to add them manually.
Once Platform Events are being sent to Salesforce, you will need to implement a Flow in Salesforce to consume the platform events and map the data to the appropriate objects. Learn more in Using Limio Commerce-generated Salesforce Platform Events to populate your Salesforce data.
Send the whole Limio order in the Salesforce Platform Event (optional)
If enabled we will send the whole order as a string in the platform event.
With this option set, it provides a method to pass any details collected conditionally during the checkout and to provide a way to access Limio objects through IDs. For example, the update_subscription order type uses IDs to add and remove offers or add-ons from a subscription. The Salesforce Platform event will now get the Limio object data, so you can map that data back to Salesforce.
The i42as__LimioOrder__c field is a JSON string, not structured Salesforce fields. To extract individual values (e.g. email, address, custom fields), you will need Apex code in your Salesforce Flow. Declarative Flow formulas cannot parse JSON natively.
Key fields to note:
customerDetails.email— the customer's email address (not available as a first-class platform event field)customFields— any custom checkout fields collected during the orderbillingDetails— full address as submitted by the customer
Last updated
Was this helpful?

