This phase of the Salesforce Platform Governance Method focuses on the integration capabilities of the Salesforce platform and the external systems with which your projects intend to integrate.
Overview
Integration is a key capability of the Salesforce platform. It is designed to bring as much customer-related information together in one place as possible. The more you know about your customers, the better you can serve them.
Part of that customer-centric strategy is to provide numerous ways for Salesforce to integrate with any external systems that an enterprise may already have in use. The Salesforce platform is one of the most open platforms available today in terms of integration. With that level of openness comes some work for your organization to govern. Not that you are looking to restrict what your projects do in terms of integrating with external systems, but you will need to understand at a holistic level the flow of data and the connected systems you have.
The Salesforce Platform Governance Method: Phase E
“Integration services are detailed design and implementation services that link application functionality (custom software or package software) and/or data with each other or with the established or planned IT infrastructure. Specific activities might include project planning, project management, detailed design or implementation of application programming interfaces, Web services, or middleware systems.”
—Gartner1
Salesforce Integration Patterns
Pattern | Usage |
|---|---|
Remote Process Invocation – Request and Reply | This pattern is probably the ideal integration technique to use with an external system. Salesforce invokes a process on your external system and waits for that process to complete; the response can then be used to determine success or failure and act accordingly. |
Remote Process Invocation – Fire and Forget | This pattern is useful for integrating with external systems that need to be informed or act as part of a business process, but completion and response are not required. Salesforce can continue to perform the business process regardless of the external systems’ success or failure. |
Batch Data Synchronization | This pattern is useful for sending and receiving large quantities of data that you want to reside in two or more different systems. Each system has its own copy of the data. The data is synchronized on a regular interval, typically daily. |
Remote Call-In | This pattern allows an external system to call a Salesforce process to create and maintain data or perform a process of some sort. You could consider this the opposite of remote process invocation, as the instigation of the interface is triggered by the external system rather than the Salesforce platform. |
UI Update Based on Data Changes | This is a useful integration pattern from an end user’s perspective, where the user interface is automatically refreshed based on data changes. |
Data Virtualization | This pattern allows Salesforce to expose data that is stored externally as if that data were held within the Salesforce platform. It’s useful when large amounts of data sit outside the Salesforce platform and you do not want to duplicate that data within the Salesforce platform using the batch data synchronization pattern. |
The Salesforce integration patterns are a starting point and a neat way to categorize your integration requirements with the Salesforce platform. However, because you can use Apex to integrate with external systems, your projects can create all manner of solutions to meet the nuances of your organization and the systems within it.
The flexibility of the Salesforce platform when it comes to integration makes governance more important than ever. Your governance team will be looking to understand the flow of data from one system to the other, which system owns the data, and, when changes occur to that data, how those changes flow back into the correct systems.
As the patterns suggest, integrations can take many forms; some integrations will be triggered by data changes, while others will be slower data movement–type integrations. Additionally, you could use a few patterns in concert.
It is common that some legacy systems provide a basic integration capability. On several occasions you will find that the batch data synchronization and remote process invocation patterns are used together. For example, when dealing with stock information, the stock is loaded into the Salesforce platform via the batch data synchronization pattern and then stock “status” is updated on the external system using either of the remote process invocation patterns.
What is important is recognizing when integration sprawl is happening—multiple systems all trying to talk to each other with more and more complex coordination requirements and eventually a lack of data integrity. This situation will be harder and more costly to unpick than taking the time to define an integration strategy and standards up front.
Your governance team should be instrumental in defining your organization’s integration strategy and standards and managing the deviations from those standards. There will more than likely be scenarios that challenge the standards in place within your organization because it is unlikely that every system you use will have the capabilities required to meet your standards.
Finally, if your governance team covers more than just the Salesforce platform, they are probably familiar with a much broader range of integration patterns (such as the 65 integration patterns detailed in Gregor Hohpe and Bobby Wool’s book, Enterprise Integration Patterns). If this is the case, your governance team will probably need to provide some degree of translation between your enterprise integration patterns and the Salesforce integration patterns, mainly because your Salesforce capability will have learned the Salesforce approach to integration, driven by the Salesforce training and certifications.
Technologies & Overall Integration Strategy
Phase E: integration - technology & overall integration strategy
Govern the enterprise integration landscape and overall integration strategy, with associated risks, trade-offs, and business and technical considerations
Your governance team will need to govern the overall integration landscape within your organization by using a clearly defined integration strategy. Your strategy will provide the acceptable patterns that your organization can accommodate, and each pattern will come with trade-offs and risks. These trade-offs and risks must be clearly articulated to the business by the project team.
Every time an integration is made between two or more separate systems, you are accepting an intrinsic link between those two or more systems. What happens to one system may influence the other systems integrated with it. Your governance team needs to understand this situation, because simple operational processes such as updates to systems for security patches or simply new releases may have an impact on other integrated systems.
Data Custody – Which system is a custodian of the data? This system is the primary owner of the data and therefore the primary source of “truth” for that data. This is important for the business to know (if they do not know already) because not all integrations offer “instant” interactions, and therefore knowing which system has the most up-to-date view of the data is an important piece of information.
Business Risks – Can the systems being integrated provide the business with the operational resilience required to deliver the business requirements? If the business requires 24/7 access, your project team will need to know if that is achievable by the systems delivering the business processes. Integrating with a system that is offline over the weekend, when the business requires 24/7 access, will not be acceptable to the business.
Technical Standards – Has the project delivered the integration solution in line with your organization’s technical standards? For example, has the project used the organization’s integration solution already in place, such as Salesforce’s MuleSoft or Dell’s Boomi products, because your integration standards require no peer-to-peer integrations?
Integration Patterns Used – Has the project used the appropriate integration pattern(s)? This is sometimes driven by the systems being integrated, but can also be driven by project deadlines where several integration solutions are available, and the project selects the pattern that’s easiest to implement, sometimes presented as a “minimal viable product” approach but tends to remain for the lifetime of the application.
Security Compliance – Security plays a part in practically every aspect of systems design. The Salesforce platform is no exception. Integration between two or more systems requires security consideration: how the systems authenticate, how that authentication is tracked, how data is transmitted, how changes to data are tracked. Your governance team will need to spend some time working with the project to understand how these questions are being tackled.
Your governance team will need to address the preceding items, helping the project team to understand the risks associated with the integration patterns selected. Your project team should provide your governance team with a clear scope or set of requirements that is driving the integration to begin with. This will help your governance team understand what your project team is trying to achieve and assess the project based on those criteria.
One area that is typically overlooked is the quality of the data. Often, the project and business have overlooked that data quality may not be as good as expected. This drives all sorts of integration challenges, especially when one system is controlling the data an end user enters versus receiving data from a system that does not provide such controls.
One example that happens very regularly is using restricted picklists in the Salesforce platform. These are great for controlling the options available for the end user to select. Color is a good example of a picklist. However, your external system may not use a picklist for this information, allowing the end user to enter a color as “free” text. Your integration will be challenged by this simple problem of mapping a free text field with a controlled field in the Salesforce platform.
Another example is a field that is mandatory on the Salesforce platform versus a field that is not mandatory on the external system. Again, this simple problem creates complexity within your integration solution. Your project will have to work with the business to provide a solution for this.
Integration Pattern Risks
Pattern | Risks |
|---|---|
Remote Process Invocation – Request and Reply | Your external system must respond within the Salesforce platform’s timeout limit; otherwise, the process will fail. External calls are subject to Apex synchronous transaction governor limits. Care should be taken that your process stays within those limits. The small timeout values may drive the volume of data that can be transmitted, while variation in data volume may create failures in the process. State management needs to be addressed, where errors on the external system result in transactional integrity on the Salesforce platform. Transaction complexity could become an issue over time. This pattern is particularly useful for simple transactions and not complicated processes. Pay attention to the Salesforce platform’s governor limits, which are easily breached if the integration is not clearly defined. Keep in mind the external systems’ integration capabilities and how they might change over time. For example, a system may support SOAP today, but have a roadmap to move to a RESTful API in the future, retiring the SOAP interface. |
Remote Process Invocation – Fire and Forget | State management needs to be addressed, where errors on the external system result in transactional integrity on the Salesforce platform, made more complex in the “fire and forget” pattern because your two systems are not performing a synchronous process, which means that failures on the external system need to inform the Salesforce platform with information to tie the transactions together (such as an external ID). Pay attention to the Salesforce platform’s governor limits, which are easily breached if the integration is not clearly defined. Keep in mind the external systems’ integration capabilities and how they might change over time. For example, a system may support SOAP today, but have a roadmap to move to a RESTful API in the future, retiring the SOAP interface. |
Batch Data Synchronization | Your batch processes must complete within the batch window. You need to understand the business requirements for system availability. Your batch processes should not execute while you have active users. Pay attention to the Salesforce platform’s governor limits, which are easily breached (such as DML limits) if your project has not considered data volumes and processing times. Batch sizes can help keep your batch processes within the limits but will extend the time for your complete batch to complete. |
Remote Call-In | Your external system must complete within the Salesforce platform’s session timeout limit; otherwise, the process will fail. Keep in mind any SOQL queries also have individual timeout limits. The small timeout values may drive the volume of data that can be transmitted, while variation in data volume may create failures in the process. State management needs to be addressed, where errors on the external system result in transactional integrity on the Salesforce platform. Use external ID to maintain a consistent key between systems. |
UI Update Based on Data Changes | Custom user interfaces are required in Salesforce to implement this pattern, adding technical risk to the project and increased testing requirements. |
Data Virtualization | Your external system must respond within the Salesforce platform’s timeout limit; otherwise, the process will fail. The small timeout values may drive the volume of data that can be transmitted, while variation in data volume may create failures in the process. State management needs to be addressed, where errors on the external system result in transactional integrity on the Salesforce platform. Use external ID to maintain a consistent key between systems. Pay attention to the Salesforce platform’s governor limits, which are easily breached if the integration is not clearly defined. |
Your governance team should pay attention to any trade-offs between the integration patterns and how that marries with the business requirements delivered by the project. There is always a trade-off in every integration pattern, and it is likely that whichever pattern is selected will be not perfect.
Data Consistency – Data is rarely updated in real-time in today’s integration solutions; it is typically too expensive to achieve this. Real-time has morphed into the phrase near-time, where data is updated as quickly as it can be given the processes involved and the communication routes required. This does lead to some degree of data skew between the different systems. The slower the data updates occur, the greater the chance of data skew.
Data Volumes – The quicker you want to have data reflected across different systems, the lower the data volumes should be. Where important status indicators are required between systems, such as stock status, the approach should be to keep the data volume as small as possible. For example, if you are changing the status of a stock item, the data could contain just the stock identifier and the status, rather than any other data that is not really required to maintain stock status.
Data Frequency – The frequency at which data changes can be an issue with regards to the data volumes and consistency. You will not want to create a “chatty” integration solution for data records that change regularly as this will consume your Salesforce platform limits and may not be accommodated by your external system.
Integration Data Requirement Trade-offs
Requirement | Trade-off |
|---|---|
Data Consistency – HIGH | Data Volume – LOW Data Frequency – HIGH |
Data Volume – HIGH | Data Consistency – LOW Data Frequency – LOW |
Data Frequency – HIGH | Data Consistency – HIGH Data Volume – LOW |
Reduce data duplication – Ideally, you should not be duplicating data in multiple systems. This is not always an achievable principle, but one that should always be front of mind. Only duplicate data if it is critical, and then only duplicate data that changes infrequently.
Reduce communication frequency – You do not want to flood your network or your systems with lots of communications. Communications should be kept to a minimum, as highly “chatty” integrations could have a detrimental impact on the systems being integrated since they may not be capable of accommodating the additional workload put upon them.
Reduce peer-to-peer integrations – You want to avoid propagating peer-to-peer integrations. Where you only have a small number of systems within your enterprise, it is unlikely you could justify the expense of an integration solution, but where you have several systems, all needing to share data and integrate processes, you should really consider using an enterprise integration solution.
Govern the data backup/archiving/data warehousing integration strategies
Governing data backup, archiving, and data warehouse integration strategies focuses on the storing of data outside the Salesforce platform and how that is going to happen.
Your project team may not have considered this requirement because most such teams think that your data backup requirements are taken care of by Salesforce. To some degree that is true. Obviously Salesforce is running the Salesforce platform in a manner that delivers the service its customers expect; however, this is different from data backup, archiving, and warehousing at the project or business level.
Your organization may have a data backup, archiving, or warehousing strategy already in place, but this will differ massively from how Salesforce provides for backups of its own services.
Backup, Archiving, and Data Warehousing Strategies
Strategy | Definition |
|---|---|
Data Backup | The solution to store data outside the Salesforce platform for the purposes of recovering data lost inadvertently. This could be due to human error, maliciousness, or defects in coding, configuration, or integration. For example, you create an integration that updated account information that inadvertently updated the wrong fields. |
Data Archiving | The solution to store data outside the Salesforce platform for a period (usually several years) to meet compliance requirements. Typically, the data being archived is removed from the system that the data came from, but this is not always the case. Archiving data can be a great way to retain current information in the Salesforce platform rather than historical data that is no longer relevant to the business but must be retained. |
Data Warehousing | The solution to copy data from the Salesforce platform into another data management platform for the purposes of reporting or business intelligence requirements |
Given the simplified definitions in Table 6-4, your governance team will be looking to identify how the project will integrate with solutions to deliver those requirements out of the box, as the Salesforce platform does not provide built-in integrations for these.
Data Export – A basic solution built into the Salesforce platform that allows the project to export data either “now” or as scheduled. However, the term now does not mean the Salesforce platform will export the data there and then; your project will need to wait for the job to be queued and executed. The project selects the objects in scope for export, and the Salesforce platform will export the contents of those objects. Your project will have 48 hours to retrieve the exported data files, after which time Salesforce will delete them .
Data Loader – An external application for the desktop PC. The application provides various features for data unloading and loading. The added attraction of this application is that you can use filters, which means you can be more selective over the data retrieved. The data is saved directly onto your desktop PC in a character-separated-values file format.
It is obvious to see that the solutions offered by Salesforce for data backup require some level of manual intervention and probably lack the capabilities that most businesses require for a robust data backup solution. However, they are good enough for a growing enterprise to start with.
As the solutions offered by Salesforce are quite basic, the levels of integration are basic too. However, your project may be looking to introduce a more robust solution for data backup, archiving, and data warehouse.
Use the Salesforce APIs.
Use a third-party solution specifically designed for the Salesforce platform.
Your project team may have the capability to develop its own solution using the Salesforce APIs, and your governance team will need to govern this solution as they would any other application developed on the Salesforce platform.
Using a third-party solution offers a pre-built answer to your backup and archiving needs. Generally, data warehousing can occur from the data that is backed up, as you have already extracted the data; tacking this into a data warehouse solution has no impact on the Salesforce platform .
Govern whether the appropriate integration strategy and standard integration patterns have been used
Where possible, your governance team must ensure that your projects have kept to the standards. For the Salesforce platform, the standard integration patterns help with that. Each pattern provides several different approaches that the platform supports.
Your governance team should make itself familiar with these patterns or utilize expertise from elsewhere, such as offer projects or even Salesforce advisory services, to effectively govern the project’s use of the relevant integration patterns.
There will be situations where a project has had to integrate with an system external to the Salesforce platform that does not provide the facilities to cleanly use a standard Salesforce feature to integrate. In the main, though, even those outlying situations can be categorized into one of the standard Salesforce integration patterns. However, your governance team will need to have a dispensation process that allows projects to create a bespoke integration via Apex or alternative that works for the business requirement. The dispensation should be offered for a period, after which a review should happen to determine if the solution selected is still the only approach available.
Throughout the lifecycle of an application, it is more than likely that your organization will see its IT landscape change, so the dispensation approach allows everyone to revisit non-standard or out-of-policy solutions regularly and determine whether anything has changed within your IT landscape that could offer alternatives.
Verify what data needs to exist within the Salesforce platform.
Understand which external system that data will come from.
Decide on the frequency at which the data will arrive within the Salesforce platform from the external system.
Configure the data model within the Salesforce platform to receive the external system’s data.
Control access to fields that are specific to managing the integration, and use external IDs if possible.
Govern the integration components involved in a flow and consider transaction management and error and exception handling
Flows offer a declarative solution to develop complex processes. In some way, flows are very close to the principles of developing a program in Apex, as they offer many of the constructs you would expect to develop using Apex.
Platform Events
External Objects
Custom Lightning Components
Enhanced External Services
Apex
Integration Considerations from Flow
Option | Server Side | Client Side | Synchronous | Asynchronous |
|---|---|---|---|---|
Platform Events | Yes | No | No | Yes |
External Objects | Yes | No | Yes | No |
Custom Lightning Components | No | Yes | Yes | Yes |
Enhanced External Services | Yes | No | Yes | No |
Apex | Yes | No | Yes | Yes |
There are two main areas here to consider for your governance team that may be something that has been overlooked by the project team.
Firstly, server side versus client side. This may be obvious to some, but basically you are deciding whether the integration executes from your desktop/laptop PC via the browser for client side, or from the server side (i.e., within Salesforce’s data centers). The only technical solution that offers client-side integration is the Lightning components (whether traditional [Aura] Lightning components or more modern [JavaScript] Lightning Web components). The important matter here from a governance perspective is that the performance and reliability aspects shift.
For client-side solutions, your organization is very much responsible for making sure that the browser deployed to your desktop/laptop PC runs consistently for all users across all usage scenarios. For example, if you have users who can access your Salesforce instance via VPN from a café using their three-year-old laptop, then that experience may differ from a user sitting in your main office on your internal network using the latest laptop offered by your organization. This basically means that your external system needs to be more tolerant of transaction timelines as they will be affected by the network and compute performance of whatever device the client-side integration is executing upon.
For server-side solutions, your organization relies upon Salesforce to execute the integration in a timely manner. You are less concerned with network bandwidth (as that too is Salesforce’s problem). Your laptop/desktop PC performance is not so important because it does not execute the integration. However, server side is consuming limits on the Salesforce platform, so you have a trade-off to consider.
Secondly, synchronous versus asynchronous. This basically decides whether the execution of your integration “blocks” the execution of your flow (i.e., the flow must wait for the integration to complete) or the integration is “non-blocking,” allowing your flow to continue to execute while the integration executes independently. These are important factors to consider from a governance perspective, as you may have to implement additional transactional controls to correct any asynchronous processes that fail.
Integration Solution Tools
Phase E: integration - integration solution tools
Govern the use of the appropriate platform-specific integration technology for integration with external systems
Once your project team has learned the types of integration that are needed to meet the business requirements, it will have several choices to make regarding the technology available to them.
The Salesforce platform, as you would expect, offers a few technologies that can be used to deliver the integration patterns described earlier. Although some might say there are no wrong approaches, there are some that will deliver the desired outcome better than others.
The following describes the integration technologies available to your projects and whether the technology is optimal for the integration pattern. Although Salesforce provides a more conservative view on what is acceptable, your governance team should take a harder view, simply because any compromise drives workload later on in the application’s lifespan, and it is worth tracking any integration that was not optimal.
Remote Process Invocation – Request and Reply
Enhanced external services (optimal)
Lightning component initiating an Apex SOAP or REST callout synchronously (optimal)
Visualforce page initiating an Apex HTTP callout synchronously (optimal)
Trigger that is invoked by Salesforce platform data changes initiating an Apex SOAP or HTTP callout synchronously (suboptimal)
Batch Apex initiating an Apex SOAP or HTTP callout synchronously (suboptimal)
Your governance team is looking to make sure the project has considered the limits associated with each technology listed as well as considered potential failure conditions, such as timeouts and errors. Additionally, transactional integrity should be considered by the project team in the event of those failure conditions.
The actual technical approach will be controlled by the capability of the external system, but your governance team must determine whether the best approach has been taken given those external system limitations. A few technical solutions proposed are suboptimal, and therefore should be used with caution as there is usually a high number of trade-offs and restrictions.
Remote Process Invocation – Fire and Forget
Process-driven platform events (optimal)
Customization-driven platform events (suboptimal)
Workflow-driven outbound messaging (suboptimal)
Outbound messaging and call-backs (suboptimal)
Lightning component initiating an Apex SOAP or HTTP callout asynchronously (suboptimal)
Trigger that is invoked by Salesforce platform data changes initiating an Apex SOAP or HTTP callout asynchronously (suboptimal)
Batch Apex initiating an Apex SOAP or HTTP callout asynchronously (suboptimal)
There are a few options for the Remote Process Invocation – Fire and Forget integration pattern, and your governance team may need to be considerate of the capabilities of the external system in terms of trying to coordinate transactions via error or failure scenarios. It may be that the best the project can achieve is a batch integration using Apex, with very little idea as to whether the data made it to the external system’s data stores or not.
However, your governance team is always going to be looking to the project team to achieve the best outcome given the constraints of all systems.
Batch Data Synchronization
Change data capture (optimal)
Data replication using bulk API (optimal)
Data replication using non-bulk API (suboptimal)
Remote call-in (suboptimal)
Remote process invocation (suboptimal)
Any integration for large amounts of data that does not use one of Salesforce’s solutions built specifically for that purpose is going to be suboptimal. Your governance team will need to understand the drivers behind any suboptimal integration patterns chosen by your project.
There are a few reasons that your governance team should encourage alternatives, mainly for consumption of platform limits and the number of records being changed. Your project’s use cases will vary, of course, so there may be good reason to perform a record-level data replication integration. However, your governance team should raise the potential problems this could cause and have the project team discuss the mitigations they have.
Remote Call-in
SOAP API (optimal)
REST API (optimal)
Apex web services (suboptimal)
Apex REST services (suboptimal)
Bulk API (optimal for bulk operations)
Your project may have the requirement to provide a method for your external systems to make a call into the Salesforce platform to retrieve data. There are many reasons for this to occur, but mainly a call-in denotes the Salesforce platform as the primary owner of the data being requested.
Out of the box, the Salesforce platform exposes its objects, standards, or customers via a REST interface. This is the most simplistic solution to supporting call-in integrations. However, if more complex processing is required before the data being requested is ready—for example, the data needs to be reformatted into a particular structure—then Apex REST services could be the right option. However, your governance team will need to subject the project to further governance phases to support the Apex coding introduction.
UI Update Based on Data Changes
Streaming API (optimal)
There will be a few programmatic elements to this integration solution; therefore, your governance team will need to review this not only from an integration perspective, but also from a code quality perspective.
Data Virtualization
Salesforce Connect (optimal)
Apex web services (suboptimal)
Apex REST services (suboptimal)
Your governance team must make sure the project team understands the implications of data virtualization. On the surface this can be a very straightforward solution to implement, especially if Salesforce Connect is suitable. However, the project team should be confident that they have understood any longer-term implications around the data’s being virtualized and where that data resides currently. Will this data be available for the lifespan of the application the project is building? Will the data format remain consistent for the lifespan of the application that the project is building? Additionally, where Salesforce Connect is being used, it may be prudent to understand Salesforce’s longer-term support for the connector you are planning to use.
Govern the usage of the Lightning platform integration APIs and features and determine whether they have been appropriately used
Salesforce offers many APIs, and as previously mentioned some are more suited than others to specific integration patterns.
Your governance team will need to address any areas where your project team has overstepped the intended capability of any given Salesforce platform API; for example, using a Lightning component to integrate with an external system to extract large volumes of data.
The example given may sound silly to some, but this does happen. Not everyone who creates applications or configurations for the Salesforce platform has the right level of knowledge to tackle the task at hand. Even large system integrators do not always have the most experienced resources working on your projects. It is always worth checking.
Security
Phase E: integration - security
Govern how security requirements are met at each of the integration layers
Security is a paramount consideration in any application development or configuration on the Salesforce platform. Your data is an important part of your organization, and as such you will want to make sure it is safe and secure. Previous phases of the Salesforce Platform Governance Method tackled the broader security and data access governance, but your governance team will need to apply some of the thinking from those previous phases into this phase.
The main difference that your governance team will need to consider when applying security to an integration is making sure that security is considered and applied at all levels of your project’s integration.
Authentication – Your governance team will need to make sure that your integration has implemented the proper authentication solution. In most cases this will require credentials of some sort to be passed from the external system to the Salesforce platform to allow further communications to occur.
Data Access – Your governance team will need to provide the right level of access to the external system that is integrating with the Salesforce platform. This should not be a broad full-access grant, but something that is tailored for the specific use case of the integration.
Data Transmission – Your governance team will need to make sure that any data transmissions from the external system to the Salesforce platform are done using the proper encryption. Remember that the Salesforce platform is an SaaS product accessible from anywhere in the world.
Traceability – Your governance team will need to make sure that any changes made to data by the external system integrating to the Salesforce platform are logged or traceable in some way so that it is clear what has changed and when.
As with any security requirements, the credentials used to allow communications from one system to another should be controlled and maintained just like any other access to your systems. Therefore, your governance team will want to learn from the project team how the credentials used to authenticate the external system with the Salesforce platform are maintained in line with your organization’s security policies; for example, password change requirements.
Your governance team will need to consider the integration and the capabilities of the external system or platform. If your project is extracting data from the Salesforce platform to store elsewhere for further processes, that data should be secured.
It can be very easy to overlook data security once the data leaves the Salesforce platform. One example that is constantly arising is the extraction of data for the purposes of business intelligence. That data being extracted from the Salesforce platform and moved into a database of some kind has a very open access policy.
Method
Technologies and Overall Integration Strategy
Integration Solution Tools
Security
Approach
This phase is focused on governing the integration aspects of an application or configuration. You may have integration strategy and standards already defined within your organization, which should be applied to your Salesforce platform implementation as well. Alternatively, the design patterns provided by Salesforce cover the main use cases you are likely to come across if you do not have these already defined.
Your project team could present you with Apex source code as part of its integration solution, so your governance team will need to inform the project team that it is subject to subsequent governance phases because of this.
Ultimately, integration can be a complex and difficult part of any project. On the surface the integration may sound straightforward, but very often an integration becomes complex very quickly or compromises must be made to accommodate the capabilities of both sides of the integration. It is likely that some incompatibility will arise that will drive these compromises.
Your governance team should pay close attention to security throughout its assessment of the project’s application or configuration. Security is often only considered from one perspective during the integration. Your governance team should take a holistic view of how security will be applied, perhaps looking at the lifecycle of the data that the integration is focused on to provide a level of assurance that security has been applied consistently across the entire integration requirement.
Your governance team will need to be sympathetic toward any deviation from the standard policy or best practice within your organization if that deviation is driven by lack of capability in the systems involved. The business should drive the requirement, but also carry the risk associated with any suboptimal approaches taken. Your governance team should highlight this to the business sponsors of the project under governance to make sure that although the project team has done everything it can to provide the best possible integration, any suboptimal areas are accepted as business risk.
Inputs
Application configuration and source (or the repository in the instance of using a source control system) where appropriate
Integration architecture, detailing the systems involved and the flow of data
Security policy (if defined by the project)
Clear definitions around sensitive data
Steps
The steps to govern the integration will help the project team understand how its application and ultimately the Salesforce platform will participate in any integrations with external systems. Your governance team is looking not only to protect the assets of your company, especially the data, but also to protect the holistic view of data integrity across all systems deployed within your organization.
Technologies and Overall Integration Strategy
- 1.
Govern the enterprise integration landscape and overall integration strategy, with associated risks, trade-offs, and business and technical considerations
- 2.
Govern the data backup / archiving / data warehousing integration strategies
- 3.
Govern whether the appropriate integration strategy and standard integration patterns have been used
- 4.
Govern the integration components involved in a flow and consider transaction management and error and exception handling
Integration Solution Tools
- 1.
Govern the usage of the appropriate platform-specific integration technology for integration with external systems
- 2.
Govern the usage of the Lightning platform integration APIs and features and determine whether they have been appropriately used
Security
- 1.
Govern how security requirements are met at each of the integration layers
Outputs
Not Applicable – This phase in the Salesforce Platform Governance Method is not applicable to the project.
Remediate – The governance team requests that the project team remediates its design to accommodate the issues raised during the governance review.
Pass – The governance team has found no issues or concerns with the project’s proposal and therefore the project has passed this governance phase.
Review – The governance team has found the inputs cannot be objectively measured and therefore a subjective view has been made, which will lead to a discussion with the project team to reach consensus. Although undesirable, this could be a consequence of unclear standards/policies.
Scenario
Govern the enterprise integration landscape and overall integration strategy, with associated risks, trade-offs, and business and technical considerations
Govern whether the appropriate integration strategy and standard integration patterns have been used
Bright Sound Guitars integration architecture
Hanna has worked with her developers, Ranveer Shah and Caitlyn Horton, to tackle the suggestions raised during that previous governance session. Hanna is now ready to present to the governance team a more detailed view of her integration between the Salesforce platform and the Stock Control System.
Bright Sound Guitars detailed integration architecture
Hanna introduces Caitlyn to the governance team so that Caitlyn can talk the team through her solution.
The stock control system only supports one API to retrieve stock. Caitlyn needs the stock to be within the Salesforce platform so that the business can perform an end-to-end sales process. She will update the Product2 object with the stock from the stock control system, enhancing that object to contain a field that holds the external ID used by the stock control system. That way, any changes to the stock can be reflected accurately with the Salesforce platform.
As Caitlyn will need to update the price book for any new products added, and the fact that she needs to do some basic manipulation and verification of the data being received from the stock control system, she will implement this integration using Apex.
The API for the current stock from the stock control system provides several stock items per page. Caitlyn will need to call the API for each page of stock, incrementing the page she needs until she reaches the final page of stock. She then knows she has all the stock available. However, Caitlyn does not know how many pages of stock are available until she makes the first API call for the first page. The returned payload provides an attribute that provides the total number of pages. Therefore, Caitlyn suggests having an Apex function that always attempts a retrieval of the first page from the stock control system’s API so that she knows up front how many times she will call the API. She needs to know this to optimize her batch processes and recursion to retrieve all stock.
Finally, Caitlyn suggests that she can trigger an update to the stock control system via a trigger on the Salesforce platform so that the business can deactivate products when they know they are no longer for sale rather than use the external system to perform the same function.
Bright Sound Guitars integration design
A batch process that is scheduled and retrieves all the stock from the stock control system each night, updating the Salesforce platform
An action that she wants to add into the Salesforce platform’s user interface so that a manual stock transfer can occur
A trigger that will update a specific item within the stock control system when its status is changed on the Salesforce platform
Caitlyn will develop a few Apex classes to support the features she wants, plus use a few other Salesforce platform technologies to support the button she wants to add to the user interface and custom fields she needs. Caitlyn wants to contain all the Apex callouts within one class so that maintenance is easier in the longer term.
The batch process could be difficult to control in terms of knowing how many times it will need to call out to the stock control system. As this is a limitation of the stock control system, they understand that Caitlyn has done the best she can. However, they highlight that Caitlyn will need to make sure that she considers the DML statements and call-out sequence, as well as “bulkify” as much as possible so that multiple statements are being recursively used.
The open-endedness of the stock synchronization will make it difficult to determine the batch window needed to complete a stock transfer, so the governance team recommends that Hanna and Caitlyn look at the current stock records within the stock control system to model this. Also, filtering out any unwanted records from the stock control system that are not relevant to the Salesforce platform would be beneficial.
The governance team can see that all communications with the stock control system are initiated from the Salesforce platform. They like the fact that the control sits within the Salesforce platform to determine the appropriate time to perform a stock synchronization. However, they mention to Hanna that she may need to review the availability of the stock control system to make sure her project is not attempting a stock synchronization during a time when the stock control system is not available.
Finally, the governance team mentions that the business should be made aware that the stock will only be updated on a nightly basis and therefore they are trading off data volume against data consistency. It could be that when Bright Sound Guitars performs its monthly stock updates, these might not be immediately available within the Salesforce platform, although the governance team acknowledges that Caitlyn is going to develop a manual option for stock synchronization.
Overall, the governance team is happy with what they have been presented by the project team and thank Hanna and Caitlyn for a job well done. They feel comfortable that once the comments have been addressed the project team will be able to progress in its development.
Summary
Phase E tackles the governance of a project’s integration solutions, from architecture design through to implementation. Having completed this governance phase, you have checked that the project has adhered to the standard integration patterns, considered security, and accepted the trade-offs associated with each integration pattern. Additionally, you have learned the limitations of any external systems and how these limitations have to be overcome to meet the business requirements.
You have highlighted to your project team any areas of concern within the integration solution and are confident that the team will remediate your concerns.