• Cert++
  • Practice
  • Certle
  • Review
  • Tracks
  • Checklist
  • Guides
  • Upgrade
Cert++
  1. Home
  3. Platform Integration Architect

Platform Integration Architect

Checklist progress

0/170Learned

Platform Integration Architect

Study Checklist

  • Platform Administrator
  • Platform App Builder
  • Platform Foundations
  • Platform Developer
  • Platform Administrator II
  • Agentforce Sales Consultant
  • Agentforce Service Consultant
  • Platform Data Architect
  • Platform Development Lifecycle and Deployment Architect
  • Platform Identity and Access Management Architect
  • Platform Integration Architect
  • Platform Sharing and Visibility Architect
  • Heroku Architect
  • B2C Solution Architect
  • Experience Cloud Consultant
  • Agentforce Field Service and Operations Consultant
  • Agentforce Nonprofit Consultant
  • Data 360 Consultant
  • Omnistudio Consultant
  • CRM Analytics and Einstein Discovery Consultant
  • Platform User Experience Designer
  • Platform Strategy Designer
  • B2C Commerce Developer
  • JavaScript Developer
  • Omnistudio Developer
  • Platform Developer II
  • Marketing Cloud Engagement Administrator
  • Marketing Cloud Engagement Specialist
  • Marketing Cloud Engagement Consultant
  • Agentforce Sales Foundations
  • Business Analyst
  • Marketing Cloud Engagement Developer
  • Marketing Cloud Engagement Foundations
  • Agentforce Specialist
  • Agentforce Life Sciences Consultant
  • B2B Commerce Administrator AP
  • B2B Commerce Developer AP
  • Agentforce Consumer Goods AP
  • Agentforce Financial Services AP
  • Agentforce Health AP
  • Agentforce Manufacturing AP
  • MuleSoft Integration Foundations
  • MuleSoft Developer
  • MuleSoft Developer II
  • MuleSoft Platform Integration Architect
  • MuleSoft Platform Architect
  • Tableau Desktop Foundations
  • Tableau Data Analyst
  • Tableau Consultant
  • Tableau Server Administrator
  • Tableau Architect

Checklist progress

