ERP > Salesforce Integrations

Written By Ian Moore

I recently worked with 3 projects that included SAP or Oracle to Salesforce transformations for Field Service assets. In each of the projects there were different scenarios of where we could take the solutions based on where the customer was at with their current platforms, asset volumes, CRM etc. ie. where they have their master data and where that master data needs to move to for actionable insight in the field service teams ecosystem *think mobile. This brought me to write this article on some of the key concepts and rules when integrating an ERP to Salesforce when the ERP is already well established which is most often the case. (There are many ERPs, but for this article I will lead with SAP to make it fit the use cases.) I would like to also discuss the solution options and challenges we ran into without disclosing too much on design.

So typically you will have Oracle and SAP as the master of key data but to do a clean transformation you still need to provide options to the client on where they can place their master detail records? This includes the pros and cons of each solution path.

If the client chooses to keep most master data in SAP then SAP will remain as the System of Record (SoR) and therefore, the authoritative source for master/detail objects such as:

    • Accounts (Customer master)

    • Products (Material master)

    • Price books

    • Contracts

    • Asset Hierarchy

As I mentioned - if the clients assets are heavy volumes in the hierarchy then you may run into the challenges in Salesforce for supporting 10k assets per hierarchy and setting up additional hierarchy towers will provide challenges. In some cases our clients are growing their assets by X percent so some options will not be sustainable.

If the client is running another platform like ServiceMax then this platform will take a large share of the asset ownership to control the field service actions. I have worked with ServiceMax over the years on many projects as a Certified specialist and it is a beast. It has a lighter option called Asset360 which is native and built on the Salesforce platform which provides some of the key offerings around the optimization of the entire asset lifecycle but not the heaviness of the full platform and Smax licensing which can be expensive. (ie. why not have all licensing on one book vs 2?)

So going forward lets assume that SAP will be the system of record for accounts, contacts, products, price books, contracts and overall assets.

SAP as SoR:

This means that the following is true:

  • Salesforce will typically only store a copy for reference and operational use in the CRM processes.

  • Changes in Salesforce for these records should generally be restricted or flagged for review before syncing back.

  • Rule: If SAP owns it, Salesforce should be read-only or have controlled write-back workflows.

  • Note: I could discuss that a Work Order should be able to be created from the Salesforce field tech and sync back for proper SAP ID setup/sync but these kind of things you need to own and prepare for. I’m taking into consideration you would already know this requirement and others like it.

Rules to Support the Golden Rule for SAP>Salesforce integrations when SAP owns master data:

  • “Salesforce should consume master data from SAP, not redefine it.”

  • All integration logic should preserve SAP as the ultimate source, while giving Salesforce enough data for CRM workflows and analytics.

Integration Architecture Patterns:

It’s always good to understand the options for syncing the data from each of the systems.

  • Near Real-Time Sync: via middleware like MuleSoft, SAP CPI, Dell Boomi, etc. Near RT is complex, system resource consuming, and has to have a good use case.

  • Batch Sync: periodic jobs for large datasets (e.g., nightly product catalog updates).

  • Hybrid: real-time for critical updates (e.g., customer status changes) and batch for bulk master data. Balancing a Hybrid ecosystem will take a knowledgable and experienced TA for insight and sign-off.

Key concepts:

  • Use middleware for mapping and transformation to decouple systems.

  • Keep a canonical data model so Salesforce fields map cleanly to SAP fields. (*more discussed on this topic below). In short, if you can’t keep a canonical data model, keep a mapping template sheet with each object as a tab so that you have a running master. What is a canonical data model: (for visual see link above). A question I get often is whether CDM is a middleware? “While a canonical data model is not middleware itself, it is often implemented using middleware to facilitate data translation and integration between different systems. It acts as a common data format that various systems can translate their data into and out of, enabling seamless communication and data sharing”. It makes sure both sides communicate properly. IN short the purpose of the CDM is to enable an enterprise to create and distribute a common definition of its entire data unit.

  • A canonical data model (CDM) is a standardized, common representation of data used across different systems within an organization. It acts as a central format for data exchange, simplifying integration and reducing the complexity of managing multiple data formats. Instead of point-to-point integrations between each system, data is translated to and from the CDM, acting as a universal translator

  • Leverage SAP IDs (Customer Number, Material Number) as external IDs in Salesforce.

  • An external ID is a unique identifier that links a record in one system to its corresponding record in another system. It allows for seamless data exchange and synchronization between different platforms, acting as a bridge between disparate systems

