Connected Apps allow administrators to define specific OAuth scopes and policies, offering granular control over what external applications can access.

Existing integration protocols and standards determine how systems can communicate, which is vital for integration planning.

Identifying system boundaries helps in understanding data ownership and control, which is essential for defining integration points and responsibilities.

SOAP is commonly used for real-time integrations due to its support for synchronous communication and robust security features.

Legacy systems often have limited protocol support, which can restrict integration options and require additional middleware.

Knowing existing authentication mechanisms ensures that integrations are compatible and secure, preventing unauthorized access and data breaches.

Data standards ensure that data is consistently formatted across systems, facilitating accurate and efficient data exchange during integration.

Assessing system limitations helps identify potential performance bottlenecks, allowing for proactive mitigation strategies in the integration design.

A system boundary is the point at which one system ends and another begins, defining the limits for data exchange and integration points.

HTTPS is a secure protocol that encrypts data during transmission, making it a common choice for secure integrations.

Legacy systems often lack modern APIs, making integration with platforms like Salesforce challenging and requiring additional middleware or custom solutions.

Data silos across systems can hinder effective data synchronization, leading to inconsistencies and integration challenges.

OAuth 2.0 provides secure, token-based delegated access, allowing applications to access Salesforce resources without exposing user credentials.

Proper configuration of Salesforce as a SAML Identity Provider or Service Provider is essential for seamless authentication with external systems using SAML.

Creating dedicated integration users with only the necessary permissions enhances security and aligns with the principle of least privilege.

Understanding the existing systems, protocols, and constraints is crucial for designing effective integration solutions that align with current capabilities and limitations.

OAuth 2.0 with refresh tokens allows multiple systems to maintain secure, scalable access to Salesforce data without sharing user credentials.

The ‘API Only‘ permission restricts users from accessing the Salesforce UI, ensuring they can only interact with Salesforce through APIs, which is ideal for integration users.

Understanding existing authentication mechanisms ensures that the integration is compatible and secure, facilitating seamless communication between systems.

Using a single integration user across multiple systems can pose a security risk, as it grants broader access than necessary, violating the principle of least privilege.

MFA adds an additional verification step during login, significantly enhancing security by protecting against unauthorized access, especially in integrations involving user credentials.

Named Credentials securely store authentication settings for external services, simplifying the process of making authenticated callouts from Salesforce.

Correct Answer: A. Enable Salesforce Shield Event Monitoring and set up real-time dashboards to track API call usage and response times. Explanation: Salesforce Shield Event Monitoring provides detailed insights into the performance and usage of Salesforce integrations by tracking API calls, response times, and other critical metrics. Setting up real-time dashboards allows the Integration Architect to visualize performance data, quickly identify bottlenecks, and respond to issues proactively. This approach leverages Salesforce’s native capabilities for comprehensive and efficient monitoring. Option B is incorrect because Salesforce Debug Logs can generate an overwhelming amount of data when monitoring thousands of transactions daily, making it inefficient for real-time performance monitoring and issue identification. Option C is incorrect because implementing custom logging within the integration code requires additional development and maintenance effort. Storing logs in a separate Salesforce object can also impact storage limits and performance. Option D is incorrect because relying solely on external monitoring tools ignores the robust monitoring features available within Salesforce, which are specifically designed to work seamlessly with Salesforce integrations.

Correct Answer: B. API call latency and throughput. Explanation: API call latency measures the time taken for an API request to be processed, while throughput refers to the number of API calls handled within a specific timeframe. Monitoring these metrics is crucial for ensuring that integrations perform efficiently, handle the required load, and scale effectively as data volume increases. High latency or low throughput can indicate performance bottlenecks that need to be addressed to maintain seamless data synchronization. Option A is incorrect because the number of active users does not directly impact the performance of integrations. It is more relevant to user experience and license management. Option C is incorrect because the amount of data stored in Salesforce objects pertains to data storage management rather than the performance of integrations. Option D is incorrect because the frequency of data backups is related to data protection and recovery strategies, not directly to the performance monitoring of integrations.