0/170Learned

  • Identifying integration standards (REST vs SOAP vs event-driven) and protocol constraints when analyzing an existing multi-system landscape
  • Recognizing legacy system protocols (SOAP/XML, EDI, flat file) and determining interoperability requirements when modernizing integrations
  • Mapping an existing system landscape to identify the canonical data model used across systems and where data format mismatches require transformation
  • Differentiating between synchronous and asynchronous integration boundaries and when each is mandated by existing system constraints
  • Identifying firewall, network boundary, and DMZ constraints that affect inbound vs outbound integration choices
  • Determining which Salesforce platform limits (API call limits, governor limits, concurrent request limits) constrain an integration design given a system landscape
  • Identifying Salesforce org topology constraints (multi-org, sandbox, production, Government Cloud) that affect integration architecture decisions
  • Analyzing tight coupling pain points in point-to-point integrations and recommending architectural improvements using middleware or an ESB
  • Identifying data duplication and synchronization conflicts as integration pain points when multiple systems hold the same data (system of record ambiguity)
  • Identifying data latency and throughput bottlenecks in an existing integration landscape that prevent real-time synchronization requirements from being met
  • Recognizing Salesforce API limit consumption as a constraint when multiple existing integrations share the same org's daily API allocation
  • Assessing on-premise vs cloud system hosting as a landscape constraint that determines whether a Salesforce-hosted integration (callouts) or hybrid middleware (MuleSoft on-prem, Mule Gateway) is required
  • Identifying the absence of event-driven capability in existing point-to-point integrations as a scalability pain point and assessing the migration path to pub/sub architecture
  • Choosing between user-level OAuth (user context) and system-level OAuth (service account / client credentials) based on integration data access requirements
  • Selecting OAuth 2.0 Web Server flow when a user-context integration requires browser redirect for third-party app access
  • Selecting OAuth 2.0 JWT Bearer flow for server-to-server integrations where no user interaction is possible
  • Selecting OAuth 2.0 Client Credentials flow for system-level integrations that use a service account
  • Determining OAuth scopes for a Connected App based on integration data access needs and principle of least privilege
  • Determining OAuth policies (IP relaxation, admin-approved users, refresh token) for Connected App security in inbound integrations
  • Evaluating when to use Named Credentials vs hardcoded credentials vs externally managed secrets for outbound callout authentication
  • Configuring IP restrictions for inbound integration access to enforce network-level security requirements
  • Evaluating SAML-based SSO vs OAuth for authentication when integrating Salesforce with an enterprise identity provider (IdP)
  • Determining when certificate-based authentication (mTLS) is required by existing system security standards and how Salesforce stores and uses X.509 certificates for outbound connections
  • Distinguishing functional integration requirements (data transformation rules, business process triggers) from non-functional requirements (latency SLAs, availability, scalability)
  • Translating business SLA requirements (e.g., data must sync within 15 minutes) into technical integration pattern selection criteria
  • Recognizing idempotency as a non-functional requirement and its implications for integration design (duplicate message handling)
  • Identifying availability and disaster recovery requirements that dictate integration architecture choices (retry logic, failover, redundancy)
  • Identifying observability requirements (logging, tracing, alerting) as non-functional requirements that must be designed into the integration architecture from the start
  • Determining the maintainability and operational requirements (on-call runbooks, integration ownership, support SLAs) that influence build vs buy decisions for integration middleware
  • Classifying Salesforce data (PII, financial records, public marketing data) and applying appropriate integration security controls based on data classification
  • Determining transport security requirements (TLS version, mutual TLS, encryption at rest) based on data classification in an integration context
  • Identifying which data classification requires field-level masking, tokenization, or encryption before transmission to external systems
  • Determining data residency requirements based on data classification and how they constrain the geographic deployment of integration middleware
  • Identifying the need for a 360-degree customer view as a CRM success requirement and determining which external systems must be integrated to achieve it
  • Defining the system of record for each data domain as a foundational CRM integration requirement to prevent data conflicts
  • Identifying data quality requirements (completeness, accuracy, deduplication) as integration requirements critical to CRM adoption and success
  • Determining user experience requirements that mandate real-time vs near-real-time integration, particularly for sales reps accessing live data in Salesforce
  • Assessing data volume growth and new geographies as factors requiring scalable, multi-region integration solutions
  • Evaluating data residency constraints from GDPR, CCPA, and HIPAA in integration design
  • Evaluating data retention and cross-border transfer restrictions from regulations in integration design
  • Determining how industry-specific compliance mandates (financial services, healthcare) influence the choice between cloud-based and on-premise integration middleware
  • Assessing M&A requirements where newly acquired systems must be rapidly integrated with Salesforce

Given an existing system landscape diagram, create an inventory of the systems and integration patterns.

0/8

Mapping data flows between systems in a landscape to identify which integration patterns are in use and where gaps or risks exist

Learn this concept
Unseen

Identifying hub-and-spoke vs point-to-point integration topology from a landscape diagram and understanding the operational trade-offs of each

Learn this concept
Unseen

Identifying request-reply and fire-and-forget integration patterns from a system landscape diagram

Learn this concept
Unseen

Identifying batch and publish-subscribe integration patterns from a system landscape diagram

Learn this concept
Unseen

Identifying event-driven patterns (Platform Events, Change Data Capture, Streaming API) in a landscape diagram

Learn this concept
Unseen

Distinguishing event-driven integration patterns from polling-based integration patterns in a landscape diagram

Learn this concept
Unseen

Identifying process choreography integration patterns from a system landscape diagram

Learn this concept
Unseen

Classifying Salesforce-to-Salesforce (SF2SF) integration patterns in a multi-org landscape and identifying when the native SF2SF feature or external middleware is more appropriate

Learn this concept
Unseen

Given a use case and business process, evaluate system and process constraints.

