Salesforce Integration-Architect Salesforce Certified Integration Architect (SU24) Exam Practice Test

• Option C is correct because including selective criteria in query filters can improve the performance of the integration. Selective criteria are filters that reduce the number of records that need to be scanned by the query optimizer, such as indexed fields, standard indexes, or custom indexes. Selective criteria can help the query run faster and avoid hitting the query timeout limit or the query row limit.
• Option D is correct because removing the sharing restrictions can improve the performance of the integration. Sharing restrictions are filters that limit the access to records based on the user’s role, profile, or sharing rules. Sharing restrictions can add complexity and overhead to the query execution, as they require additional joins and calculations. Removing the sharing restrictions can simplify the query and reduce the number of records that need to be processed.
• Option A is incorrect because including non-selective criteria in query filters can degrade the performance of the integration. Non-selective criteria are filters that do not reduce the number of records that need to be scanned by the query optimizer, such as non-indexed fields, formula fields, or OR conditions. Non-selective criteria can cause the query to run slower and hit the query timeout limit or the query row limit.
• Option B is incorrect because removing the query filters can degrade the performance of the integration. Query filters are conditions that specify which records to retrieve from the database, such as WHERE clauses or LIMIT clauses. Query filters can help the query run faster and avoid retrieving unnecessary or unwanted data. Removing the query filters can increase the number of records that need to be processed and transmitted by the integration.

References: Working with Very Large SOQL Queries: Improve performance with custom indexes using Salesforce Query Plan tool: Querying Data That Respects User Permissions: How does sharing affect SOQL performance?: SOQL SELECT Syntax : SOQL Best Practices

 The BatchApexErrorEvent object allows handling errors that occur during Batch Apex execution. By subscribing to this event, the integration can retry the invoice generation for the failed records or perform other recovery actions. This is a resilient and scalable solution that does not require custom code in the Batch Apex job itself or in the middleware1

 Invoking middleware service to retrieve valid shipping methods is a solution that can allow the sales representatives to select between valid services for the customer’s country. The middleware service can act as a single point of entry for all shipping services and provide routing and transformation capabilities. Using middleware to abstract the call to the specific shipping services is a solution that can allow the sales representatives to request shipping estimates from the selected service. The middleware can hide the complexity and heterogeneity of the shipping services and provide mediation and orchestration capabilities. Using Platform Events to construct and publish shipper-specific events is not a solution, as Platform Events are used for event-driven integration, not for web-service integration. Storing shipping services in a picklist that is dependent on a country picklist is not a solution, as it does not address how to request shipping estimates from the shipping services. Reference: Salesforce Integration Architecture Designer Resource Guide, page 16-17

Option B is a correct finding, because it means that the company can use their cloud-based ETL tools to extract data from the legacy systems via the APIs exposed by the on-premise middleware, transform the data as needed, and load the data into Salesforce using queues. Queues are a way of managing asynchronous operations, such as bulk data loading, by placing them in a queue and executing them when resources are available1.

Option C is also a correct finding, because it means that the company can expose their legacy data to the cloud via their on-premise middleware APIs. APIs are a way of enabling communication and data exchange between different systems using standard protocols and formats2. By providing APIs to access their legacy data, the company can use any cloud-based tool or application that can consume those APIs to retrieve and manipulate the data.

Option A is not a correct finding, because it means that the company cannot access their legacy data from the cloud, which prevents them from using their cloud-based ETL tools or any other cloud-based integration solution. If only on-premise systems are allowed to access the legacy systems, then the company would need to use an on-premise integration tool or application to copy the data to Salesforce.

Option D is not a correct finding, because it does not affect the ability to copy legacy data in Salesforce. Queues are useful for on-premise integration, but they are not necessary for copying data to Salesforce. The company can use other methods, such as direct API calls or batch processes, to load data into Salesforce without using queues.

References: 1: Queueable Apex | Apex Developer Guide | Salesforce Developers 2: API Basics | SOAP API Developer Guide | Salesforce Developers

The API that should be used for the Salesforce platform event solution is Tooling API. Tooling API is a specialized API that exposes metadata used in developer tooling that you can access through REST or SOAP. You can use Tooling API to create, update, or delete platform event definitions and fields4 Streaming API is used to subscribe to platform events and receive notifications when they are published5