Correct Answer: B. Platform Events with monitoring dashboards. Explanation: Platform Events allow real-time monitoring of integration processes by publishing events related to data transactions. By creating monitoring dashboards, the Integration Architect can track metrics such as data delivery times, success rates, and error occurrences in real-time. This setup enables proactive management of the integration to ensure that SLAs are met consistently. Option A is incorrect because Salesforce Health Check is primarily used to evaluate the security settings of a Salesforce org, not specifically for monitoring integration performance. Option C is incorrect because Salesforce Optimizer provides recommendations for improving org performance and configuration but does not offer real-time monitoring of integration performance against SLAs. Option D is incorrect because while Einstein Analytics (now Tableau CRM) can be used for advanced data analysis, it is not specifically designed for real-time integration performance monitoring and SLA compliance tracking.

Correct Answer: B. Review Salesforce debug logs, analyze API usage patterns, and identify any recent changes in the external system. Explanation: To effectively diagnose performance issues, the Integration Architect should first review Salesforce debug logs to identify any errors or delays in API processing. Analyzing API usage patterns helps in understanding if the increased response times are due to higher load or inefficient API usage. Identifying recent changes in the external system can reveal if modifications on either side have introduced performance bottlenecks. This systematic approach ensures that the root cause is accurately identified and addressed. Option A is incorrect because simply increasing API limits and restarting the service does not diagnose the underlying cause of the performance degradation and may not resolve the issue. Option C is incorrect because while implementing caching and optimizing API calls can improve performance, these actions should be taken after diagnosing the specific causes of the increased response times. Option D is incorrect because disabling the integration and performing a data backup does not address the performance issues and may disrupt business operations further.

Correct Answer: B. Track the utilization of Salesforce governor limits, such as CPU time and heap size. Explanation: Salesforce imposes governor limits to ensure that no single integration consumes excessive resources, which could degrade system performance. By monitoring the utilization of these limits, such as CPU time and heap size, the Integration Architect can identify and address performance bottlenecks, optimize code, and ensure that the integration operates smoothly even under peak loads. This proactive monitoring is essential for maintaining high performance and preventing integration failures. Option A is incorrect because monitoring active sessions and user logins is more relevant to user activity and security rather than the performance of integrations handling high-volume data processing. Option C is incorrect because updating the integration user’s password and security settings is a security best practice but does not directly relate to monitoring or maintaining integration performance. Option D is incorrect because while regular performance reviews are beneficial, they are not as immediate and actionable as tracking real-time governor limits, which provide direct insights into integration performance issues.

Correct Answer: B. Implement Salesforce Shield Event Monitoring and set up automated alerts for performance thresholds. Explanation: Salesforce Shield Event Monitoring provides comprehensive visibility into integration activities, including API usage, response times, and error rates. By setting up automated alerts based on predefined performance thresholds, the Integration Architect can receive real-time notifications of any performance degradation or failures. This proactive approach ensures that issues are promptly addressed, maintaining optimal performance and enabling quick recovery from failures. Option A is incorrect because Salesforce Health Check focuses on security configurations rather than performance monitoring. Quarterly audits may also be too infrequent to catch real-time performance issues. Option C is incorrect because manual log reviews and weekly performance testing are time-consuming and may not provide the timely insights needed for maintaining optimal integration performance. Option D is incorrect because while third-party monitoring solutions can be valuable, leveraging Salesforce’s native tools like Shield Event Monitoring ensures seamless integration and comprehensive monitoring tailored to Salesforce environments.

Correct Answer: B. Implement continuous performance benchmarking and trend analysis using historical data. Explanation: Continuous performance benchmarking involves regularly measuring the integration’s performance metrics and comparing them against historical data to identify trends and potential issues before they escalate. Trend analysis helps in forecasting future performance needs and proactively addressing any degradation in performance, ensuring that the integration remains efficient and reliable over time. Option A is incorrect because while data backups are important for data protection and recovery, they do not directly contribute to monitoring integration performance or identifying potential issues. Option C is incorrect because simply increasing API call limits does not address underlying performance issues and may lead to resource overconsumption without resolving the root causes of performance degradation. Option D is incorrect because limiting the integration to off-peak hours can reduce load temporarily but does not provide a sustainable solution for maintaining performance and identifying issues proactively.

Correct Answer: C. API response times, error rates, and data processing throughput. Explanation: Monitoring API response times helps in assessing how quickly Salesforce can process integration requests. Tracking error rates is essential for identifying issues that could disrupt data processing. Data processing throughput measures the volume of data handled over a specific period, ensuring that the integration can manage large data volumes efficiently. Together, these metrics provide a comprehensive view of the integration’s performance, enabling the Integration Architect to identify and address bottlenecks promptly. Option A is incorrect because the number of Salesforce users and their login times are more relevant to user experience and system access rather than the performance of data processing integrations. Option B is incorrect because data storage usage and file storage limits pertain to data management and capacity planning, not directly to the performance of integrations handling large data volumes. Option D is incorrect because while the frequency of data synchronization and the number of records per sync are important, they do not provide as comprehensive a view of performance as monitoring API response times, error rates, and data processing throughput.

