Best Practices for Salesforce Integration Architecture in the Public Sector

Best Practices for Salesforce Integration Architecture in the Public Sector

Table of Contents

Integrating Salesforce with other platforms is a common use case; common enough that certain high profile individuals in the industry state that not integrating your CRM is like working with your hands tied behind your back.

Given how common it is, there are tons of posts, videos, help articles, and a comprehensive trailhead certification track that can get you up to speed. While any run-of-the-mill technical architect can pick and design the proper way to join Salesforce with any other tool, the use cases within the Public Sector is where this post will go.

You may be wondering why a different vertical would change a design pattern for  integrating the Salesforce Core Platform (as Sales, Service, and Experience is usually used everywhere!); the key here is compliance. As mentioned in our previous blogs, Public Sector users typically require a level of compliance that necessitates implementation of security controls and/or operating on the Salesforce Government Cloud platform (or both).

These controls can be stood up as configuration, development, or strictly organizational policy in operating on the Salesforce platform. That organizational policy has the impact of filtering down why certain integration approaches can be used with Salesforce in order to prevent spillage or non-compliant design. 

Let’s first talk about some typical integration approaches you would find across Salesforce Core, in general, just to set the stage:

Pre-Built Connectors

A lot of platforms have connectors that can be found on the AppExchange or within the product catalog for tools being integrated with. This method is typically the most widely used (and should be) but the use cases with which the connector can support are discrete and typically immutable. There may be a cost associated with the use of the connector or it may be free with licensing for the non-Salesforce application. Note that behind the scenes, the connector likely uses a Point-to-Point integration or Middleware application to integrate but this is obfuscated from the user.

Middleware-Based Integration

Platforms like MuleSoft, Boomi, Workato sit between platforms and can be rolled out to the entire enterprise to support integrating other applications together. These platforms are powerful and require build and maintenance going forward by a knowledgeable team member or vendor to support. These applications are typically much quicker to build and scale integrations and keep them consistent beyond even Salesforce.

Point-to-Point Integration

This works well for simple, direct connections between two systems, but becomes cumbersome as an organization scales. There are a bazillion different ways to do a point to point integration but this is typically where users land to get time constraints to meet halfway with costs, and there is either a systems integrator in the mix or someone with a developer skill set exists within the organization. Most platforms have an exposed set of standard APIs or capabilities to extend the APIs (which Salesforce has both), so this method is building the logic into either the source or the target platform to get the job done. 

Common Integration Approaches with Compliance as a Key Factor

Given these approaches (and there are a lot of tactical approaches that can fit inside each of these) we should have a rough idea of when we would want to choose one over the other. Weighing the pros and cons should consider team composition, bandwidth, team skill set, cost, and scalability needs before making a decision. For Public Sector or Government Cloud use cases, there is a consideration for the level of compliance needed which really changes how we make these decisions. Each of the approaches now can be seen in a different light:

Pre-Built Connectors

Given that the connectors are built by the platform companies themselves (or sometimes Salesforce), the level of compliance that the connector has, comes into question. Answering that question is difficult because the connector is purposely shrouded or hidden from its users or even sometimes a trade secret.

This is a problem for compliance because how do I know that the data being integrated between Salesforce and the other platform is not taking a pit-stop somewhere undesirable? Also, geographically, do I know what countries the physical devices are in that store this data?

Unless stated and proven as compliant to a certain certification level, the assumption is that handing your data over for these connectors to use, is putting your data and organization at risk.

Middleware-Based Integration

This reveals the same questions that come up for the Pre-Built Connectors: do these middleware platforms store data within their platform? Well in most cases they probably have to, so then do these middleware platforms store this data on United States soil? If the answer is maybe, we risk compliance to implement it this way and could be a non-starter.

Most products like these have a direct and clear stance on their level of compliance and typically have a product line dedicated to Public Sector or Government compliance.

If they do not have that compliant product (or don’t document their level of compliance), it is not worth the risk to implement. For example, products like MuleSoft or Boomi do have US Government compliant applications whereas as of this writing, Workato does not. 

Point-to-Point Integration

While this option is typically avoided strategically, with compliance as a priority criteria, this becomes much more alluring. The reason being is that we are not storing data in transit for this solution, meaning we do not have to worry about the inner workings of a separate application like we do for a connector or middleware-based option.

However, when pursuing this option, since we have more creative control over how the integration is built, we have to still adhere to best practices which include the compliance factor. If Salesforce were to be integrated with a non-compliant or out of boundary system, providing the ability for that other application to access administrator level capabilities within Salesforce would be a drastic oversight.

Tactical methods should always make sure that in-boundary or compliant systems do not yield management to out of boundary systems. 

A Shift in Mindset

So as we can see, in promoting compliance to the pinnacle factor in building the integration the desirable approaches seem to flip on their head. That doesn’t mean that we are unable to use a connector or middle-ware to integrate, it just means that our evaluation of the options and approaches require a shift in mindset. At Vectr Solutions, that mindset shift is a natural part of our implementations; we know the tools (and architecture) to make implementations go smoothly. 

Let Vectr Solutions Optimize Your Public Sector Salesforce Integration

Vectr Solutions specializes in designing and implementing secure, scalable Salesforce integration architectures tailored to government agencies and contractors. Our team of Salesforce Certified Integration Architects ensures that your organization achieves mission efficiency, data integrity, and long-term compliance. Whether you need to integrate legacy systems, streamline multi-org environments, or implement real-time data synchronization, Vectr Solutions has the expertise to deliver a seamless solution.

Connect with our experts today: Contact Vectr Solutions.

Author

Salesforce Blog

Case Studies