References: Platform Events Developer Guide | Salesforce Developers, Define and Publish Platform Events Unit | Salesforce Trailhead

QUESTIONNO: 241

Northern Trail Outfitters is in the final stages of merging two Salesforce orgs but needs to keep the retiring org available for a short period of time for lead management as it is connected to multiple public web site forms. The sales department has requested that new leads are available in the new Salesforce instance within 30 minutes.

Which two approaches will require the least amount of development effort?

Choose 2 answers

A Configure named credentials in the source org.

B Use the Composite REST API to aggregate multiple leads in a single call.

C Use the tooling API with Process Builder to insert leads in real time.

D Call the Salesforce REST API to insert the lead into the target system.

Answer: A, B

The two approaches that will require the least amount of development effort are configuring named credentials in the source org and using the Composite REST API to aggregate multiple leads in a single call. Named credentials are a type of metadata that store authentication information for accessing external services, such as the target Salesforce org. By using named credentials, you can simplify the code for making callouts and avoid hardcoding credentials or tokens. The Composite REST API is a resource that allows you to execute multiple REST API requests in a single call. You can use the Composite REST API to create, update, or delete up to 25 records in one request. This can reduce the number of API calls and improve performance.

References: [Named Credentials], [Composite Resources]

The typical and worst-case historical response times, and how many concurrent service calls are being placed are two considerations that an integration architect should make when building a scalable integration solution for synchronous callouts to “available to promise” services. These two factors can affect the performance, reliability, and availability of the integration solution, as well as the user experience of the customer checkout process. The integration architect should design the solution to handle high volumes of service calls, optimize the response times, handle errors and timeouts, and avoid hitting governor limits or service quotas. References: Certification - Integration Architect - Trailhead, [Callout Limits and Limitations], [Integration Patterns and Practices]

 The best solutions for minimizing potential downtime for users in this situation are to use named credentials and an enterprise ESB. Named credentials allow you to store the URL and authentication parameters of an external service in one definition, and then use it in Apex callouts or declarative integrations. If the URL of the external service changes, you only need to update the named credential once, and all the integrations that use it will be updated automatically. An enterprise ESB is a middleware layer that acts as a broker between different systems and services. It can provide routing, transformation, orchestration, and monitoring capabilities for integrations. If the URL of an external service changes, you only need to update the ESB configuration once, and all the integrations that use it will be updated automatically. Option B is not correct because remote site settings only allow you to specify the domains that are allowed for callouts from your org. They do not store any authentication parameters or provide any routing or transformation capabilities. Option C is not correct because content security policies are used to control what resources can be loaded on a Visualforce or Lightning page. They do not store any authentication parameters or provide any routing or transformation capabilities. References:

• Named Credentials
• Streamline and Secure: Mastering Named Credentials in Salesforce

The three systems from the current system landscape that can be retired with the implementation of Salesforce are Case Management System, Sales Activity System, and Email Marketing System. These systems can be replaced by Salesforce Service Cloud, Sales Cloud, and Marketing Cloud respectively, which provide similar or better capabilities for managing cases, sales activities, and email campaigns. Option A is not correct because Order Management System cannot be retired with the implementation of Salesforce. The company wants to reuse their existing enterprise capabilities for order management processes, which are likely to be complex and customized. Salesforce does not provide a native order management solution for B2C commerce scenarios. Option E is not correct because Quoting System cannot be retired with the implementation of Salesforce. The company wants to reuse their existing enterprise capabilities for quoting processes, which are likely to be complex and customized. Salesforce does not provide a native quoting solution for B2C commerce scenarios.

The maximum callouts in a single Apex transaction is one of the factors that should be considered when choosing Apex code to make callouts to an external system. The limit is 100 callouts per transaction, and if this limit is exceeded, a LimitException is thrown. Therefore, the integration architect should evaluate the expected volume and frequency of the callouts and design the solution accordingly2

References: Salesforce API Limits and Usage