Why D is correct: Calling the credit check service within the Save event is the functional requirement, and the SLA of 95th percentile under 2s is the non-functional performance requirement ensuring real-time responsiveness. Why A is wrong: Batch checks conflict with “real-time”. Why B is wrong: Logging and retention address auditing, not real-time. Why C is wrong: Apex debug logs are for troubleshooting, not performance guarantees.

Why C is correct: The Web Server flow issues an authorization code via browser redirect, allowing the portal to obtain tokens in the user’s context and avoid repeated prompts, respecting cross-domain SSO and CSRF protections. Why A is wrong: Canvas is deprecated for cross-domain SSO and more complex than standard OAuth flows. Why B is wrong: Hardcoded session IDs compromise security and expire unpredictably. Why D is wrong: User-Password flow requires handling credentials programmatically and cannot support SSO.

Why D is correct: JWT Bearer flow uses signed tokens issued by the IdP and doesn’t require storing user credentials or refresh tokens. The server can generate a JWT at runtime, simplifying unattended, high-volume ETL processes. Why A is wrong: Web Server flow requires initial user consent and storage of refresh tokens, adding management overhead. Why B is wrong: Storing encrypted credentials still poses risk and may fail if password policies change. Why C is wrong: SAML Bearer requires more complex assertion exchange and isn’t as streamlined for API-only flows.

Why B is correct: IP restrictions block API calls from unknown addresses; adding the application’s IP(s) to the org’s whitelist is a prerequisite to successful authentication and callouts. Why A is wrong: “API Only” governs UI access, not IP restrictions. Why C is wrong: OAuth client credentials matter after connection, but IP access must be granted first. Why D is wrong: “Modify All Data” is an authorization scope, not related to network boundaries.

Why C is correct: Named credentials configured with a specific named principal ensure that API calls execute under that user’s context and respect sharing rules, preventing over-exposure of records. Why A is wrong: “full” scope grants all permissions, ignoring object-level restrictions. Why B is wrong: “View All Data” bypasses sharing and violates least-privilege. Why D is wrong: System Mode runs without FLS or sharing, exposing all data.

Why A is correct: By hosting the SAML metadata on the Experience site and configuring Just-In-Time provisioning, users authenticate through the community domain seamlessly without exposing the internal IdP URL. Why B is wrong: Username–Password flow exposes credentials in code and cannot hide login UI. Why C is wrong: Redirecting to internal domain breaks the community UX and leaks internal endpoints. Why D is wrong: Relaxing IP restrictions doesn’t address domain exposure or login UI.

Why D is correct: Named Credentials with an external Auth. Provider automatically handle JWT validation against the IdP issuer, simplifying callout security without manual code. Why A is wrong: Manual parsing is error-prone and bypasses built-in token validation features. Why B is wrong: Auth. Provider config alone doesn’t secure callouts or code-level validation. Why C is wrong: Remote Site Settings allow callouts, but not token validation.

Why C is correct: Identity Connect synchronizes users and profiles from a central directory into multiple orgs, ensuring consistent permission sets and authentication policies across environments. Why A is wrong: Delegated Authentication only offloads password validation, not permission synchronization. Why B is wrong: OAuth scopes are per app, not a user-permission management solution. Why D is wrong: A refresh token manager handles tokens, not user provisioning or permissions.

Why A is correct: An explicit Service Level Agreement for latency directly captures the non-functional performance requirement, ensuring design choices (e.g., transport, processing) meet the 500ms threshold. Why B is wrong: Compression may reduce size but adds CPU overhead and doesn’t guarantee latency. Why C is wrong: At-rest encryption is a security requirement, unrelated to transit latency. Why D is wrong: OAuth is an authentication mechanism, not a performance metric.

Why B is correct: Calculating required throughput (5M records/7200s ?694 r/s) sets a clear performance target for the batch process, guiding API choice and parallelism. Why A is wrong: Custom UI pages cannot handle mass loads at scale. Why C is wrong: Encryption in transit is security-related, not throughput. Why D is wrong: Caching pages does not impact backend data load speed.

