Three deployment patterns showing how API Manager policies are enforced for a Mule API, an API proxy, and Flex Gateway connected mode.
Mule API with API Gateway
The API Manager instance attaches policies that are enforced by API Gateway embedded in the runtime of the Mule application.
API Proxy Protecting a Non-Mule API
An API proxy deployed on Mule runtime receives API Manager policy configuration and forwards approved traffic to the protected API.
Flex Gateway Connected Mode Protecting a Non-Mule API
Flex Gateway runs outside Mule runtime, stays connected to API Manager, and enforces policies before routing to the protected API.
RTF and CH2 Deployment Process
02
The initial deployment sequence for Runtime Fabric and CloudHub 2.0.
Deployment Initiation
The sequence from the user upload to the creation of the initial application pod.
Kubernetes Architecture
The internal routing and architecture of the deployed application pod.
CloudHub 2.0 Connectivity Patterns
03
Four different architectural methods for connecting to applications within a CloudHub 2.0 Private Space.
1. Inbound External Clients
Routing for external clients connecting over the Internet, VPN, or Direct Connect (via Transit Gateway) to an application.
2. Outbound via AWS PrivateLink
An internal CloudHub 2.0 app connecting securely to an external customer AWS S3 bucket without traversing the public internet.
3. Intra-Private Space Communication
Communication paths between two apps in the same Private Space, showing both direct K8s DNS routing and loopback via Private Ingress.
4. Non-HTTP TCP Connection (HL7 MLLP)
An external client utilizing a VPN to connect to a non-HTTP TCP port exposed directly on the worker nodes via the Application Manager API.
Mutual TLS Context Exchange
04
Client and server keystore and truststore relationships for mutual TLS in Mule applications.
Transport Handshake Evolution
05
A three-step comparison of TLS 1.2, TLS 1.3, and HTTP/3 over QUIC connection setup.
TLS 1.2 Handshake
TLS 1.2 exchange showing the full handshake before application data is sent.
TLS 1.3 Handshake
TLS 1.3 exchange showing shorter handshake before data transmission.
HTTP/3 over QUIC
QUIC uses UDP in place of the TCP three-way handshake and combines transport and TLS 1.3 setup so encrypted application data can start after a single round trip.
OAuth 2.0 / OIDC
06
A compact walkthrough of the most common OAuth 2.0 and OIDC flows used across APIs and web apps.
Authorization Code Flow
User login and consent flow for a web app exchanging an auth code for tokens.
Client Credentials with Token Validation
Machine-to-machine token issuance with API gateway token validation against the auth server.
Client Credentials with JWT Claim Validation
Machine-to-machine flow where the gateway validates JWT claims locally instead of calling the auth server.
AnyPoint Platform SAML SSO
07
Browser-based SAML sign-on sequence between AnyPoint Platform and an external identity provider.
Data 360 LWC DMO Access Architectures
08
Architectural comparison of querying a Data 360 DMO, with each access pattern separated into its own scenario slide.
Scenario A: Home Org Native Query
An LWC in the home org queries the local Data Space through Apex using the native Data Cloud query API.
Scenario B: Different Org Integration
An LWC in a different org reaches the remote Data Space through an Apex HTTP callout to the Data 360 REST API.
Scenario C: Companion Org Native Query
An LWC in a companion org uses the same native Apex query path against a shared Data Space exposed to that org.
Identity Resolution: Unification Types
09
An overview of the four Identity Resolution unification types in Salesforce Data Cloud — Individual, Account, Lead, and Household — showing source DMO relationships, unified link objects, and resulting unified profiles for each pattern.
Individual Unification
The Individual DMO is the foundation of B2C identity resolution. Source records (Contacts, Subscribers, Shoppers) are matched via Contact Points and Party Identification, producing a Unified Individual and unified Contact Point objects connected through Unified Link bridge objects.
Account Unification
Account unification targets B2B use cases. The Account DMO is the primary object, matched using Party Identification (external IDs) and Contact Point Address or Phone. Each source Account record links 1:1 to a Unified Account via the Unified Link Account bridge, enabling account-based segmentation and activation.
Lead Unification
Leads do not have their own unified profile type — instead, CRM Lead records are harmonized to the Individual DMO alongside Contact records. Identity Resolution then resolves both into a single Unified Individual, collapsing prospect and known-customer records that represent the same person across systems.
Household Unification
Household unification groups Individual records that share a physical address into a single Household profile. Identity Resolution produces a Unified Household and Unified Link Household, with related Unified Individuals attached — enabling household-level segmentation for financial services, retail, and other family-unit use cases.
Zero Copy Integration: File vs. Query Federation
10
Comparison of File Federation and Live Query Federation in Salesforce Data 360, split into focused scenario slides.
File Federation
Data Cloud reads files directly from external table storage without routing queries through the warehouse compute layer.
Live Query Federation
Data Cloud pushes SQL down to the remote warehouse and receives only the computed result set back.