0/6

  • Evaluating Salesforce governor limits (concurrent API requests, callout timeout limits, heap size) as architectural constraints that force asynchronous integration patterns
  • Evaluating transaction boundary constraints in Salesforce (trigger execution context, two-phase commit limitations) that prevent synchronous cross-system transactions
  • Evaluating Salesforce callout restrictions from synchronous Apex contexts (no callouts after DML in same transaction) as a constraint requiring an asynchronous workaround pattern
  • Assessing the 100-callout-per-transaction limit and other per-execution governor limits as constraints that shape the design of high-frequency integration triggers
  • Assessing external system rate limits and throttling policies as constraints that require queuing, backoff, or bulk integration approaches
  • Identifying process constraints such as approval workflows, business hours, and maintenance windows that affect integration scheduling and error handling design

Given a use case, identify integration security/authentication/authorization requirements.

0/6

  • Determining the correct integration user setup (dedicated integration user, profile, permission set) to enforce least-privilege access for automated integrations
  • Specifying OAuth 2.0 scopes required for a Connected App based on the integration's data access needs and principle of least privilege
  • Determining IP allowlisting requirements for external systems calling Salesforce APIs to prevent unauthorized inbound access
  • Translating data sensitivity requirements into Salesforce field-level security and sharing model constraints that integration user profiles must respect
  • Identifying mutual TLS (mTLS) requirements for high-security integrations and how Salesforce supports or requires certificate-based authentication
  • Identifying when SAML assertions must be passed through middleware to Salesforce for identity federation, and how the Salesforce identity provider and service provider roles are configured

Given a use case, identify performance needs (volumes, response times, latency) and propose appropriate integration solutions that will meet business requirements.