Data Synchronization Rules:

Per this article, SAP is the primary master data store so the following data sync rules are available:

  • Create record in SAP > Push to Salesforce: no direct Salesforce creation for core master records unless you have a “prospect” workflow.

  • Update in SAP > Overwrite in Salesforce: Salesforce updates should not overwrite SAP unless explicitly designed or it will impact reporting, compliance and possibly financial numbers.

  • Soft vs. Hard Deletes: If a record is deleted or made inactive in SAP, decide whether Salesforce record is: Deleted or Marked as Inactive to keep a historical reference for insight and reporting.

  • Note: If you are Salesforce Certified, you will know to use Salesforce’s External ID and Upsert to avoid duplicates. When I say SF Certfied I mean you have an Admin + 2 additional certs minimum.

Transactional Data:

  • SAP will own transactions like orders, invoices, shipments.

  • Salesforce might show them in read-only related lists via integration.

  • ie. Opportunities created in Salesforce will be converted to orders in SAP so you will need trigger points for the handoff.

  • ie. Parts inventory consumption in a depot, truck or client location (think hospitals that keep their own surplus of assets).

Security, Governance & Error Handling:

  • Data Validation: Ensure incoming SAP data matches Salesforce picklists, required fields, and data types.

  • Data Validation Metadata: I would also suggest clean dedicated work (meaning high profile ownership) be done to map the metadata over so that what is represented in SAP can map correctly to Salesforce or any other systems for reference. Metadata, Metadata, Metadata. If your unsure why I mention this 3x research this topic with some diligence. ie. I have had multiple projects passed over with no context to the naming conventions, details or anything else for records, fields etc from the previous implementation partner (na) and it makes my job AND everyone else’s extremely painful from mapping data to creating reports and process flows.

  • Error Logging: Middleware should log and retry failed syncs. Have your CoE and associated War Room keep tallies via dedicated reports to check in on a periodic basis. This will keep you on your toes to issues that may need resolving and bigger issues under the surface.

  • Partial Failures: Design processes so one bad record doesn’t block the entire batch.

  • Audit & Compliance: Track who changed what and when, across both systems. This is about accountability people. If anyone can make changes at any time without accountability, you should hear the gong of death in the distance. I have seen this - its a serious RISK. Actual quote, “I didn’t know X field did X to X” - go back to my Metadata section above.

Performance & Scalability:

  • As a primary rule, (1) Know Salesforce API limits (2) Respect Salesforce API limits (3) Have actions on the RIGHT OBJECT (don’t stack up the standard objects (ie. Account) when the trigger or such needs to be further down in the hierarchy of actionable objects.

  • Use bulk APIs and batch sizes.

  • Filter SAP data before sending to Salesforce. Just because SAP is your system of record doesn’t mean it couldn’t benefit from some clean up and standardization to communicate with external systems better. Only push what’s relevant, clean and defined (value per record) for Salesforce or other Target platforms.

  • Archive or purge old, unused data to keep Salesforce lean. This also goes for any technical debt for code (clean, streamline, delete), reports (I’ve seen companies with 100s of Reports they are not using), etc. There should be a process in place that is automated (after 3 months, 9 months, 1 year send X data to X system or delete, etc). For any reports not used in X months - delete. Same with Users, etc.

  • Note: Salesforce is not a data management tool - period. Its meant to manage actionable data. Data that pushes a process forward. Hence the name: Sales (*an action) + Force (action). Keep you org clean and mean.

Change Management:

Changer Management is a big one for Salesforce and it is always on our schedules, RFP responses, strategies for adoption and sustainability of the business.

Align business rules: if sales, field service or service reps need to change customer info, define this by use cases for each role.

  • Use If > Then statements. If X Role need to do X, do X. If Field Service Rep needs to update payment information, can they do it is the first question? If not, have a process supporting this If>Then statement.

  • Have a PROCESS. How do they take in this request of change? You did X, now your doing X - why? In some cases Users will have to do more work (ex. paper sheets to digital in the field) but show the value and future of the industry.

  • Show them the SAP workflows (what is editable in SF vs SAP) so they can see the entire process lifecycle and understand where their information goes. In other words,

  • Explain the BIG PICTURE.

This has all been very high level and there are many exciting areas to talk about here which I will be discussing in future articles.

Ian Moore
Next

8 AI Terms I Love (part 1)