Using Change Data Capture (CDC) to update downstream systems accordingly when a record changes is a solution that can handle this requirement by capturing data changes in Salesforce and sending them to external systems via a publish-subscribe model. This way, the external systems can receive near real-time updates from Salesforce and synchronize their data accordingly. Designing an MDM solution that maps external ID’s to the Salesforce record ID is a solution that can handle this requirement by creating a master data hub that stores and manages the unique identifiers of each system and their relationships. This way, the MDM solution can ensure data quality, consistency, and accuracy across systems. Locally caching external ID’s at the middleware layer and designing business logic to map updates between systems is not a good solution because it can introduce performance and scalability issues, as well as increase the complexity and maintenance cost of the middleware layer. Storing unique identifiers in an External ID field in Salesforce and using this to update the proper records across systems is not enough to handle this requirement, as it does not address how to update Salesforce with record changes from external systems. Reference: Salesforce Integration Architecture Designer Resource Guide, page 27-28

 Idempotent design means that the same request can be repeated multiple times without changing the outcome. This is useful for avoiding duplicate orders in case of network failures or timeouts. By implementing idempotent design, the sales representatives can retry the order(s) in question without creating duplicates in the manufacturing system. Outbound messaging is not a reliable solution because it does not guarantee delivery or acknowledgement of messages. Scheduled apex is not a real-time solution and may not catch all the duplicate or missing orders

• Option B is correct because platform events are published after the Apex transaction completes. Platform events are asynchronous messages that are published and consumed by different processes or systems. When an Apex transaction publishes a platform event, the event is not sent immediately, but rather added to a temporary queue. The event is only published and delivered to the subscribers after the Apex transaction commits successfully. This ensures that the event data is consistent with the database state and that the event is not lost in case of a rollback.
• Option A is incorrect because platform events are not published immediately before the Apex transaction completes. As explained above, platform events are published after the Apex transaction commits successfully. Publishing events before the transaction completes can cause data inconsistency and event loss issues.
• Option C is incorrect because platform events can have a trigger in Apex, but this is not related to the question of when events are published. A platform event trigger is a special type of Apex trigger that executes when a platform event message is received by Salesforce. A platform event trigger can perform logic based on the event data, such as updating records, sending notifications, or calling external services. A platform event trigger does not affect the publishing of events, but rather the consumption of events.
• Option D is incorrect because platform events can be published from Apex, but this does not answer the question of when events are published. Platform events can be published from various sources, such as Apex code, Process Builder, Flows, or API calls. Publishing events from Apex requires creating an instance of a platform event object and using the EventBus.publish method to add it to the temporary queue. The actual publishing of events happens after the Apex transaction completes, regardless of the source of the events.

References: Publish and Subscribe with Platform Events: Publish Platform Events : Subscribe to Platform Events : Write a Platform Event Trigger : Create and Publish Platform Events in Apex : EventBus Class

Creating Salesforce Cases using the Salesforce REST, SOAP or Bulk API is a solution that can allow the logging service to create case records in Salesforce based on the exceptions received from the middleware platform. This way, the logging service can use the standard APIs to interact with Salesforce and leverage the features and functionality of the case object. Creating Salesforce Cases conditionally using automatic Case creation rules is a solution that can allow the logging service to create case records in Salesforce based on predefined criteria and actions. This way, the logging service can reduce the number of API calls and avoid creating unnecessary or duplicate cases. Receiving Application Events through Change Data Capture (CDC) is not a solution that is related to this requirement, as CDC is used for capturing data changes in Salesforce and sending them to external systems, not for receiving data from external systems. Subscribing to the Application Exceptions using the Salesforce Streaming API is also not a solution that is related to this requirement, as Streaming API is used for subscribing to events or notifications from Salesforce, not for sending data to Salesforce. Reference: Salesforce Integration Architecture Designer Resource Guide, page 25-26

The integration consultant should evaluate current and future data and system usage and then identify potential integration requirements to Salesforce. This approach can help to understand the business needs, data flows, data quality, data volume, data frequency, and data security of the proposed CRM system. Based on this analysis, the integration consultant can design and implement the best integration solution for each system, such as Marketing, ERP, or Outlook.

References: [Salesforce Integration Architecture Designer Resource Guide]

