Salesforce Integration: Architectural Principles for Seamless Third-Party Connectivity

Salesforce can be integrated with various third-party applications. This integration can help businesses to streamline their workflows, automate tasks, and gain a complete view of their customers.

When integrating Salesforce with third-party applications, it is essential to consider the following architectural principles:

Patterns

1. Remote Process Invocation — Request and Reply: A pattern for synchronous communication where a client sends a request and waits for a response from a remote service.
2. Remote Process Invocation — Fire and Forget: A pattern for asynchronous communication where a client sends a request to a remote service but doesn’t wait for or expect a response.
3. Batch Data Synchronisation: A pattern for periodically updating data in bulk between systems, typically in scheduled intervals.
4. Remote Call-In: A pattern where external systems initiate calls to internal services for specific functionality.
5. UI Update Based on Data Changes: A pattern that automatically updates the user interface in response to data changes, often through real-time notifications or event-driven mechanisms.
6. Data Virtualisation: A pattern for abstracting and presenting data from various sources as a unified, virtualised data source, simplifying access and integration.

Layer

An integration layer is a component within a software architecture that facilitates the seamless exchange of data and functionality between different systems or software applications. It acts as a bridge or intermediary, enabling disparate systems to communicate and work together by translating, transforming, and routing data or requests between them. Integration layers are essential for creating cohesive and interconnected software ecosystems, allowing organisations to streamline processes, improve data consistency, and enhance overall system interoperability. Different types of layer:

1. Security Layer: Manages access control, authentication, and data protection to ensure the system’s safety and integrity.
2. User Interface Layer: Provides the visual and interactive elements through which users interact with the application.
3. Business Logic Layer: Implements the core application logic and rules that drive the functionality and operations.
4. Data Layer: Deals with data storage, retrieval, and management, ensuring the persistence and availability of data for the application.

Timing

Timing refers to the coordination and order of events in a system, determining when specific actions or processes occur.

1. Synchronous Timing: In synchronous timing, events or processes occur in a predetermined order and are closely synchronised, often in a lockstep manner, where one process waits for the other to complete before proceeding.
2. Asynchronous Timing: Asynchronous timing involves events or processes that can occur independently and without strict synchronisation, allowing multiple actions to proceed concurrently or with varying timing.

Direction

Direction in integration refers to the flow of data or requests between Salesforce and a remote system, indicating whether data is moving from Salesforce to the remote system or vice versa.

Types of Integration Direction:

1. Salesforce to Remote System: In this direction, data or requests originate in Salesforce and are transmitted to a remote system for processing or storage.
2. Remote System to Salesforce: In this direction, data or requests originate in a remote system and are transmitted to Salesforce, where they are processed or integrated into the Salesforce environment.

Volume

In the context of computing and data management, “volume” refers to the quantity or size of data or the scale of operations within a given system.

Small Data Volumes: Small data volumes typically refer to a relatively limited amount of data that can be easily managed, processed, and stored within the capabilities of a system.

Large Data Volumes (LDV) or Unknown: Large data volumes represent a significant quantity of data that may challenge traditional system resources. The “unknown” category encompasses scenarios where data quantities are unspecified or fluctuate, potentially exceeding known limits.

Other Limits (Governor Limits, API Callout Limits, Bulk API Limits): In addition to data volume, these other limits, such as governor limits that restrict the resources used by a process, API callout limits governing external system interactions, and Bulk API limits for handling large data loads, are important constraints within a computing environment.

Here are some examples of how Salesforce can be integrated with third-party applications:

Salesforce Integration Patterns for Petstar Ltd.: A Comprehensive Guide

Petstar Ltd., a thriving organisation specialising in various services, has an intricate web of systems that play crucial roles in their day-to-day operations. With Salesforce as the central hub for their sales processes, ensuring a seamless flow of data and operations across various platforms is imperative. Let’s delve into integration patterns to address specific scenarios Petstar Ltd. faces, providing detailed insights on optimising their operations.

Scenario Husky: Synchronising Salesforce and ERP

Challenge: When a new account is created or existing ones are updated in Salesforce, it must be accurately mirrored in the ERP system. Furthermore, the ERP account ID should be stored as an external field on the corresponding Salesforce record.

Recommendation:

• Pattern — Remote Process Invocation — Fire and Forget: This pattern allows for asynchronous communication, making it suitable for cases where the response time or acknowledgment from the remote system may vary or isn’t crucial. It’s well-suited for scenarios where you want to initiate a process in the remote system but don’t need to wait for an immediate response.
• Layer — Business Logic: The integration should occur within the business logic layer, which can handle the initiation of the integration process without impacting the user interface or the overall system.
• Timing — Asynchronous: Asynchronous communication is appropriate because it decouples the Salesforce system from the remote system, enabling Salesforce to continue its operations without being blocked by the remote system’s response time.
• Direction — Salesforce -> Remote System: This direction implies that Salesforce is the initiator, and it sends data to the remote system without waiting for a reply, aligning with the “Fire and Forget” nature of the integration.
• Volume — Unknown: Given the unknown data volume, an asynchronous approach is more flexible and can handle varying data quantities without affecting the performance of the Salesforce system.

By implementing the “Remote Process Invocation — Fire and Forget” pattern within the business logic layer with asynchronous communication, you can efficiently transmit account data from Salesforce to the remote system, even when dealing with an unknown volume of data. This approach ensures that Salesforce can continue its operations without being held up by the remote system’s response, making it a robust and flexible solution for Scenario Husky.

Scenario Kelpie: Real-time Case Management

Challenge: Petstar relies on a legacy application for case management, and executives must be able to close all related cases in real time before deactivating or closing an account directly from the account page.

Recommendation:

• Pattern — Remote Process Invocation — Request and Reply: This pattern allows for synchronous communication and is appropriate when immediate responses are needed, as in this scenario where executives require real-time case management capabilities.
• Layer — Security; Business Logic: Implementing this pattern, involving sensitive operations like closing cases, should be conducted in the security layer to ensure proper access control and in the business logic layer to handle the operation’s core functionality.
• Timing — Synchronous: Synchronous communication is essential in this case because it ensures that executives receive immediate feedback and can close related cases before deactivating an account.
• Direction — Salesforce -> Remote System: In this scenario, the request is initiated from Salesforce, and the response is expected from the remote system, aligning with the “Request and Reply” nature of the integration.
• Volume — Small: With a small data volume, the synchronous “Request and Reply” pattern ensures real-time response and provides executives with the ability to manage related cases without delay.

By implementing the “Remote Process Invocation — Request and Reply” pattern within the security and business logic layers with synchronous communication, you can ensure that executives receive immediate responses when closing related cases in Salesforce. This approach aligns with the requirements of Scenario Kelpie and ensures efficient real-time case management for small data volumes.

Scenario Labrador: Synchronising Billing Data

Challenge: The ERP system calculates essential account status and billing-related attributes. These attributes must be accurately stored on the Account object in Salesforce and synchronised whenever they change.

Recommendation:

• Pattern — Remote Call-In: The “Remote Call-In” pattern is well-suited for situations where external systems, in this case, the ERP system, need to initiate calls to Salesforce for specific functionality. This pattern allows the remote system to update data in Salesforce when changes occur.
• Layer — Security; Business Logic: This pattern should be implemented within the security layer to ensure proper access control and in the business logic layer to handle the processing and updating of account status and billing attributes.
• Timing — Both: The “Remote Call-In” pattern supports both synchronous and asynchronous communication. Synchronous communication can be used when immediate updates are needed, and asynchronous communication can be employed for less time-sensitive updates.
• Direction — Remote System -> Salesforce: In this scenario, the ERP system is the initiator, pushing updates to Salesforce when account status and billing attributes change, making the “Remote Call-In” pattern appropriate.
• Volume — Unknown: Given the unknown data volume, the “Remote Call-In” pattern offers flexibility and allows updates to be pushed from the remote system to Salesforce without imposing strict volume limitations.

By implementing the “Remote Call-In” pattern within the security and business logic layers with both synchronous and asynchronous timing, you can ensure that the ERP system can update account status and billing attributes in Salesforce as needed, even in scenarios with an unknown data volume. This approach accommodates the real-time or batch updates required in Scenario Labrador.

Scenario Retriever: Archiving Documents

Challenge: Documents older than one month and stored in Salesforce must be systematically transferred to the Content Management System.

Recommendation:

• Pattern — Batch Data Synchronisation: The “Batch Data Synchronisation” pattern is ideal for scenarios where data needs to be periodically transferred between systems in batch processes, making it well-suited for archiving older documents.
• Layer — Data: This pattern should be primarily implemented within the data layer, as it involves the transfer and synchronisation of data between systems.
• Timing — Asynchronous: Asynchronous timing is suitable for this scenario, as it allows the periodic and systematic transfer of documents without the need for real-time responses.
• Direction — Remote System -> Salesforce: In this context, the direction is from the remote Content Management System to Salesforce, enabling the systematic transfer of documents to the Content Management System.
• Volume — Unknown: Given the unknown data volume, the “Batch Data Synchronisation” pattern is flexible and can handle varying quantities of data without affecting system performance.

By implementing the “Batch Data Synchronisation” pattern within the data layer with asynchronous timing and data transfer direction from the remote system to Salesforce, you can systematically and efficiently archive older documents from Salesforce to the Content Management System, even when dealing with an unknown data volume. This approach streamlines the document archiving process in Scenario Retriever.

Scenario Sighthound: Unified Subscription Information

Challenge: Displaying subscription information on the Account record page is essential and needs to be sourced from multiple platforms. For young accounts, subscription information is stored in the ERP, while older accounts’ data resides in a legacy system. Non-subscription payment information should be displayed seamlessly without requiring page refreshes.

Recommendation:

• Pattern — Data Virtualisation: The “Data Virtualisation” pattern allows data from various sources to be presented as a unified, virtualised data source, simplifying access and integration. It’s ideal for displaying data from multiple sources on a single page.
• Layer — Data: This pattern should be implemented primarily within the data layer, as it involves the integration and presentation of data from multiple sources.
• Timing — Synchronous: Synchronous communication is appropriate, as the data should be displayed on the Account record page in real time without delays.
• Direction — Salesforce -> Remote System: In this scenario, data is fetched from the remote systems and presented within Salesforce, aligning with the “Data Virtualisation” pattern.
• Volume — Small: With a small data volume, synchronous data virtualisation ensures real-time data presentation without performance concerns.

By implementing the “Data Virtualisation” pattern within the data layer with synchronous timing and data retrieval direction from Salesforce to remote systems, you can seamlessly display subscription information from multiple sources on the Account record page, providing a unified and real-time user experience for small data volumes in Scenario Sighthound. This approach ensures that executives have immediate access to relevant subscription data.

Scenario Swiss Shepherd: Marketing Campaign Management

Challenge: Marketing campaigns run from a legacy application and must be visible on account record pages. Executives require the capability to create specific marketing campaigns for groups related to their accounts.

Recommendation:

• Pattern — UI Update Based on Data Changes: This pattern ensures that the user interface is updated in response to data changes, making it suitable for real-time updates of marketing campaigns on account record pages and for enabling executives to create campaigns.
• Layer — Data: Implementation should primarily occur in the data layer, as it involves monitoring data changes and triggering UI updates based on these changes.
• Timing — Asynchronous: Asynchronous timing is appropriate, as data changes should be monitored and reflected in the UI without causing delays or blocking the user interface.
• Direction — Salesforce -> Remote System: In this scenario, data changes in Salesforce should trigger updates on the remote system (marketing campaigns), which aligns with the “UI Update Based on Data Changes” pattern.
• Volume — Small or Unknown: This pattern is suitable for both small and unknown data volumes, as it efficiently handles real-time updates and provides flexibility for varying data quantities.

By implementing the “UI Update Based on Data Changes” pattern within the data layer with asynchronous timing and data update direction from Salesforce to the remote system, you can ensure that marketing campaigns are updated in real time on account record pages and that executives can create campaigns seamlessly, regardless of whether the data volume is small or unknown. This approach provides an interactive and responsive user experience in Scenario Swiss Shepherd.

In conclusion, businesses like Petstar Ltd. that face many integration challenges, given the complexity of their operations and the diverse systems they rely on. By adopting a combination of real-time, batch, and composite integration patterns, they can significantly enhance their operational efficiency. This approach empowers their employees to make informed decisions, deliver exceptional customer service, and ensure that data flows smoothly between their systems, ultimately leading to improved business outcomes.