Cert++
  1. Home
  3. Platform Integration Architect

Platform Integration Architect

Checklist progressProgress

0/179Learned

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
  • Slack Administrator

Checklist progressProgress

0/179Learned

  • Inventorying systems, integration points and standards in the current landscape
  • Identifying the system of record and replication needs across a landscape
  • External system protocols versus Salesforce integration mechanisms
  • Network and transport boundaries for on-premise and legacy endpoints
  • Platform limits and allocations as landscape boundaries
  • Reusing existing ESB or ETL middleware versus point-to-point integrations
  • Swivel-chair work and stale data copies as landscape pain points
  • Conflicting sources of truth and duplicate records across systems
  • Daily API allocation pressure from existing integrations
  • Capacity and availability limits of legacy back-end systems
  • Transformation complexity in the integration layer
  • Isolating the decisive constraint in an existing integration landscape
  • External client apps versus connected apps for integration access
  • Server-to-server OAuth flow choice for inbound integrations
  • Legacy username-password and user-agent flows in an existing landscape
  • Login and session policies that protect integration accounts
  • Integrating Salesforce with an existing enterprise identity provider
  • Functional versus non-functional integration requirements
  • Integration type and architecture layer of a requirement
  • Transformation, orchestration and aggregation needs in an integration
  • Data freshness and SLA requirements as integration timing drivers
  • Response-wait requirements for the calling system or user
  • Data volume and message size as integration requirements
  • Error handling and recovery expectations as integration requirements
  • Idempotency and duplicate-message handling requirements
  • Maintainability and operational support requirements for integrations
  • Classifying integration data into Confidential, Secure and Public tiers
  • Field-level versus object-level classification of integration payloads
  • Transport protection for integrations carrying highly sensitive data
  • Carrying data classification across integration boundaries
  • Single customer view as a driver of integration scope
  • System of record and data quality in CRM integrations
  • Automating manual cross-system business processes
  • CRM success metrics and their reporting data needs
  • Historical data migration versus ongoing synchronization
  • Projected growth against API and event allocations
  • Org design factors that limit integration throughput at scale
  • Point-to-point versus middleware as the integration landscape grows
  • Acquisitions and multi-org growth in integration choice
  • Replication versus virtualization as data volumes and retention grow
  • Privacy and data residency regulations versus replicating personal data
  • Payment card data and PCI DSS scope in integration design
  • Audit and traceability obligations for integration activity
  • Data, process and virtual integration categories
  • UI, business process and data layers in a landscape inventory
  • Systems of record and source of truth in the inventory
  • Interface attributes to capture for each integration point
  • Integration direction and initiating system per interface
  • Point-to-point versus middleware-mediated connections
  • Classifying existing interfaces by Salesforce integration pattern
  • Existing integration mechanisms and the patterns they implement
  • System capabilities, failure handling and transactionality as process constraints
  • Tight versus loose coupling between process participants
  • Downtime and maintenance windows of process participants
  • Inbound API request allocations and concurrent request limits
  • Reaching on-premise systems behind a corporate firewall
  • Legacy protocols, file-based exchange and transformation constraints
  • Orchestrating multi-step processes across several systems
  • Shared integration identity versus per-user identity
  • Dedicated API-only integration users and least privilege
  • OAuth flows for user-facing web, mobile and device clients
  • Client app policies and scopes for inbound API access
  • Federated identity and a central IdP for API access
  • Mutual TLS and certificate requirements for integrations
  • Encryption requirements for sensitive integration data
  • Sizing volume, throughput and latency needs into an integration SLA
  • Synchronous versus asynchronous processing for response-time requirements
  • Near-real-time versus batch synchronization for data freshness needs
  • Data virtualization versus replication of external data
  • REST or SOAP API versus Bulk API 2.0 for inbound record volumes
  • Bulk load throughput planning and batch processing timeouts
  • Large data volume extract performance through the APIs
  • Reducing API round trips with Composite resources and GraphQL
  • Event-driven patterns for volume surges and multi-subscriber fan-out
  • Platform event and Change Data Capture delivery allocations
  • Middleware queuing and throttling to absorb volume spikes

Given a use case, identify the integration pattern that meets business requirements

0/11

Pattern timing, volume and direction as selection criteria

Learn this concept
Unseen

When to choose the Request and Reply pattern

Learn this concept
Unseen

When to choose the Fire and Forget pattern