• Option A is correct because using ESB (Mule) with cache/state management can help to handle the long-running requests from Salesforce and return a request ID or a response if available from the external systems. This way, Salesforce does not have to wait for the external systems to respond and can avoid the API gateway timeout1
• Option C is correct because using Continuation callouts can make the eligibility check request from Salesforce from Lightning UI at page load without blocking the UI thread. Continuation callouts are asynchronous and can handle long-running requests up to 60 seconds23
• Option E is correct because implementing a ‘Check Update’ button that passes a request ID received from ESB can allow the user to manually check the status of the eligibility check request. This can be useful when the response is not available within the Continuation timeout limit or when the user wants to refresh the data4
• Option B is incorrect because recommending synchronous Apex callouts from Lightning UI to External Systems via Mule and implementing polling on API gateway timeout can cause performance issues and user frustration. Synchronous Apex callouts block the UI thread and can only handle requests up to 120 seconds. Polling on API gateway timeout can increase the network traffic and consume the callout limits25
• Option D is incorrect because creating a Platform Event in Salesforce via Remote-Call-In and using the empAPI in the lightning UI to serve 3,000 concurrent users can introduce complexity and scalability issues. Platform Events are meant for event-driven architecture and not for request-response scenarios. Remote-Call-In requires an additional license and configuration. empAPI has a limit of 1,000 concurrent subscribers per channel678

References: 1: MuleSoft Documentation 2: Salesforce Documentation 4: Salesforce Trailhead 3: Salesforce Developers Blog 5: Salesforce Documentation 6: Salesforce Documentation 7: Salesforce Documentation 8: Salesforce Documentation

• Option C is correct because Salesforce should be the system of record for their customers and prospects, as it is the CRM solution that the sales and service associates use to view and log their interactions with them. Salesforce can also integrate with the Marketing and ERP solutions to display relevant information from those systems, such as campaign history, invoices, and orders12
• Option A is incorrect because ERP is not a suitable system of record for customers and prospects, as it is mainly focused on invoicing and order fulfillment. ERP may not have all the data that the sales and service associates need to interact with them, such as contact details, preferences, activities, and opportunities. ERP may also have different data models and definitions than Salesforce and Marketing, which can cause data quality and consistency issues3
• Option B is incorrect because Marketing is not a suitable system of record for customers and prospects, as it is mainly focused on email campaigns. Marketing may not have all the data that the sales and service associates need to interact with them, such as account information, service cases, contracts, and quotes. Marketing may also have different data models and definitions than Salesforce and ERP, which can cause data quality and consistency issues.
• Option D is incorrect because creating a new custom database for customers and prospects is not a feasible or efficient solution, as it would require additional development, maintenance, and integration costs. It would also create another layer of complexity and potential data duplication in the system landscape. Salesforce already provides a robust and flexible platform for managing customer and prospect data, which can be easily customized and integrated with other systems.

References: 1: Salesforce CRM - The Definitive Guide 2: Salesforce Integration Cloud - Connect Any App, Data, or Device 3: What Is ERP? | Oracle : Salesforce vs ERP: What’s the Difference? : Marketing Cloud - Digital Marketing Platform : Salesforce vs Marketing Cloud: What’s the Difference? : Salesforce Platform - Build Apps Fast : Why You Shouldn’t Build Your Own CRM System

The mobile device should make a REST Apex inbound call to meet the requirement. A REST Apex inbound call allows the mobile device to invoke custom Apex logic on Salesforce using a RESTful interface. The Apex logic can then access the geolocation field using the user’s OAuth token and update it with the GPS coordinates from the mobile device. The geolocation field is secured with Field Level Security, so the user can view the value without changing it. A SOAP API inbound call or a REST API inbound call would not be able to access the custom geolocation field, as they are not supported by the standard Salesforce objects and fields. Reference: Salesforce Integration Architecture Designer Resource Guide, page 20

Data Visualization is the type of integration that allows users to view real-time data from an external system without storing it in Salesforce. This can be achieved by using Lightning Web Components, Visualforce pages, or Canvas apps that display data from the external system using APIs or web services. Data Synchronization, Process Orchestration, and Batch Processing are types of integration that involve moving data between systems, which is not required by the business requirement. Reference: Salesforce Integration Architecture Designer Resource Guide, page 9

The continuation class in Apex allows you to make long-running requests to external web services and process their responses in a callback method. This is useful for scenarios where the response time exceeds the normal Apex limits, such as 10 seconds for synchronous transactions or 120 seconds for asynchronous transactions. By using continuation, you can avoid hitting these limits and provide a better user experience1

References: Callout Limits and Limitations

