In Part One: Best Practices in Cloud Integrations of our article series “Best Practices of Integrating Salesforce and Microsoft Dynamics 365 Business Central,” we went over a brief introduction of a few different types of integrations that can be used among Business Central, Salesforce, and SmartConnect, how to address potential integration challenges, and what types of data source can be used among the three products.

In this article, we’re going to be focusing on the data strategy behind those integrations.

System Maturity

One of the first things your team needs to consider before integrating data between systems is the system maturity of the environment in which you’re working.

If you’re implementing a Dynamics 365 Business Central system and still training your users and configuring the system, the individual data points of the fields you’re using might not be set in stone. As an example, if you’re trying to build an integration between Business Central and Salesforce, while you’re implementing Business Central and Salesforce, that’s like building a plane while you’re flying it.

While that’s surprisingly possible, it’s definitely not the easiest thing to do, nor do we advise doing so. We always recommend making sure your systems are established, that the users are trained in those systems, that business processes are set, and you’re not having a lot of variability and change in your data (table structure) when you’re thinking about integrating two systems.

Document Entities Needed for Integration

The next thing you want to consider is documenting data for an integration.

You can use whatever tools you like, but plan it out on “paper” first. Do it outside of the system before you ever touch the SmartConnect tool. Consider various factors, like your endpoints—what you’re doing, whether that’s something like sales orders, invoices, or whatever major type of record you want to integrate between the systems. When you get into the individual fields, not all fields between the systems are going to be identical, so you need to work on that translation or interpretation between the two systems.

Data types are one of the most crucial things that get overlooked. The systems are going to look at data differently because they have different data types, and that has to be understood when you’re creating mappings. Otherwise, you can end up with data-type errors as you try to move one type of data from one system to the other which can be difficult to troubleshoot.

As you go through your mapping, identify how that system will represent that data. Is it a text, a date field, an integer, a currency, or something else? Will it smooth out your mapping? You may have to actually do some conversion within your integrations to make that happen, but just be aware of how it can impact things down the stream as well.

For example, if you convert something from one data type to another, think about whether that is going to make reporting more difficult in that destination system.

It’s really important to make sure that data and the desired business process flow between systems is well documented, whether documenting it in Excel or through fancy mapping software. The important thing is to get it documented, agreed upon, and to think through the different steps in the integration.

The 3 V’s of Data

As you’re designing your integrations, we highly recommend factoring in what we call “the 3 Vs of data”—volume, velocity, and variability.

  • Volume: How much data you have to integrate. This is necessary when you’re considering how long it’s going to take for the records to integrate into another system.
  • Velocity: How quickly you need this data to show up in the integration system.
  • Variability: How varied your data is. This could also potentially indicate how many different endpoints you’re integrating with and how broad your integration design is.

An example to describe these different factors would be the difference between financial transactions and e-commerce transactions.

As you’re designing your integrations (and to the extent you’re able), try to consider “the 3 Vs” to help you determine how much you need to optimize your integration design.

Technical Readiness

Once you have the data ready, you need to ensure you’re ready as an organization or as partners assisting integration implementations. Think of the integration between Business Central and Salesforce as a stool. Each piece of software is one of the legs on the stool. Business Central is one leg, and SmartConnect.com and Salesforce are the other two. They’re all critical in successfully integrating the solutions. Having technical expertise for all three solutions is critical for the organization to support the integrations going forward.

SmartConnect is extremely user-friendly. Whether you have a background in programming or not, you can build integrations in SmartConnect without needing a bounty of custom development know-how.

Where many people run into the need for technical knowledge is on the Business Central and Salesforce side of things because you have different data to pull from and you might need to manipulate default connectors for one business need or another. It’s helpful to understand…

When planning out an integration, remember to make sure the project has expertise on all three sides. As you’re mapping things out you may have to determine if you have all the data points, and you may stumble upon opportunities you hadn’t previously thought about. That’s where you may have a need for customization. One example we see in some integration designs is the need to add a field for “record type ___ integrated to ERP (or the other system)”, so that the next time the integration runs, a looped process is avoided. That’s just one scenario where an extra field could be needed, depending on the scenario. If customization is necessary or desired, you’ll need to rely on specialized system implementers for each of these products so you can reach your goals.

Some of the customization methods you might run across are AL language for Business Central, SOQL and Apex scripting for Salesforce, or JavaScript for any calculations or scripting within SmartConnect. It’s good to be prepared and know where to find those skills if you need them.

If you do need more advanced skills and your internal team doesn’t have the technical knowledge for these products, take a look at the experts. At eOne Solutions we have an excellent support team for our services. You can also work with consulting firms that have the Salesforce knowledge needed for integrations and to build custom endpoints. 

If you’re the type of organization that likes to be self-sufficient, these are still great products for you. Business Central, SmartConnect, and Salesforce have a ton of accessible information online, plus there are a significant number of online communities and forums focused on all three products. There are also local user groups for both Business Central and Salesforce. For SmartConnect resources, eOne Solutions offers regular D365 Business Central integration bootcamps that you can leverage as well for your organizations.

To learn how you should integrate data between systems, read Part Three: Integration Strategy of this article series, Best Practices of Integrating Salesforce and Microsoft Dynamics 365 Business Central. – Coming Soon!

Contact us at sales@eonesolutions.com or 888 319-3663 to learn more.