This post details integrating Salesforce orders with RPM to ensure critical data points are tracked and maintained in both systems. While the focus here is on orders, it’s important to note that additional data can also be integrated between Salesforce and RPM.

Why Integrate Salesforce Orders with RPM?

Integrating orders between Salesforce and RPM allows RPM subscribers to associate commission data with orders and reconcile expected revenue with received revenue, commonly known as revenue assurance.

For subscribers who also want to assign agents as part of the integration, this process streamlines commission management by assigning agencies to commissions when they’re received and aligns commissions with orders.

Getting Started

Technical Resources Needed

To implement this integration, you will need:

• A developer with experience working with APIs and integrating systems.
• A user familiar with RPM customization.
• A user familiar with Salesforce customization.

API Access

Before starting the integration, ensure you have the necessary API access and permissions for both systems:

Salesforce

• API Access: RPM requires API access to your Salesforce instance.
• Edit Permissions: The Salesforce API User needs special edit permissions to bypass field restrictions when making necessary updates.

RPM

• API Access: Contact RPM Support to enable the API and sign up for an API tier if you don’t already have one.
• API User Setup: Set up an API user with the appropriate role and permissions.

Integration Implementation

Gathering Information

Start by gathering details about how orders are structured and managed in both systems:

Salesforce Orders

• How are your orders structured? For example, do you use a parent/child relationship or link the main order to service locations?
• At what point should the order be transferred to RPM (e.g., when the order status is “Closed-Won”)?

RPM Orders

• Have you customized your RPM order process to align with your Salesforce orders?
• Do you need additional workflows configured in RPM to support processes like commission tracking?

Defining the Source of Truth

A successful integration relies on defining the source of truth for data:

• Salesforce: Designated as the source of truth for order information. Any changes made in Salesforce take precedence over RPM.
• RPM: The source of truth for commission data, including entities like customer names, supplier names, and account numbers. Since RPM is the primary tool for managing commissions and the primary point of commission data entry, it is integral to ensure that commission entities are managed within RPM. 

Event-Based Triggers for Data Flow

To maintain synchronization between Salesforce and RPM, configure the following event triggers:

1. RPM & Salesforce: Whenever basic entities (Supplier, Customer, Account, Agency, or Rep) are created or edited in RPM, the changes are reflected in Salesforce. See Webhooks.
2. Salesforce: Whenever an order is created or edited in Salesforce and meets integration conditions (e.g., status is “Closed-Won”), the changes are reflected in RPM.

Data Mapping

Properly mapping data between Salesforce and RPM is critical for integration success. Identify how RPM’s basic entities correspond to Salesforce entities:

Basic Entity Rules

RPM enforces stricter rules than Salesforce for basic entities to maintain a defined commission structure:

• Supplier names are unique. 
• Accounts are unique under their specific supplier. 
• Customer names are unique. 
• Each entity has a unique identifier (“UID”) that should be used to sync between Salesforce and RPM.
• Suppliers and Accounts are always connected. Accounts from a supplier can only belong to a single customer. Accounts and customers are always connected as well. An account entity in RPM requires a supplier and a customer. 

Basic Entity Naming Rules in Salesforce 

It is important to keep in mind that Salesforce doesn’t have unique naming rules. You can create accounts with the same number under the same supplier and each account would have a UID but in RPM, it would generate an error because you can’t create duplicate accounts under a supplier. 

For example:

Recommendation

Create unique naming rules for supplier, customer, accounts (with customer and supplier combined with the account), and agency in Salesforce to prevent multiple entities with the same name from being created.

Orders

Identify the data points in Salesforce and their pair in RPM. 

An example of this field map could look like this:

Keep in mind that any structured data (ie. List fields in RPM) needs to match in both systems. RPM’s API does not allow for any creation of new list options. Any setup changes made to Salesforce order structured data or data points need to be set up in RPM.

Validation Considerations

Customer Specific Recommendations

In RPM, accounts are assigned to reps, and since multiple accounts can belong to the same customer, multiple reps could have commissions under the same customer. This will not affect the integration process but if you have a specific need to track the reps associated with the customer at the customer level versus the account level a custom object has to be created in Salesforce to track the information.

A custom entity in Salesforce can be created to track the customers from RPM instead of the default customer entity. 

Salesforce Validation Rules

To prevent duplicate records and maintain synchronization, consider implementing the following rules in Salesforce:

• Suppliers should have unique names.
• Accounts should be unique by both account number and supplier.
• Customers should have unique names.

Additionally, validate that every supplier, account, or customer in Salesforce has an RPM ID and vice versa.

Agencies and Reps

• Agency Names: Must be unique in both Salesforce and RPM.
• Rep Names: Can have duplicates, but each Rep entity is unique by its ID.

RPM requires rep usernames to be globally unique across all RPM subscriptions. Consider using a combination of fields (e.g., First Name + Last Name + Salesforce ID + RPM ID) to ensure uniqueness.

Going Forward: RPM Functionality Best Practices

Some RPM features, while useful, require careful consideration after integrating Salesforce and RPM to prevent synchronization issues:

1. Customer Mergers: RPM allows merging multiple customers into one record, but this action isn’t tracked via API Webhooks. Perform these actions cautiously or avoid them altogether. If a customer merge is done make sure that the merge is also done in Salesforce.
2. Account Mergers: Similar to customer mergers, account mergers require careful handling. If possible, add an account alias before the accounts that need to be merged are created. Account aliases allow for the tying of multiple accounts to one account number. 
3. Account Moves: Moving accounts between customers is safe as long as corresponding changes are updated in Salesforce.

Summary

This document has provided a detailed, non-technical overview of integrating Salesforce orders with RPM. By completing this integration, RPM subscribers can enhance their revenue assurance programs, ensuring accurate tracking of expected and received revenue.

If you are interested in integrating Salesforce and RPM, then hit this 👇.