The Integration Architect Certification is a credential developed for Salesforce professionals who have knowledge, skills, and experience implementing integration solutions on the Salesforce platform and are looking to verify their expertise to further advance their career in this area.

There are 6 areas of knowledge that are covered by the Salesforce Integration Architect certification.

They are covered by the Integration Architect training, but if you are not able to attend, then you will need to ensure you know the areas listed below well.

Integration Architect Topic Weighting Chart

The following are the core topic areas of the Integration Architect certification and what you’re expected to know:

This topic includes the following objectives:

A system landscape may consist of remote systems that must comply with certain standards and protocols required for integration. In addition, certain boundaries or limitations could also affect the integration of systems. For instance, synchronous Apex SOAP callouts require the remote system to be compatible with the web service standards supported by Salesforce, which are WSDL 1.1, SOAP 1.1, WSI-Basic Profile 1.1, and HTTP. And the maximum number of callouts in an Apex transaction cannot exceed 100.

A system landscape may consist of constraints and/or pain points that can negatively affect integration solutions. For instance, if the custom logic defined in an Apex class that performs a SOAP callout to an ERP system is incorrect, the integration can cause errors in the ERP system.

Salesforce features such as organization-wide defaults, profiles, permission sets, and automated business processes may need to be assessed to identify any constraints or pain points that can be eliminated.

A system landscape represents an IT infrastructure and illustrates how servers, clients, external applications, and other systems relate with each other. System integration requires authentication and authorization to allow and secure communication between independent systems. Salesforce supports different protocols and provides several tools to allow various types of integration with their multi-tenant platform.

This section covers basic concepts related to authorization and authentication for external systems integrated with Salesforce, and describes, namely, the topics such as Named Credentials, OAuth 2.0, Connected Apps, and Certificates & Keys.

This topic includes the following objectives:

The implementation of an integration solution generally requires identifying functional and non-functional requirements. Functional requirements are mandatory and describe the features or functions of the system, such as the functionality of a particular integration feature in Salesforce. Example of a functional requirement is that a user would like to obtain order data from an external system by clicking a quick action on an opportunity record page in Salesforce. On the other hand, non-functional requirements describe how the features or functions of the system should perform. Examples include data volume, scalability, security, etc.

It is highly important for an organization to be knowledgeable of the data that it stores and uses in its day-to-day operations. Depending on the location of the business entity or residence of the customers who contribute to data in the org, there are legal obligations that require the organization to keep data confidential and secure. Examples of these data protection and privacy laws are the General Data Protection Regulation (GDPR) that is used to protect personal data of EU residents, or the Health Insurance Portability and Accountability Act (HIPAA) in the US to protect healthcare information. Salesforce allows specifying the data sensitivity of a field to indicate whether the data it holds should be treated as confidential, secure or encrypted, or public. Data classification requires an organization to define the org’s schema and identify the risk and sensitivity of each data, and Salesforce provides tools to make the process easier.

When designing an integration solution or functionality that has impact on data and processes of an organization, there are key factors to consider to ensure the successful implementation and delivery of the project. An example factor is the operating model that a business is patterned after, which affects the scope of the project and the strategy that can be used to meet the requirement. In a business that adheres to a good governance framework, IT initiatives are always aligned with the company’s vision and strategy, priorities are identified in an exhaustive list of business requirements, a proper software development lifecycle process is in place, and other factors. In this topic, the lean governance framework is discussed to determine aspects that impact the success of system integration initiatives.

The choice of integration solutions can be impacted by business growth and regulatory factors. Business growth can be in the form of a new business sector in a foreign country or customer base expansion through marketing initiatives. Establishing a business in a new country may require integrating additional enterprise systems or using a separate Salesforce org.

Laws and regulations such as the GDPR, LGPD, and PIPL can affect the choice of integration solutions. For instance, to comply with the GDPR, it may be necessary to delete customer data stored in Salesforce when it is no longer needed. 

An architect should also take into account certain considerations while designing integration solutions based on business factors and regulations. One of the important design considerations is that the integration solution should be based on the company’s interpretation of the regional law(s).

This topic includes the following objectives:

There are different types of Salesforce system architecture landscapes, namely, ground-to-cloud, cloud-to-ground, and cloud-to-cloud. In the Cloud-to-Ground architecture, data originates from Salesforce and is pushed into an on-premise system. In the Ground-to-Cloud architecture, data originates from the on-premise architecture and is pushed into Salesforce. In the Cloud-to-Cloud architecture, data is moved from one org to another. The integration pattern(s) used in a system landscape depend on the company’s business requirements. The different integration patterns are Remote Process Invocation - Request & Reply, Remote Process Invocation - Fire & Forget, Batch Data Synchronization, Remote Call-In, UI Update Based on Data Changes, and Data Virtualization.