Why C is correct: TLS 1.2+ ensures encryption in transit and AES-256 at rest secures stored data, satisfying both security requirements for PII. Why A is wrong: “full” OAuth scope grants broad access but doesn’t enforce encryption. Why B is wrong: Audit logs help trace access but don’t enforce encryption. Why D is wrong: Read-only restricts permissions but doesn’t address encryption requirements.

Why D is correct: Defining and enforcing a unique event ID that Salesforce checks before creating records is a functional requirement that prevents duplication by making the integration idempotent. Why A is wrong: Logging events doesn’t prevent duplicates. Why B is wrong: mTLS secures transport but doesn’t guarantee idempotency. Why C is wrong: Longer retention helps auditing but not duplicate prevention.

Why A is correct: Two-phase commit or compensating transactions ensure atomicity across distributed systems, guaranteeing that either all steps succeed or none are committed, fulfilling the business’s transactional requirement. Why B is wrong: Alerts notify failures but do not enforce rollback. Why C is wrong: Archiving success doesn’t revert partial commits. Why D is wrong: Longer timeouts do not implement transaction rollback.

Why B is correct: Specifying local storage capacity and maximum sync retry interval defines the non-functional requirements for offline capability and synchronization performance. Why A is wrong: API type choice is an implementation detail, not an offline requirement. Why C is wrong: CI/CD pipelines relate to deployment, not offline functionality. Why D is wrong: UI animations don’t address offline sync.

Why C is correct: Configuring Salesforce’s network access controls to only allow API calls from approved CIDR blocks enforces the network-level authorization requirement. Why A is wrong: Password complexity affects authentication but not network origin. Why B is wrong: Disabling guest access changes Community behavior, not network boundaries. Why D is wrong: Custom domains alter URLs but don’t enforce network restrictions.

Why B is correct: Mutual TLS allows each partner to present a unique client certificate, enforcing cryptographic separation at the transport layer and eliminating shared secrets or credential reuse. Why A is wrong: A shared user cannot isolate partner actions or audit them individually. Why C is wrong: A single client secret reused across partners provides no per-partner isolation. Why D is wrong: Basic auth relies on credentials transmitted in clear or base64, offering weaker security and no partner-level identity binding.

Why B is correct: Defining concurrency capacity and error thresholds specifies the scalability and reliability non-functional requirements necessary to handle peak loads. Why A is wrong: Authentication flow choice is unrelated to load capacity. Why C is wrong: Serializing requests undermines concurrency and increases latency. Why D is wrong: Polling frequency relates to client behavior, not server load handling.

Email addresses are personal data subject to privacy regulations; they require secure handling (encryption in transit, access controls) without overclassifying as “Confidential.”

Order ID and status code reveal no customer identity or values and can be shared publicly, making them “Public” operational metadata.

Bank account numbers are direct financial identifiers requiring the highest confidentiality, encryption at rest, transit, and strict access controls (“Confidential”).

SKUs and descriptions are marketing materials intended for consumption by partners; they carry no private or proprietary risk and are “Public.”

Certificate fingerprints are internal security tokens—while not PII, they must be protected to prevent misuse, fitting “Secure.”

Anonymous aggregated metrics contain no user or sensitive data and can be safely shared, making them “Public.”

SSNs are extremely sensitive national identifiers requiring top-tier protection—strict encryption and minimal exposure under “Confidential.”

OAuth tokens grant access and require secure storage and transport, classified as “Secure” due to their sensitivity and rotation.

Aggregated, non-identifiable metrics at department-level cannot be traced to individuals; they carry minimal risk and are “Public.”

Cardholder data demands the strictest control—only highly authorized roles may decrypt and access, meriting “Restricted.”

Real-time synchronization ensures global teams can work from the same up-to-date lead records, which improves efficiency and reduces duplicate efforts—a critical CRM success factor. The other options either lack timeliness, focus on access rather than data, or introduce manual processes, which degrade CRM performance.

Customer identity resolution enables consolidation of data from various systems under a single customer profile, ensuring all departments work from the same view. Monthly exports are not real-time, and email templates or partial interaction logging don’t fulfill a 360° view requirement.

Event-driven integrations offer timely visibility, empowering service agents to respond proactively. Batch and manual options delay insights, and external exports lack usability within Salesforce, reducing CRM effectiveness.