0/6

  • Recommending Bulk API vs REST API vs Composite API based on data volume, response time requirements, and Salesforce API limits
  • Understanding the Salesforce Bulk API 2.0 job lifecycle and when it is the appropriate choice over Bulk API 1.0 or REST Collections
  • Choosing between synchronous callouts and asynchronous queueable/batch jobs for high-volume integration scenarios to avoid Salesforce callout limits
  • Determining when Platform Events or Change Data Capture (CDC) meets near-real-time latency requirements better than polling-based REST API calls
  • Evaluating data virtualization (Salesforce Connect / External Objects) as an alternative to full data replication when low latency and read-only access to external data is required
  • Evaluating Heroku Connect as a data replication solution and when its eventual consistency model meets or conflicts with business latency requirements
  • Selecting the request-reply integration pattern for synchronous real-time data retrieval scenarios and understanding its latency and coupling trade-offs
  • Applying the Remote Process Invocation (Request-Reply) pattern when a remote process result is required before proceeding
  • Distinguishing fire-and-forget from request-reply and selecting fire-and-forget for long-running external processes where Salesforce does not need an immediate response
  • Contrasting Remote Process Invocation (Request-Reply) with fire-and-forget when no callback is needed from the remote process
  • Applying the batch data synchronization pattern when near-real-time is not required and operational impact must be minimized during off-hours
  • Choosing the publish-subscribe (pub/sub) pattern using Platform Events when decoupling producers and consumers is required for scalability
  • Choosing between Change Data Capture (CDC) and outbound messaging/workflow rules for event-driven outbound integration from Salesforce
  • Selecting the data virtualization (External Objects) pattern to surface external data inside Salesforce without replication and understanding when it is preferred over batch synchronization
  • Applying the process choreography pattern when a business process spans multiple systems and no central orchestrator is appropriate
  • Selecting the orchestration pattern using MuleSoft or a middleware layer when a single integration must coordinate multiple backend system calls
  • Identifying the UI Update or Remote Call-In pattern as appropriate when an external system needs to push updates into Salesforce without waiting for a Salesforce polling cycle
  • Specifying the components of a Salesforce outbound integration using Apex callouts (HttpRequest, named credentials, remote site settings, async vs sync context)
  • Selecting appropriate Salesforce integration components (External Services, Flow, Apex) for a low-code vs pro-code integration solution based on team skills and requirements
  • Identifying the components of an event-driven Salesforce integration using Platform Events (event producer, Platform Event definition, CometD subscriber, replay mechanism)
  • Defining the components of a MuleSoft-based integration (Anypoint Platform, API Gateway, Mule flows, connectors) and their roles in a Salesforce integration architecture
  • Defining the components of a Salesforce Connect (OData) integration: External Data Source, External Object, OData adapter, and how they surface external records in Salesforce
  • Defining the components of a Salesforce-to-Salesforce (SF2SF) integration: Connection objects, Subscription objects, published records, and the limitations of the native SF2SF feature
  • Defining the components required for a Heroku Connect integration solution (Heroku app, Postgres database, Heroku Connect add-on, mappings) and their responsibilities
  • Evaluating the trade-off between synchronous REST callouts (simplicity, immediate response) and asynchronous Platform Events (decoupling, scalability) for a given scenario
  • Identifying the Salesforce callout timeout limit (120 seconds) and its impact on synchronous integration patterns involving long-running external processes
  • Understanding the 50,000 Platform Events per hour org limit and how it constrains high-volume event-driven integration designs
  • Assessing the trade-offs between using Salesforce Connect (OData) for external data virtualization vs full data replication into Salesforce
  • Analyzing Heroku Connect replication lag and eventual consistency as trade-offs when near-real-time accuracy is required
  • Evaluating MuleSoft iPaaS cost and operational complexity trade-offs versus native Salesforce integration capabilities for simpler use cases
  • Evaluating the trade-offs of a native Salesforce-to-Salesforce (SF2SF) connection versus a middleware-brokered multi-org integration (data fidelity, error handling, SOQL relationship support)
  • Choosing the REST API vs SOAP API based on data format requirements, client capability, and integration complexity
  • Selecting the Bulk API 2.0 for high-volume data loads (greater than 2,000 records) and understanding its job-based asynchronous processing model
  • Applying the Composite API (composite resources, SObject Collections, composite graph) to reduce API call consumption for multi-record operations
  • Selecting Platform Events when custom event payloads and app-defined events are required for streaming
  • Selecting Change Data Capture when external systems must subscribe to Salesforce record changes via the Streaming API
  • Selecting PushTopic or Generic Streaming for SOQL-based subscription to record changes when custom event definitions are not needed
  • Choosing the Metadata API vs Tooling API for deployment and configuration automation use cases in CI/CD pipelines
  • Applying the GraphQL API (Salesforce) for flexible data querying to reduce over-fetching in mobile or external portal integrations
  • Applying API-led connectivity (system layer, process layer, experience layer) using MuleSoft to design a reusable integration architecture
  • Applying the OpenAPI Specification (OAS/Swagger) or RAML to define and document integration APIs, and how API-first design improves integration reliability and reuse
  • Applying data transformation standards (XSLT, DataWeave, JSON-to-JSON mapping) in integration middleware to translate between Salesforce's data model and external system schemas
  • Applying OAuth 2.0 JWT Bearer flow for server-to-server integrations where no user interaction is possible and a service account is required
  • Selecting an API gateway (MuleSoft API Manager, AWS API Gateway) as the security enforcement point for inbound Salesforce integration requests and understanding its rate limiting and policy application role
  • Applying HMAC or digital signature verification for validating the authenticity and integrity of inbound webhook payloads to Salesforce
  • Selecting message queuing (e.g., MuleSoft VM queues, external MQ) as a buffering technique to handle traffic spikes between systems with different processing rates
  • Designing a Salesforce-connected MuleSoft Anypoint Platform deployment model (CloudHub, on-premise, hybrid) and selecting the appropriate runtime based on data residency and network requirements
  • Designing Salesforce as an API provider: versioning strategy, resource URL design, authentication requirements, and rate limit exposure to consumers
  • Designing a custom REST API in Apex (@RestResource) as a Salesforce API provider and understanding its security, versioning, and governor limit considerations
  • Designing a Salesforce SOAP (WSDL-based) API provider and when to use the enterprise vs partner WSDL for external system consumption
  • Implementing Salesforce as an API consumer using Apex HttpCallout: handling callout limits, timeout configuration, and callout-from-trigger restrictions
  • Understanding the restriction that Apex callouts cannot be made after DML in the same transaction and the design patterns to work around it (Queueable, Platform Events)
  • Configuring External Services in Salesforce to register an external REST API and invoke it declaratively via Flow or Apex
  • Selecting Named Credentials for secure credential management in outbound callouts and understanding per-user vs org-wide named credential configurations
  • Choosing between synchronous Apex callouts, Queueable Apex with callout, and Platform Events for outbound integration based on transaction context and volume
  • Evaluating Salesforce outbound messaging (workflow-based) vs Apex callouts vs Platform Events for pushing Salesforce data changes to external systems
  • Implementing Salesforce Flow (Screen Flow, Autolaunched Flow, Scheduled Flow) as a declarative outbound integration mechanism via External Services or Apex actions
  • Understanding how Change Data Capture (CDC) enables external systems to subscribe to Salesforce record changes without polling, and when to prefer CDC over outbound messaging
  • Configuring Change Data Capture: selecting entities to track, understanding enriched payloads (changedFields, header metadata), and implementing header-based change filtering in subscribers
  • Applying bulk-safe Apex trigger patterns to prevent governor limit violations when integration volumes increase unexpectedly
  • Designing an integration solution to handle Salesforce API daily limit growth by distributing API usage across connected apps or using Bulk API for high-volume operations
  • Partitioning high-volume batch integration jobs using Batchable Apex with appropriate scope sizes and chained Queueable patterns to stay within execution limits at scale
  • Evaluating Platform Event delivery guarantees (at-least-once delivery) and designing idempotent consumers to handle duplicate events at scale
  • Using the ReplayId mechanism in Platform Events / Streaming API to recover from subscriber failures and replay missed events
  • Applying horizontal scaling principles in MuleSoft (multiple workers, clustering) to meet throughput requirements for high-volume Salesforce integrations
  • Designing Salesforce Connect (External Objects) custom adapters using Apex for scalable access to external systems not covered by standard OData adapters
  • Designing Heroku Connect mappings with appropriate polling intervals and field selection to balance synchronization frequency with Salesforce API consumption
  • Distinguishing system errors (network failure, timeout) from application errors (validation failure, business rule violation) in integration error handling
  • Applying appropriate error handling strategies for system errors (retry, timeout handling) versus application errors (validation feedback, business rule messaging) in integrations
  • Implementing retry logic with exponential backoff for transient failures in Apex callouts and external API integrations
  • Implementing idempotent upsert operations using Salesforce external IDs to safely reprocess failed records without creating duplicates
  • Designing Salesforce outbound messaging acknowledgment handling and what happens when the external endpoint does not acknowledge receipt
  • Handling partial success in Salesforce Bulk API jobs (allOrNone vs partial success) and determining appropriate error record handling strategies
  • Designing error notification and alerting in MuleSoft flows using error handlers, on-error-continue vs on-error-propagate, and routing errors to a dedicated monitoring channel
  • Designing dead-letter queue patterns for failed Platform Event processing or MuleSoft flows to prevent data loss without blocking the integration pipeline
  • Implementing compensating transactions or saga patterns in distributed integration scenarios where two-phase commit is not possible
  • Implementing OAuth 2.0 Web Server flow for inbound integrations where a third-party application accesses Salesforce data on behalf of a user
  • Applying Named Credentials with per-user authentication for outbound integrations that must maintain data access consistent with the running user's Salesforce permissions
  • Configuring Connected App admin-approved users only policy to restrict integration access to pre-authorized users
  • Configuring Connected App OAuth policies: IP relaxation when network constraints require it for integration access
  • Configuring Connected App refresh token policy (expiration, revocation) for integration token management
  • Configuring Salesforce as a SAML identity provider (IdP) for delegated authentication to external systems and understanding when Salesforce acts as the IdP vs service provider (SP)
  • Implementing certificate-based authentication (mutual TLS) for high-security outbound callouts and configuring the Salesforce certificate keystore
  • Configuring Salesforce Shield Platform Encryption for integration scenarios: impact on SOQL, Bulk API, and outbound data visibility when fields are encrypted
  • Implementing the OAuth 2.0 Device Flow for IoT or headless integrations where a browser redirect is not possible
  • Applying API versioning strategies in Salesforce integrations to prevent breaking changes when Salesforce deprecates older API versions
  • Using Custom Metadata Types or Custom Settings to externalize integration endpoint configuration, enabling environment-specific values to be deployed independently of Apex code
  • Designing a sandbox-to-production integration promotion strategy: managing Named Credentials, Connected App configurations, and endpoint URLs across environments
  • Designing integrations resilient to Salesforce seasonal releases by avoiding hard dependencies on API version-specific behaviors and using stable API endpoints
  • Designing for Salesforce maintenance windows: understanding sandbox refresh impacts, scheduled maintenance, and how to build integrations that gracefully handle temporary unavailability
  • Building integration test harnesses using Apex mock callouts (StaticResourceCalloutMock, HttpCalloutMock) to enable CI/CD pipeline testing without live external endpoints
  • Designing integration tests and monitoring that detect integration failures caused by Salesforce metadata changes (field removal, picklist changes, validation rules)
  • Implementing circuit breaker patterns in integration middleware to prevent cascading failures when a downstream system (Salesforce or external) is unavailable
  • Defining KPIs and thresholds for integration monitoring (throughput, error rate, latency, queue depth) and mapping them to Salesforce API usage dashboards
  • Monitoring Salesforce API limit consumption using the /limits endpoint and setting up alerts before daily limits are exhausted
  • Using Salesforce Event Monitoring (EventLogFile) to audit API usage, identify integration performance bottlenecks, and detect unauthorized access patterns
  • Defining MuleSoft Anypoint Monitoring dashboards and alerts to track flow execution times, error rates, and message volumes for Salesforce integrations
  • Implementing Platform Event subscriber health checks (delivery status, replay position) to detect and recover from stalled streaming consumers
  • Using Salesforce transaction security policies and real-time event monitoring to detect anomalous integration access patterns (unusual API volumes, off-hours access)
  • Defining escalation paths for integration failures: when to auto-retry, when to alert operations, and when to trigger manual intervention based on error classification
  • Designing outbound message retry behavior and understanding Salesforce's built-in retry for unacknowledged outbound messages (retries up to 24 hours)
  • Implementing Platform Event replay (using stored ReplayId or -2 for earliest) for recovery when a subscriber was offline and missed events
  • Designing recovery procedures for failed Bulk API jobs: partial success handling, error record reprocessing, and idempotent upsert strategies
  • Identifying Salesforce custom objects or platform tools (e.g., EventLogFile, custom logs) to capture integration execution history for reporting and troubleshooting
  • Using Salesforce Reports and Dashboards on custom integration log objects to give business stakeholders self-service visibility into integration health without requiring direct system access
  • Designing integration audit trail reports that capture message volumes, success/failure rates, and SLA compliance over time for stakeholder reporting
  • Defining reporting requirements that distinguish transient failures (auto-recovered) from persistent failures (requiring business escalation) in integration monitoring dashboards
  • Establishing integration governance reporting: tracking API consumer usage by connected app, enforcing rate limits per consumer, and providing capacity planning data to integration architects