An integration design may be affected by system and/or process constraints. System constraints are limitations or restrictions within Salesforce or a remote system that necessitate the implementation of an alternative. On the other hand, process constraints are limitations or restrictions in a business process that necessitate the implementation of an alternative approach. For example, an integration solution design may be affected by the limited number of API calls per day or the lack of support for REST API by the remote system.

Salesforce provides industry-standard and secure protocols for authorizing external applications with the platform. In a scenario where a user outside Salesforce needs to access the services of the platform, Salesforce can be used to authenticate the user, or Salesforce can rely on an external service to validate the identity of the user before authorizing access. Several types of authentication flows are supported to allow different types of applications such as web apps, mobile apps, servers, and IoT devices to integrate with the org. Although Salesforce uses some of the most advanced technology for protecting the multi-tenant platform, additional security procedures are always recommended to further enhance org security that will be described in this section.

The choice of the integration pattern for an integration between Salesforce and a remote system may depend on the required data volumes, response times, and latency. For example, an integration based on the ‘Remote Process Invocation - Request & Reply’ pattern is suitable for small volume, real-time activities.

REST/SOAP API can be invoked from a remote system to create, update or delete 200 records at a time. If a data load for data synchronization with a remote system requires processing of more than 2,000 records, the use of Bulk API 2.0 can be considered. Synchronous Apex callouts are suitable for small volume, real-time activities. Salesforce Connect can be used to give users real-time access to data.

This topic includes the following objectives:

As part of this objective you should understand the various integration patterns that can be utilized to design integrations between Salesforce and remote systems. It also covers the use cases of the integration patterns. An integration pattern describes the design and approach for integrating systems. It can focus on application, data or process integration.

The integration pattern called Remote Process Invocation - Request & Reply is used when Salesforce needs to perform a synchronous callout to a remote system and wait for a reply. Remote Process Invocation - Fire & Forget is used to send information to a remote system when an immediate response is not required. Batch Data Synchronization is used for exporting, transforming and loading data between Salesforce and a remote system. Remote Call-In is used when a remote system needs to perform an API call to Salesforce to retrieve, create, update, or delete data. Data Virtualization is used to give Salesforce users access to data stored in a remote system. UI Update Based on Data Changes focuses on the use of Streaming API to update Salesforce UI whenever an event occurs. The Publish/Subscribe pattern involves the use of platform events, which can be used by Salesforce and a remote system to communicate events.

As part of this objective you should understand various integration solutions and the components that comprise each solution. An integration solution is typically based on an integration pattern. Salesforce can be integrated with an external system using one of several integration patterns, including Remote Process Invocation (synchronous and asynchronous), Remote Call-In, Batch Data Synchronization, and Data Virtualization.

Various native features are available for building an integration solution, such as REST API, SOAP API, Platform Events, Apex Web Services, Salesforce Connect, etc. Each solution consists of certain components or resources that are used to connect the systems and process data. For example, using Enhanced External Services requires registering an external web service using a JSON-based API spec, which generates invocable actions that can be used in a flow built using Flow Builder.

An integration solution may be affected by limitations or constraints. A trade-off may be necessary in an integration solution design to meet a particular requirement. It’s a situational decision that involves losing one aspect of the design in favor of gaining another aspect.

Limitations that can affect an integration solution include governor limits, such as the maximum size of an HTTP response, and lack of support for the required capabilities or standards. Constraints can make it necessary to consider an alternative solution. For example, if a company does not have the resources for programmatic development, it may be necessary to choose a declarative solution.

Salesforce provides access to various APIs that can be used for integration with external systems. REST API is a REST-based web services interface that can be used for programmatic access to data in Salesforce. Similarly, SOAP API can be used to retrieve, create, update, or delete Salesforce records.

Bulk API 2.0 is based on REST and is used to process large sets of data. It can be used to insert, update, upsert, or delete hundreds of thousands of records. Streaming API is a subscription-based mechanism based on CometD that enables real-time streaming of event messages.

An integration solution may consist of several components, which can be affected by standards, calling mechanisms, and security mechanisms. Each component of an integration solution must be compatible with the standards supported by Salesforce. For example, SOAP API calls must use the standards supported by Salesforce (WSDL 1.1, SOAP 1.1, WSI-Basic Profile 1.1, and HTTP).

Certain security considerations also apply to integration solutions. For example, an OAuth trust must be established for using one of the Salesforce APIs, such as REST or SOAP API.