The integration architect should consider Change Data Capture Events and High Volume Platform Events for using the Streaming API with minimal data loss. Change Data Capture Events capture changes to Salesforce records and deliver them as events to subscribers. High Volume Platform Events are custom events that can be published and consumed at a large scale. Both types of events support reliable event delivery, which means that events are stored for 72 hours and can be replayed by subscribers in case of connection loss or failure. This ensures that data loss is minimized, even when the client re-connects every couple of days12

References: Change Data Capture Developer Guide, Platform Events Developer Guide

 Outbound Message is a SOAP-based notification service that sends information about changes in Salesforce to a specified endpoint. It is a type of Remote Process Invocation—Fire and Forget integration pattern, which means that Salesforce does not wait for a response from the external system. Outbound Message can be configured using workflow rules or process builder, and it can include a subset of fields of the object that triggered the message. Outbound Message requires the external system to expose a SOAP web service that conforms to the WSDL generated by Salesforce1.

SOAP API is a way to access Salesforce data and functionality using SOAP (Simple Object Access Protocol), which is a standard XML-based protocol for exchanging structured data over the web. SOAP API can be used for both inbound and outbound integration, and it supports two types of WSDL (Web Service Description Language) files: Enterprise and Partner. Enterprise WSDL is a strongly typed WSDL file that is specific to an organization’s Salesforce configuration. It can be used when the client application knows the objects and fields it needs to access at compile time. Partner WSDL is a loosely typed WSDL file that is generic for any organization. It can be used when the client application needs to access data dynamically at run time2.

Therefore, the correct answer is A, because Outbound Message is suitable for Fire and Forget integration from Salesforce to the legacy system, and SOAP API using Enterprise WSDL is suitable for getting response back in a strongly typed format from the legacy system to Salesforce.

References: 1: Remote Process Invocation—Fire and Forget | Integration Patterns and Practices | Salesforce Developers 2: SOAP API Developer Guide | SOAP API Basics | Salesforce Developers

Streaming API is the best option for sending real-time notifications of changes to Salesforce data. Streaming API uses a publish-subscribe model to push relevant data to subscribers without polling. Streaming API supports PushTopic events, which are based on SOQL queries that define the data changes to listen for. The affiliate company can subscribe to a PushTopic event on the NTO Salesforce org and receive notifications whenever the data that matches the query changes. This way, the affiliate company can be informed of any updates to the opportunities in the NTO Salesforce instance.

A microservice architecture is a way of designing software applications as a collection of loosely coupled services, each of which implements a specific business function. Microservices enable modularity, scalability, and agility in software development, as well as easier testing and deployment. By breaking up the monolithic web service into smaller pieces, each responsible for a single integration, UC can decouple the systems and improve the performance of the integrations. For example, UC can use Salesforce Platform Events to publish and subscribe to events from Salesforce to the legacy billing application, the ERP application, and the data lake. This way, UC can avoid point-to-point integrations and leverage an event-driven architecture that reduces coupling and increases reliability12.

The other options are not as effective as option B. Option A does not address the root cause of the tight interdependencies between systems, and may not result in significant performance improvement. Option C may improve the throughput of data loading into Salesforce, but it does not solve the problem of coupling between systems. Option D may reduce the latency and maintenance costs of the web service, but it does not change the design of the web service or the integrations.

References: 1: Microservice Architectures With Sales and Service Cloud - Salesforce Live 2: 6 Fundamental Principles of Microservice Design | Salesforce

Using an Enterprise Service Bus (ESB) to determine which shipping service to use, and transform requests to the necessary format is a good solution because it can provide routing, transformation, mediation, and orchestration capabilities for integrating different services. An ESB can also abstract the complexity and heterogeneity of the services from the client application, which simplifies the integration. Using Outbound Messaging to request costs and delivery times from Shipper delivery services with automated error retry is not a good solution because Outbound Messaging is a Salesforce-specific feature that uses SOAP web services, which may not be compatible with all shipping services. Using APEX REST Service to implement routing logic to the various shipping service is also not a good solution because it can introduce performance and scalability issues, as well as increase the maintenance cost and complexity of the code. Using Enterprise Service Bus user interface to collect shipper-specific form data is not a valid option because an ESB does not have a user interface component. Reference: Salesforce Integration Architecture Designer Resource Guide, page 16-17