Prepare for the Exam

Play Today's Certle
Back to track

Study Community

Ask questions and get the latest info from other Platform Integration Architect studiers. 593 members and growing.

Go to Discord

Classifying Salesforce-to-Salesforce (SF2SF) integration patterns in a multi-org landscape and identifying when the native SF2SF feature or external middleware is more appropriate

Explainer

Learn More

Practice Question

Keep going

Next conceptEvaluating Salesforce governor limits (concurrent API requests, callout timeout limits, heap size) as architectural constraints that force asynchronous integration patterns

Checklist progress

0/170 (0%)

0 of 170 concepts learned

Tip: You can filter concepts by status.

Prepare for the Exam

Play Today's Certle
Back to track

Study Community

Ask questions and get the latest info from other Platform Integration Architect studiers. 593 members and growing.

Go to Discord

Explainer

Salesforce-to-Salesforce (SF2SF) uses specific API objects to manage connections and share records between organizations. External middleware is required when integration needs involve distributed transactions, protocol conversion, or complex orchestration beyond Salesforce's native limits.

Core information
  • SF2SF connections are represented by the PartnerNetworkConnection object, which tracks status, type, and synchronization settings between organizations.
More details and nuances
  • Salesforce cannot participate in distributed transactions, so multi-system transactional integrity must be implemented at the middleware layer.