The technique or calling mechanism used for an integration solution is affected by the requirement. For example, if a remote process needs to be triggered from a user interface in Salesforce, an enhanced external service invoked from a flow, a Lightning component, or a Visualforce page can be used as the calling mechanism.

This topic includes the following objectives:

Salesforce offers various APIs for inbound integration, including REST API, SOAP API, Bulk API 2.0, and Streaming API. Various considerations and limitations apply to the use of an API. For example, Salesforce limits the number of API calls per 24-hour period, which depends on the edition and number of licenses.

Enhanced External Services or REST/SOAP callouts can be used to invoke an external API. Considerations related to authentication, data format, and schema definition are applicable to the use of an external service. Various governor limits, such as the maximum number of callouts allowed in an Apex transaction, apply to REST/SOAP callouts

Salesforce offers various options for making outbound calls from Salesforce. These include Enhanced External Services, Apex SOAP Callouts, Apex REST Callouts, and Outbound Messaging. 

Various considerations apply for using an outbound integration technique. For example, a remote site setting must be created to make a REST or SOAP callout using Apex code. A named credential must be defined for invoking an external service action from a flow. Outbound Messaging can be configured to send a session ID to allow the external system to make callbacks. 

A system is referred to as being scalable when it doesn’t need to make adjustments in order to operate normally when there is a substantial increase in workload as a result of user spikes or growth in data volume. In this topic, the considerations and recommendations for attaining scalability especially in environments with large data volume will be covered. Identifying the factors that impact scalability, defining a data management plan, and tracking org performance on a regular basis are key considerations to building a scalable solution.

Salesforce provides several tools for integrating the platform with other systems. A specific set of solution options are available based on the integration pattern that is implemented. When using these tools such as External Services, Outbound Messaging, Salesforce APIs, Platform Events, Change Data Capture, and Salesforce Connect in an integration solution, it is essential to be able to identify when errors can occur, which system should perform custom error handling, and even more so how to handle the errors to maintain a stable and reliable application.

In this topic, error handling mechanisms related to these integration options will be covered as well as use cases that illustrate how they’re implemented in real-world scenarios.

When integrating external applications that perform inbound requests to Salesforce, it is critical to be aware of the security implications, considerations, and features in the different layers of the platform architecture. Implementing security features available in the authentication, network, session, and data layers helps deliver secure solutions while providing reliable services to external clients.

Salesforce also provides recommendations for securing an integration solution where the org performs outbound calls to the external application such as data encryption, 2-way SSL, etc. In this topic, related features, recommendations, and considerations as well as use cases will be covered.

As part of this objective you should understand the key factors that should be identified to build resilient integration solutions. Different factors need to be considered for different integration patterns. For instance, for building resilience in Remote Process Invocation - Request & Reply solutions, recovery, timeliness, and state management should be considered. Changes should not be committed until a successful response has been received from the remote system. Retries and configurable timeout should be utilized for Apex callouts if necessary.

Ongoing state tracking using keys can be considered for various integration solutions. For example, when using batch data synchronization, Salesforce can store the unique ID returned by the remote system, and prior to performing any operations in the future, the ID can be checked to avoid record duplication.

Reliable messaging is also an important consideration for ensuring resilience in certain types of integration solutions. For example, when using REST API or SOAP API, the remote system should implement a reliable messaging system for timeout and error handling scenarios.

This topic includes the following objectives:

Salesforce provides tools that can be used to evaluate performance of the org, its applications, or pages. These tools can be used to monitor specific attributes and metrics related to integration solutions such as integration user logins, API requests, outdated API versions, and others. In this topic, tools such as Event Monitoring, real-time events, and Salesforce Optimizer will be covered to identify their capabilities and determine how they can be used to meet performance monitoring needs in integrated solutions.

 The strategy used for error handling, escalation, and recovery in an integration solution depends on the integration pattern. For instance, when an integration is based on the Remote Process Invocation - Request & Reply pattern, the caller (e.g., a synchronous Apex REST callout) should manage error handling. A suitable recovery mechanism is also important to consider in an integration solution design. In most cases, a custom retry mechanism can be implemented if quality-of-service requirements dictate it.

 This section takes a more in-depth look into Event Monitoring and Real-Time Event Monitoring to cover other general events that can be captured in an org environment that is integrated with another system. While Event Monitoring store events in event log files when resources are available, Real-Time Event Monitoring can stream and/or store events in near-real time. Furthermore, a transaction security policy can be created to intercept a real-time event and determine its next course of action.

The event information at the object and schema level will be described in order to provide a clearer picture of how granular the captured details are that enable for more efficient monitoring and can meet even complex reporting needs.