The integration architect should consider the impact of deleted records on system functionality, the ability to delete personal data in every system, and the ability to provide a 360-degree view of the customer. These are important requirements for ensuring that the company can comply with the privacy and data protection regulations, as well as deliver a customer-centric service. Option A is not correct because manual steps and procedures are not desirable for deleting personal data on demand. The integration architect should aim for an automated and reliable solution that minimizes human intervention and errors. Option D is not correct because restoring deleted records when needed may violate the privacy and data protection regulations, as well as the customer’s consent. The integration architect should ensure that the deletion of personal data is permanent and irreversible.

The error “Max CPU time exceeded” occurs when a batch of records takes more than 10 minutes to process in the Bulk API. Using a smaller batch size can reduce the processing time and avoid this error. However, there are some trade-offs to consider when using a smaller batch size, such as:

• Answer A is valid because a smaller batch size may cause record-locking errors if multiple batches try to update the same records or records that are related by a lookup or master-detail relationship. This can result in concurrency issues and data inconsistency1
• Answer B is valid because a smaller batch size may increase the time required to execute bulk jobs, as more batches need to be created and processed sequentially. This can affect the performance and efficiency of the integration1
• Answer C is not valid because a smaller batch size may not exceed the concurrent API request limits, as the Bulk API does not count against the concurrent request limit. The Bulk API has its own limit on the number of batches that can be queued or in progress, which is 5,000 per rolling 24-hour period2
• Answer D is not valid because a smaller batch size can trigger “Too many concurrent batches” error only if the number of batches exceeds the limit of 5,000 per rolling 24-hour period. This error is not related to the parallel mode of the Bulk API, which allows up to 10 batches to be processed simultaneously

OpenId Connect Authentication Provider and Registration Handler, and SAML SSO and just-in-time provisioning are two requirements that the Salesforce Community Cloud can support for self-registration and SSO. OpenId Connect is a protocol that allows users to authenticate with an external identity provider and access Salesforce resources. A registration handler is a class that implements the Auth.RegistrationHandler interface and defines the logic for creating or updating a user in Salesforce after authentication. SAML SSO is a protocol that allows users to log in to Salesforce with a single click, using an assertion from an identity provider that confirms the user’s identity. Just-in-time provisioning is a feature that allows Salesforce to create or update a user account based on the information in the SAML assertion. References: Certification - Integration Architect - Trailhead, [OpenID Connect Authentication Providers], [SAML Single Sign-On (SSO) Service for Salesforce]

Remote Site Settings and Named Credentials are solutions that should be implemented to minimize potential downtime for users in this situation. Remote Site Settings allow you to specify external domains that your organization can access during API calls or integrations. Named Credentials allow you to store authentication information for external services in a secure way. By using Named Credentials, you can easily update the URL of the external service without changing any code or configuration that references it. Enterprise Service Bus (ESB) and Remote Site Settings are not solutions that should be implemented in this situation because ESB is a middleware that facilitates communication between different systems, not a way to update the URL of an external service. Event Monitoring and Content Security Policies are also not solutions that should be implemented in this situation because Event Monitoring is used to track user activity and performance metrics, not to monitor external service availability. Content Security Policies are used to control what resources can be loaded on a web page, not to update the URL of an external service.

User Interface API should be used to implement this integration. User Interface API is a RESTful API that allows you to create native mobile apps and custom web apps with the look and feel of Salesforce’s Lightning Experience. User Interface API provides access to metadata, data, and UI components, such as layouts, actions, picklists, and record types. User Interface API also handles security, performance, and compatibility across different devices and browsers. References: Certification - Integration Architect - Trailhead, [User Interface API Developer Guide]

 Make a callout to the payment gateway through ESB supporting error handling and logging for audit purposes. This solution meets the requirements of integrating with an external RESTful service, ensuring real-time updates to the CSR, and supporting post payment processes. ESB stands for Enterprise Service Bus, which is a software architecture model that allows communication between different applications via a common bus. ESB can handle the callout to the payment gateway service, and provide error handling, logging, routing, transformation, and orchestration capabilities. ESB can also integrate with other systems or services that are involved in the post payment processes, such as billing, invoicing, or reporting. References: Certification - Integration Architect - Trailhead, [Enterprise Integration Patterns]