Learn this concept
Unseen

When to choose the Remote Call-In pattern

Learn this concept
Unseen

UI Update Based on Data Changes pattern

Learn this concept
Unseen

When to choose Batch Data Synchronization

Learn this concept
Unseen

High-Frequency Data Replication versus batch synchronization

Learn this concept
Unseen

When to choose the Data Virtualization pattern

Learn this concept
Unseen

Publish/Subscribe pattern for notifying multiple subscribers

Learn this concept
Unseen

Event-driven architecture fit versus request-reply or batch patterns

Learn this concept
Unseen

Choosing among event-driven architecture patterns

Learn this concept
Unseen

Given a use case, define the components which create a solution that meets business requirements

0/10

  • Layer approach for mapping integration components
  • Middleware hub versus point-to-point integration
  • Components for a user-initiated synchronous callout
  • Asynchronous outbound components for fire-and-forget processing
  • Change Data Capture versus custom platform events for publishing changes
  • Salesforce Connect adapter selection for virtualized external data
  • Data integration tool selection by direction, licensing and landscape
  • UI-layer integration: Canvas, Lightning Out and mashups
  • Org-to-org integration options
  • Orchestration versus choreography and where orchestration lives

Given a use case, identify the trade-offs, limitations, and constraints that meet the proposed solution

0/10

  • Coupling, availability and exception-handling trade-offs
  • Synchronous callout timeouts and long-running request limits
  • Trigger-initiated callouts and asynchronous Apex trade-offs
  • Outbound messaging delivery, endpoint security and limitations
  • Event bus allocations, add-ons and retention windows
  • Change Data Capture entity limits and gap or overflow events
  • Data virtualization versus data replication trade-offs
  • Large data volume constraints in batch synchronization
  • API request allocations versus hard governor limits
  • Transactional integrity and compensation across integrated systems

Given a use case that includes technical requirements, constraints, or drivers, specify the appropriate Salesforce application programming interface(s) (API) for the proposed solution

0/10

  • Protocols, data formats and communication modes of Salesforce APIs
  • API planning framework for choosing Salesforce APIs
  • REST API versus SOAP API for inbound record operations
  • Bulk API 2.0 versus composite and synchronous APIs by data volume
  • Bulk API 2.0 versus the original Bulk API
  • When to use GraphQL API for client-driven data retrieval
  • User Interface, Connect REST and Analytics REST APIs
  • Custom Apex REST or SOAP web services versus standard data APIs
  • Pub/Sub API versus Streaming API for external event subscribers
  • Metadata API versus Tooling API for metadata integrations

Given a use case that includes technical requirements, constraints, or drivers, determine the standards, components, techniques, and security mechanism that should be used

