One of the major components of any Salesforce implementation is building functionality to give users the ability to view data from other systems while in Salesforce. Integrating data from other sources is a powerful way to help build a complete picture of a customer within Salesforce. The most frequent use case is to bring in data from the Enterprise ERP application, such as customer accounts, products, orders, invoices, shipments, etc.
This information can empower users in various ways: Sales Reps can answer customer questions about order status or expected delivery dates, Customer Service can review invoice discrepancies and issue account credits, and Leadership Teams can develop metrics and track KPIs by comparing CRM interactions against ERP data points. By providing additional data to users and building advanced metrics based on the combination of transactional and interactional data, administrators can help take their Salesforce org to the next level.
Identifying the Data
Once it has been determined that a data integration is needed, the next step is to determine how to best store and use the data within Salesforce. As with anything in Salesforce, there are multiple ways this can be accomplished. The recommended first step is to ask questions regarding the data and to determine how it will be used. Some useful questions are:
- What is the data that needs to be pulled into Salesforce?
- Which system currently houses the data?
- What is the volume of the data? How many tables and approximately how many rows per table?
- Who will use the data?
- How will they use the data?
- Do we need to report on this data in Salesforce?
- Do we need to relate this data to existing objects or other data being integrated?
- How often does this data need to be refreshed within Salesforce?
These questions, plus any additional follow-up questions you might need, will allow you to gain an understanding of the business and the technical needs surrounding the data.
Designing the Data Model
Once you know how the data will be used, you can start considering how to design the data model. One of the best practices of data modeling is to minimize the number of custom objects by leveraging standard objects. This practice should be applied when possible, but it may not be a wise decision when considering how to store integrated data. When deciding whether or not to load external data into a standard object, the main set of considerations need to be focused on how the data in those standard objects are used.
Note: The third option after standard or custom objects is to use external objects, which will not be included in this discussion and will be reviewed at a later date.
Consider the Account object and assume that there are two types of accounts: prospect and customer. Customer account data is normally stored within an ERP system and has strict security around who can edit that data, while prospect account data has relaxed controls and is usually not maintained within the ERP system because the account is not a customer. There are really three options for managing account data:
- Store all account data within the Account object
- Build a custom table for customer data and store prospect data within the Account object
- Store the customer data in the Account object and the prospect data within a custom object
Considering the Account object is deeply integrated with most of the standard Salesforce functionality, it makes sense to store both customer and prospect data within the Account object. We would use record types, field-level security (FLS), and page layouts to control who can edit records and fields. Any customer account data that is fed from ERP should be read-only for all users. The rest of the data can be managed as the business rules dictate.
Now we will look at the options for managing order data within Salesforce. A standard Order object exists, but most companies create and manage orders within their ERP since this is transactional data. If no order data is being created within Salesforce then it is possible to load ERP order data directly into the standard Order object and you would then need to customize the object as needed and ensure that the data is read-only for users. This solution will work perfectly to meet the requirement.
But what happens in the future if the business wants to start generating orders within Salesforce to feed into ERP? Additional configuration will be needed on the Order object to segregate ERP order data from Salesforce order data. Again, this is an acceptable solution to meet the requirements. The downside is that you would need to backward design the object to the data that already exists instead of starting with a clean standard object.
For instances like this where a standard object exists and there is a possibility of using the standard object in the future, I prefer to build a custom object to store this data. It does increase the data model, but it also allows you the flexibility to model it as an exact match of the ERP data model, gives you the ability to completely wipe the data within the table and reload the entire table if the need arises, and keeps the standard object available for future enhancements.
When building an object like this, I prefer to use the naming convention of “erpName objectName”, for example, “JDE Orders”, “EBS Invoices”, or “AX Shipments.” This naming convention allows for easy object identification and tracking.
As you can see, there are several ways to manage integrated data within Salesforce and multiple ideas to consider when deciding how to store the data. However you decide to store and manage the data, the important thing is to do it in such a way that easily meets the business need and makes the data accessible to users. It should be considered complimentary data that helps to complete the picture of a customer and empower users by giving them more information than typically lives within Salesforce.