0/5

  • Named Credentials and External Credentials for outbound callouts
  • Network connectivity security for on-premises and private cloud systems
  • Data classification driving protection of integration data
  • Shield Platform Encryption choices for integrated data
  • State management and cross-system record keys
  • Salesforce as API provider versus API consumer
  • Enterprise WSDL, Partner WSDL and REST API for remote callers
  • Inbound event notification through platform event publishing
  • Request and Reply versus Fire and Forget for outbound calls
  • SOAP web service callouts versus HTTP callouts
  • External Services and Flow HTTP Callout for low-code outbound calls
  • Asynchronous Apex callouts versus platform events at scale
  • Middleware versus point-to-point callouts from Salesforce
  • Outbound data sync tool choice by timing, direction and licensing
  • Daily API request allocation across multiple integrations
  • When asynchronous processing suits a scalable integration
  • Long-running synchronous callouts and concurrent request limits
  • Automation and sharing overhead on high-volume inbound loads
  • Record locking, data skew and integration governance
  • Peak-load headroom and realistic-volume scale testing
  • Error handling and recovery in Request and Reply callouts
  • Error handling and recovery in Fire and Forget integrations
  • Error handling responsibility in Remote Call-In integrations
  • Partial success versus all-or-none behavior for inbound API calls
  • Error handling and recovery in Batch Data Synchronization
  • Retry, notify and fail requirements in integration tool choice
  • OAuth flow selection for inbound system-to-system integrations
  • Compensating login controls for API-only integration accounts
  • Data access enforcement for standard APIs versus custom Apex web services
  • Named principal versus per-user principal for authenticated callouts
  • Protecting classified data sent from Salesforce to external systems
  • Private Connect for Salesforce and AWS integration traffic
  • Loose coupling to absorb upgrades in connected systems
  • Delivery guarantees and data integrity while a target system is offline
  • Circuit breakers and graceful degradation for unavailable endpoints
  • Protecting integrations through Salesforce seasonal releases
  • Salesforce maintenance windows and instance moves
  • Integration SLIs and SLOs derived from business requirements
  • Monitoring and reporting API consumption against org allocations
  • Monitoring Bulk API jobs and asynchronous Apex processing
  • Integration latency percentiles and per-step transaction timing
  • Scale Center versus Proactive Monitoring for integration load health
  • Correlation IDs and contextual logging for cross-system tracing
  • Layered detection of integration failures before users report them
  • Error handling, transactionality and recovery by integration pattern
  • Recovery actions for different integration error categories
  • Exception capture and IT operations alerting for failed integrations
  • Flow fault paths versus default flow failure handling for callouts
  • Outbound message retry behavior and failed delivery queue
  • Middleware queuing and dead-letter handling for undeliverable messages
  • Event subscriber recovery with replay IDs and event retention
  • Change Data Capture gap and overflow event recovery
  • Bulk-proof backlog recovery after integration downtime
  • Escalation paths, runbooks and post-incident review for integration incidents
  • Custom integration log object versus record-level sync status fields
  • Platform event logging versus direct DML under transaction rollback
  • Event Monitoring event types for API and integration activity
  • Event log file delivery timing, retention and durability
  • Event Monitoring Analytics App versus external log aggregation
  • Audit reporting on data changes made by integration users
  • Business-flow success reporting versus component health metrics
  • Real-time alerting versus scheduled reports for integration monitoring

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. 662 members and growing.

Go to Discord
  1. Platform Integration Architect Checklist
  3. Design Integration Solutions

When to choose the Fire and Forget pattern

Explainer

Learn More

Practice Question

Keep going

Next conceptWhen to choose the Remote Call-In pattern

Checklist progress

0/179 (0%)

0 of 179 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. 662 members and growing.

Go to Discord
Close
  1. Platform Integration Architect Checklist
  3. Design Integration Solutions
When to choose the Fire and Forget pattern

Explainer

Learn More

Practice Question

Keep going

Next conceptWhen to choose the Remote Call-In pattern

Explainer

Fire and Forget is a Remote Process Invocation pattern for starting a process in a remote system when something happens in Salesforce, without Salesforce waiting for that process to finish. Salesforce hands off the message and moves on. If needed, the remote system can update Salesforce later in a separate transaction. Choose it when another system does the real work (for example, an ERP that processes orders) and Salesforce does not need the result right away.
Core information
  • Fire and Forget answers this question: when an event occurs in Salesforce, how do you start a process in a remote system and pass it the data it needs without waiting for a response? For example, Salesforce captures order details, but a remote system creates and manages the order. Salesforce calls the remote system to create the order and does not wait for the call to complete.
More details and nuances
  • Outbound messaging retries automatically when it gets no positive acknowledgment within the timeout period. It keeps retrying for up to 24 hours, and the retry interval grows exponentially from 15 seconds to 60 minutes. Salesforce support can extend the timeout period to seven days, but automatic retries still stop at 24 hours. After that, failed messages go into a queue that administrators must monitor and retry by hand if needed.

Explainer

Fire and Forget is a Remote Process Invocation pattern for starting a process in a remote system when something happens in Salesforce, without Salesforce waiting for that process to finish. Salesforce hands off the message and moves on. If needed, the remote system can update Salesforce later in a separate transaction. Choose it when another system does the real work (for example, an ERP that processes orders) and Salesforce does not need the result right away.
Core information
  • Fire and Forget answers this question: when an event occurs in Salesforce, how do you start a process in a remote system and pass it the data it needs without waiting for a response? For example, Salesforce captures order details, but a remote system creates and manages the order. Salesforce calls the remote system to create the order and does not wait for the call to complete.
More details and nuances
  • Outbound messaging retries automatically when it gets no positive acknowledgment within the timeout period. It keeps retrying for up to 24 hours, and the retry interval grows exponentially from 15 seconds to 60 minutes. Salesforce support can extend the timeout period to seven days, but automatic retries still stop at 24 hours. After that, failed messages go into a queue that administrators must monitor and retry by hand if needed.