Clouds, Products & Licensing: What Every CTA Must Know

This guide categorizes every Salesforce cloud, product, and platform capability by how critical it is for the CTA Review Board. It is based on analysis of the official CTA exam guide, 27+ publicly available mock scenarios, community accounts from CTAs who passed, and current (2025-2026) Salesforce platform documentation.

Tier 1: Must-Know Clouds and Products

These appear in virtually every CTA scenario. You must understand their architecture deeply, know their limits, and be able to justify when and why to use them.

Sales Cloud

Why it matters: Nearly every CTA scenario involves a sales process. Even scenarios focused on service or partner management include pipeline, forecasting, or territory requirements.

Aspect	What to Know
Core objects	Leads, Accounts, Contacts, Opportunities, Products, Price Books, Quotes
Key features	Territory Management (Enterprise vs. Original), Forecasting, Collaborative Forecasting, Lead Assignment Rules, Web-to-Lead, Sales Path, Sales Engagement
Automation	Opportunity Splits, Big Deal Alerts, Forecast Categories, Lead Scoring
Limits	15 territory models (1 active), 500 assignment rules per object, Forecast Hierarchy tied to Role Hierarchy
Licensing	Requires Salesforce or Sales Cloud user license; Enterprise ($175/user/mo), Unlimited ($350/user/mo)
Integration points	ERP (order-to-cash), CPQ tools, marketing automation, territory data from external systems
CTA scenario patterns	Multi-region sales teams, channel/partner sales, complex pricing, M&A consolidation of sales processes

Review Board Pattern

Judges frequently ask about Territory Management — specifically why you chose Enterprise Territory Management over the original model, and how territories interact with the sharing model and forecasting. Know the architectural implications of each.

Service Cloud

Why it matters: Customer service requirements appear in the vast majority of scenarios. Self-service portals, case management, and omnichannel routing are common requirements.

Aspect	What to Know
Core objects	Cases, Entitlements, Service Contracts, Knowledge Articles, Milestones
Key features	Omni-Channel Routing (queue-based, skills-based), Case Assignment Rules, Escalation Rules, Knowledge Base, Macros, Service Console
Advanced features	Entitlement Processes, Milestone Tracking, Service-Level Agreements (SLA enforcement), Live Agent / Messaging
Limits	3,000 assignment rules, 5 active escalation rules per object, Knowledge article types and data categories
Licensing	Service Cloud user license; same tier pricing as Sales Cloud
Integration points	CTI (telephony), chat/messaging platforms, knowledge systems, field service dispatch, customer portals
CTA scenario patterns	Multi-channel support, SLA management, knowledge-centered service, tiered support models, self-service deflection

Architectural Decision

A common CTA question is when to use Omni-Channel Skills-Based Routing versus Queue-Based Routing. Skills-based routing provides more granular agent matching but adds configuration complexity. Your choice should be justified by the scenario’s support model complexity.

Experience Cloud (Communities)

Why it matters: Experience Cloud appears in the majority of CTA scenarios. External user access — customer portals, partner portals, dealer networks, self-service — is a recurring theme that touches security, licensing, data access, and identity.

Aspect	What to Know
Site types	Customer Service (self-service), Partner Central (channel management), custom (LWC/Aura-based)
Key features	Templates, Guest User access, Content Management, Moderation, Reputation, Topics, Delegated Administration
Security model	External sharing model (separate OWD for external users), Sharing Sets, Sharing Groups, External Role Hierarchy
Authentication	Social Sign-On, SAML SSO, custom login flows, self-registration, passwordless login
Limits	100 active sites per org, Guest User profile restrictions (post-Spring ‘20 security hardening), limited standard object access on lower-tier licenses
License types	Customer Community, Customer Community Plus, Partner Community, External Apps, Channel — see #Experience Cloud Licenses below
Integration points	CMS, identity providers, external content, headless Experience Cloud via APIs
CTA scenario patterns	Partner/dealer portals with shared Opportunities, customer self-service with case creation, multi-tier community access, B2B2C models

Critical for CTA

Experience Cloud licensing is one of the most common areas where CTA candidates lose points. You MUST know the difference between Customer Community and Customer Community Plus licenses (role-based sharing, standard object access, reporting capabilities), and you must be able to calculate cost trade-offs between member-based and login-based licensing. See #Experience Cloud Licenses for the full breakdown.

Core Platform (Salesforce Platform)

Why it matters: The platform itself underpins everything. Every CTA scenario requires you to demonstrate deep understanding of platform capabilities, limits, and constraints. This is not a “product” you recommend — it is the foundation every recommendation sits on.

Capability Area	What to Know
Metadata-driven architecture	Multi-tenant model, governor limits rationale, metadata API, Tooling API
Declarative automation	Flow (Record-Triggered, Screen, Scheduled, Platform Event-Triggered, Autolaunched), Flow Orchestrator, Approval Processes
Programmatic	Apex (triggers, batch, queueable, schedulable, future), LWC, Aura, Visualforce, Apex REST/SOAP
Data platform	SOQL/SOSL, Big Objects, External Objects, Platform Events, Change Data Capture, Custom Metadata Types
Security	Profiles, Permission Sets, Permission Set Groups, OWD, Role Hierarchy, Sharing Rules, Criteria-Based Sharing, Apex Managed Sharing
Identity	SSO (SAML, OAuth), Connected Apps, Named Credentials, Auth Providers, My Domain, Login Flows
APIs	REST, SOAP, Bulk, Streaming, Metadata, Tooling, Composite, GraphQL
Limits	See #Governor Limits Every CTA Must Know

Tier 2: Frequently Tested Products

These products appear in many CTA scenarios but are not guaranteed in every one. You should know WHEN to recommend them, their trade-offs, and viable alternatives.

Marketing Cloud (SFMC)

When to recommend: The scenario describes mass email campaigns (exceeding Salesforce limits of 5,000 daily mass emails), journey orchestration across channels (email + SMS + push + ads), or sophisticated segmentation/personalization needs.

Aspect	Details
Core capabilities	Email Studio, Journey Builder, Automation Studio, Mobile Studio, Advertising Studio, Content Builder
Architecture	Separate platform from core Salesforce — different data model, separate login, Marketing Cloud Connector for sync
Key limitation	NOT native to the Salesforce platform; requires Marketing Cloud Connector or API integration to sync data
Integration pattern	Marketing Cloud Connector syncs Contacts/Leads/custom objects bidirectionally; API for real-time triggers
When NOT to recommend	Simple email needs (use Salesforce native email), single-channel marketing, budget-constrained orgs
Alternatives	Salesforce native email, Pardot/Marketing Cloud Account Engagement (B2B), third-party SMTP integration, Mailchimp

CTA Scenario Approach

If a scenario mentions “mass communications” or “email campaigns beyond current limits,” you do NOT have to jump straight to Marketing Cloud. Acknowledge it as an option, but also propose lighter alternatives (integrated SMTP, Account Engagement for B2B). Judges value seeing that you considered cost and complexity trade-offs.

Data Cloud (Data 360)

When to recommend: The scenario requires Customer 360 unification across multiple data sources, real-time segmentation, identity resolution across systems, or a unified data layer for AI/analytics.

Aspect	Details
Core capabilities	Data ingestion, identity resolution, unified profiles, segmentation, activation, calculated insights
Architecture	Runs on Salesforce infrastructure with its own data model (Data Model Objects / DMOs); zero-copy federation with Snowflake, Databricks, BigQuery, Redshift
Key 2025-2026 updates	Renamed to “Data 360” at Dreamforce 2025; now the core intelligence layer for Agentforce; Tableau Semantics integration; AI-driven governance
Multi-org implications	Can connect up to 5 Salesforce Core orgs and 1 Marketing Cloud org per Data Cloud instance — important constraint for multi-org strategies
When NOT to recommend	Simple single-org setups with no external data unification needs; budget constraints (consumes credits)
Alternatives	MDM tools, custom integration layer, ETL-based data warehouse

Emerging Capability

Data Cloud / Data 360 is the fastest-evolving part of the Salesforce platform. As of 2025-2026, it is increasingly central to Salesforce’s strategy (powering Agentforce, Tableau, and cross-cloud analytics). CTA candidates should understand its architectural role even if they do not recommend it in every scenario.

MuleSoft

When to recommend: The scenario describes complex enterprise integration landscapes with many systems (ERP, HRIS, billing, legacy), API lifecycle management requirements, or the need for a reusable integration layer (API-led connectivity).

Aspect	Details
Core capabilities	Anypoint Platform, API Manager, Runtime Manager, Design Center, Anypoint Exchange, CloudHub/Runtime Fabric
Architecture pattern	API-led connectivity: System APIs -> Process APIs -> Experience APIs
Key strength	Enterprise-grade iPaaS; manages the full API lifecycle; reusable integration assets; supports any-to-any integration (not just Salesforce)
Licensing model	Separate from Salesforce licensing; priced by vCore and API call volume
When NOT to recommend	Simple point-to-point integrations, small number of systems, budget constraints, when native Salesforce integration (APIs, Platform Events, Salesforce Connect) suffices
Alternatives	Native Salesforce APIs + Named Credentials, Salesforce Connect (OData), Informatica, Dell Boomi, Workato, custom middleware

CTA Decision Framework

The key question judges will ask: “Why MuleSoft and not native Salesforce integration?” Your answer must demonstrate that you evaluated native options first (Platform Events, Change Data Capture, REST APIs, Salesforce Connect) and justified the additional cost and complexity of MuleSoft based on the scenario’s integration complexity, number of systems, reusability requirements, and API governance needs.

Heroku

When to recommend: The scenario requires custom application logic that cannot run on the Salesforce platform due to governor limits, language requirements (Node.js, Python, Java, Ruby), consumer-facing web applications with high traffic, or heavy computational processing.

Aspect	Details
Core capabilities	PaaS for custom apps, Heroku Connect (bidirectional Salesforce sync), Heroku Postgres, Heroku Redis, add-on ecosystem
Key strength	No governor limits; any programming language; scales horizontally; Heroku Connect provides near-real-time Salesforce data sync
Pricing model	Dyno-based (compute) + add-ons; Heroku Connect pricing based on record count synced
When NOT to recommend	When the workload can run on Salesforce (Apex, Flow, LWC); when MuleSoft already handles the integration layer; when the org prefers AWS/Azure/GCP directly
Alternatives	AWS Lambda + API Gateway, custom apps on any cloud provider, Salesforce Functions (deprecated — use Heroku or external services)
Integration pattern	Heroku Connect for data sync, REST APIs for real-time, Platform Events for event-driven

Heroku vs. MuleSoft

A frequent CTA question: “When would you use Heroku versus MuleSoft?” MuleSoft connects systems (integration middleware, API management). Heroku runs applications (custom compute, custom UI, processing). They are complementary, not competing. For high-volume data synchronization, compare Heroku Connect (priced per record count) against MuleSoft Anypoint Connector (priced per API call/vCore) based on the scenario’s data volumes.

Tableau / CRM Analytics

When to recommend: The scenario requires advanced analytics beyond native Salesforce reports and dashboards — cross-system data visualization, predictive analytics, embedded analytics, or executive dashboards aggregating data from multiple sources.

Tool	Best For	Key Consideration
Salesforce Reports & Dashboards	Operational reporting on CRM data; users who live in Salesforce	Free with CRM license; limited to Salesforce data; max 2,000 report rows displayed
CRM Analytics (fka Tableau CRM / Einstein Analytics)	Advanced analytics embedded inside Salesforce; AI-powered predictions on CRM data	Requires CRM Analytics license; deeply integrated with Salesforce UI; limited to Salesforce ecosystem data
Tableau	Enterprise BI across all data sources; power users and data analysts	Separate platform; connects to any data source; requires Tableau license; steeper learning curve

CTA Reporting Strategy

When a scenario mentions “executive dashboards” or “cross-system reporting,” propose a tiered approach: native Reports & Dashboards for operational users, CRM Analytics for embedded Salesforce analytics, and Tableau for cross-enterprise BI. Judges value seeing you match the reporting tool to the user persona and data source.

Tier 3: Awareness-Level Products

You do NOT need deep expertise in these for the CTA exam. However, you should know what they do, when an architect would consider them, and their high-level trade-offs. If you recommend one in your solution, judges will probe your understanding.

Commerce Cloud

What it does: B2C and B2B ecommerce storefronts
CTA relevance: Appears in retail/ecommerce scenarios; most CTA scenarios do NOT require it
Key knowledge: Separate platform (B2C Commerce was Demandware acquisition); B2B Commerce runs on core Salesforce platform; different data models and integration patterns for each
Architect consideration: If the scenario mentions online storefronts or order management, acknowledge Commerce Cloud but evaluate whether the complexity is warranted versus simpler solutions

Industries Clouds (Financial Services, Health, Manufacturing, etc.)

What they do: Pre-built data models, processes, and UIs for specific verticals
CTA relevance: Rarely required in CTA scenarios; scenarios are industry-agnostic by design
Key knowledge: Built on core platform with industry-specific managed packages; introduce additional objects and automation; licensing is additive
Architect consideration: Only recommend if the scenario explicitly describes industry-specific requirements that align perfectly with an Industries Cloud’s pre-built capabilities

CPQ (Configure, Price, Quote)

What it does: Complex product configuration, pricing rules, guided selling, quote generation
CTA relevance: Occasionally appears in scenarios with complex pricing; not a core CTA topic
Key knowledge: Runs on core platform as a managed package; introduces its own object model (Quote Lines, Price Rules, Product Rules); has its own governor-like limits; requires CPQ license
Architect consideration: Recommend when the scenario describes product bundling, volume discounting, tiered pricing, or complex quoting workflows

Field Service (Lightning)

What it does: Mobile workforce management, scheduling, dispatch, work orders
CTA relevance: Appears in scenarios with mobile field workers; understand at a conceptual level
Key knowledge: Built on Service Cloud; introduces Work Orders, Service Appointments, Service Territories, Scheduling Optimization; requires Field Service license
Architect consideration: Key for scenarios with technicians, inspectors, or field-based service delivery; offline mobile capability is a differentiator

Slack

What it does: Team collaboration, channels, workflows, integration hub
CTA relevance: Low direct relevance but increasingly part of Salesforce ecosystem
Key knowledge: Slack-to-Salesforce integration via Slack Connect, Workflow Builder, Salesforce for Slack app
Architect consideration: Mention as a collaboration layer if the scenario emphasizes cross-team communication or real-time notifications

Platform Capabilities Every CTA Must Master

These are core platform features that cut across every scenario and every domain. Weakness in any of these areas will be caught during Q&A.

Automation: Flow and Process Automation

flowchart TD
    REQ[Automation Requirement] --> COMPLEX{Complex multi-step?}
    COMPLEX -->|Yes| ORCH[Flow Orchestrator]
    COMPLEX -->|No| TRIGGER{Trigger-based?}
    TRIGGER -->|Record change| RFLOW[Record-Triggered Flow]
    TRIGGER -->|Schedule| SFLOW[Scheduled Flow]
    TRIGGER -->|Platform Event| PEFLOW[Platform Event-Triggered Flow]
    TRIGGER -->|User interaction| SCREEN[Screen Flow]
    TRIGGER -->|No trigger| AUTO[Autolaunched Flow]

    RFLOW --> ENOUGH{Declarative sufficient?}
    ENOUGH -->|No| APEX[Apex Trigger/Class]
    ENOUGH -->|Yes| DONE[Deploy Flow]

    ORCH --> STAGES[Multi-stage with assignments]
    STAGES --> SLA{SLA tracking needed?}
    SLA -->|Yes| ORCH_FULL[Flow Orchestrator with Milestones]
    SLA -->|No| SUBFLOW[Orchestrator with Subflows]

Capability	When to Use	Key Limits
Record-Triggered Flow	Automate on record create/update/delete	No hard element cap (API v57.0+); constrained by CPU time limits; watch for recursive triggers
Screen Flow	Guided user input, wizards, multi-step forms	Subject to same transaction limits as any flow
Scheduled Flow	Batch processing, timed actions	250,000 records per batch; 24-hour minimum interval
Platform Event-Triggered Flow	React to event bus messages	Separate transaction from publishing context
Flow Orchestrator	Multi-step, multi-user business processes	Steps run in separate transactions; supports parallel stages
Approval Processes	Structured approval chains	30 steps per process; limited conditional logic
Apex Triggers	Complex logic beyond declarative capability	All governor limits apply; order of execution matters

Anti-Pattern

Do NOT recommend publishing Platform Events from Flow solely to trigger another Flow in the same org for orchestration purposes. This is a documented anti-pattern. Use subflows or Flow Orchestrator instead. Judges will call this out.

Event-Driven Architecture: Platform Events and Change Data Capture

Feature	Purpose	Key Characteristics
Platform Events	Custom event messaging (pub/sub)	Define custom event schema; publish from Apex, Flow, API; subscribe via triggers, Flow, CometD/Pub/Sub API; replay up to 72 hours
Change Data Capture (CDC)	Broadcast record changes to subscribers	Automatically publishes changes for selected objects; subscribers receive create/update/delete/undelete events; uses the same event bus
Pub/Sub API	gRPC-based event subscription (replaces CometD)	Higher throughput; supports both Platform Events and CDC; recommended for new implementations

Architect Decision

Platform Events are for custom business events (“Order Shipped,” “Approval Completed”). CDC is for replicating data changes to external systems. Do not use CDC as a substitute for integration middleware — it broadcasts all changes, which can create high message volumes that external systems must filter.

Governor Limits Every CTA Must Know

You do not need to memorize every number, but you must understand the categories, why they exist (multi-tenant fairness), and how they influence architecture decisions.

Limit Category	Key Numbers	Architectural Impact
SOQL queries	100 per synchronous transaction; 200 per async	Drives bulkification patterns; influences data model (denormalization vs. normalization)
DML statements	150 per transaction	Limits cascading updates; influences trigger design
Heap size	6 MB sync; 12 MB async	Constrains in-memory processing; drives batch Apex for large datasets
CPU time	10,000 ms sync; 60,000 ms async	Complex calculations may need async processing or Heroku offload
Callouts	100 per transaction; 120-second timeout	Influences integration pattern (sync vs. async); drives use of queueable chaining
API daily limits	Based on edition and license count (Enterprise: 100,000 base + per-license)	Drives decisions about integration frequency, batch vs. real-time, Bulk API usage
Bulk API	15,000 batches/24hr; 10,000 records per batch (Bulk 2.0 handles this automatically)	Critical for data migration and high-volume integrations
Storage	Data storage per license (varies by edition); File storage (10 GB org + per-license)	Drives archival strategy, LDV decisions, external storage for files
Custom objects	200 (Enterprise); 2,000 (Unlimited/Performance)	Influences managed package considerations and data model complexity
Sharing rules	300 total per object (up to 50 criteria-based; no separate ownership-based sub-limit)	Influences sharing model design; may require Apex Managed Sharing for complex needs

This is one of the deepest areas judges probe. You must be able to design a complete sharing model for a complex scenario.

flowchart TD
    START[Record Access Need] --> OWD[Set Organization-Wide Defaults]
    OWD --> MOST{Most restrictive base?}
    MOST -->|Private| OPEN[Open access via...]
    MOST -->|Public Read/Write| RESTRICT[Restrict via... very limited options]

    OPEN --> RH[Role Hierarchy]
    OPEN --> SR[Sharing Rules]
    SR --> OB[Owner-Based]
    SR --> CB[Criteria-Based]
    OPEN --> MS[Manual Sharing]
    OPEN --> AMS[Apex Managed Sharing]
    OPEN --> TEAM[Account/Opp/Case Teams]
    OPEN --> TM[Territory Management]

    RH --> EXT{External users?}
    EXT -->|Yes| EXTSHARE[Sharing Sets + External OWD]
    EXT -->|No| DONE[Sharing Model Complete]

Key concepts a CTA must articulate:

OWD (Organization-Wide Defaults): Always start here. Set the most restrictive default, then open up.
Role Hierarchy: Opens access upward. Understand “Grant Access Using Hierarchies” toggle.
Sharing Rules: Owner-based (up to 300) and Criteria-based (up to 300 per object). Know performance implications at scale.
Apex Managed Sharing: For sharing logic too complex for declarative rules. Understand the __share object and rowCause.
External sharing model: Separate OWD for external users. Sharing Sets for Experience Cloud users without roles. Sharing Groups.
Implicit sharing: Account-contact, parent-child, portal user access patterns.
Performance at scale: Large numbers of sharing rules or Apex Managed Sharing records can impact record access calculation time. Know the “group maintenance” implications.

Identity, SSO, and Access Management

Capability	Use Case	Protocol
SAML SSO	Enterprise SSO with corporate IdP (Okta, Azure AD, ADFS)	SAML 2.0
OAuth 2.0	API authentication, connected app authorization	OAuth 2.0 (multiple flows: Web Server, JWT Bearer, Device, Refresh Token)
OpenID Connect	Social login, external identity provider	OIDC
Named Credentials	Secure callout authentication (no hardcoded creds)	Supports OAuth, JWT, password, AWS Signature
Connected Apps	Govern API access, SSO entry points, manage policies	OAuth + SAML
My Domain	Custom login URL, SSO prerequisite, identity management	N/A
Login Flows	Custom logic during authentication (MFA, T&C acceptance, data collection)	Flow
Just-In-Time (JIT) Provisioning	Auto-create/update users at login via SAML attributes	SAML
Multi-Factor Authentication (MFA)	Required for all direct UI logins since Feb 2022	TOTP, WebAuthn, Salesforce Authenticator

Identity is Make-or-Break

Identity and SSO is one of the most common domains where CTA candidates fail. You must be able to design end-to-end identity solutions spanning internal users (corporate SSO), external users (community login), system-to-system authentication (Named Credentials + OAuth), and cross-org trust. Draw the identity flow showing every hop, token exchange, and trust boundary.

Shield Platform Encryption

Component	Purpose	Key Consideration
Platform Encryption	Encrypt data at rest (fields, files, attachments)	Deterministic vs. probabilistic encryption; impacts filter/search/sort; BYOK (Bring Your Own Key) supported
Field Audit Trail	Retain field history beyond 18-24 month standard limit	Up to 10 years; archive policies; storage implications
Event Monitoring	Track user activity (logins, API calls, report exports, data exports)	50+ event types; 1-year retention with paid license; NOT a system of record
Data Detect	Scan for sensitive data patterns (SSN, credit cards)	Classification policies; scanning scope

When to Recommend Shield

Shield is required when the scenario mentions regulatory compliance (HIPAA, PCI-DSS, GDPR encryption requirements), audit trail obligations, or monitoring requirements for sensitive data access. Know the performance trade-offs: Platform Encryption can impact search, sort, and filter capabilities on encrypted fields.

Multi-Org vs. Single-Org Strategy

This is CTA Domain 1, Objective 1.3 — one of the most architecturally significant decisions you will make in any scenario.

Factor	Single-Org Favored	Multi-Org Favored
Business process commonality	High commonality across BUs	Distinct processes, low overlap
Data sharing needs	Users need cross-BU visibility	Data must be isolated (regulatory, competitive)
Governance model	Centralized IT, strong CoE	Decentralized, BU autonomy prioritized
Release cadence	Unified release cycle acceptable	BUs need independent deployment schedules
Compliance/data residency	Single jurisdiction or no restrictions	Multiple jurisdictions with strict data residency
Acquisition model	Organic growth	Frequent M&A with integration timelines
Customization divergence	Manageable via config (record types, page layouts)	Fundamentally different object models or automation
Scale	Within platform limits	Near platform limits on storage, objects, or sharing rules

Modern consideration (2025-2026): Data Cloud / Data 360 can connect up to 5 Salesforce Core orgs, creating a unified data layer across a multi-org landscape. This changes the trade-off calculus — multi-org strategies become more viable when Data Cloud bridges the data silos. However, Data Cloud adds cost and complexity that must be justified.

CTA Default Position

Default to single-org unless the scenario presents compelling reasons for multi-org. Judges expect you to articulate the trade-offs. Common reasons for multi-org: data residency laws, fundamentally incompatible business processes, M&A with independent timelines, or platform limit constraints.

New and Evolving Capabilities (2024-2026)

CTA scenarios evolve with the platform. These features may not yet be heavily tested but demonstrate forward-looking architectural thinking.

Agentforce

Salesforce’s autonomous AI agent platform, succeeding Einstein Copilot. Key architectural considerations:

Aspect	Details
What it does	Autonomous AI agents that reason through multi-step tasks: analyze data, plan actions, execute workflows
Architecture	Topics (defining what an agent can do, max 10-15 per agent), Actions (max 15 per topic), Atlas Reasoning Engine
Data foundation	Requires clean, structured data; grounded via Data Cloud / Data 360; supports RAG with external data via External Objects in Prompt Builder
Governance	Einstein Trust Layer for data protection; GDPR compliance; guard rails on agent actions
Testing	Agentforce Testing Center for validating agent responses and performance
Licensing	Per-conversation pricing model; separate from standard CRM licenses
CTA relevance	Emerging area; demonstrates awareness of platform direction. If a scenario mentions AI-assisted service or automated workflows, acknowledge Agentforce as an option with appropriate guardrails

Hyperforce

Salesforce’s re-architecture to run on public cloud infrastructure (AWS, GCP, Azure).

Aspect	Details
What it does	Enables data residency by running Salesforce in specific cloud regions
Coverage	38+ regions globally; 90% of customers have migration access as of 2025
CTA relevance	Critical for scenarios with data residency requirements (GDPR, data sovereignty laws). When a scenario mentions “data must reside in EU/APAC/specific country,” Hyperforce is the architectural answer
Key constraint	Not all features are available in all Hyperforce regions immediately; verify feature parity

Well-Architected Framework

Salesforce’s prescriptive architectural guidance, relaunched at Dreamforce 2025.

Three pillars:

Trusted: Secure, Compliant, Reliable
Easy: Intentional, Automated, Engaging
Adaptable: Resilient, Composable

CTA Alignment

Frame your review board solution using Well-Architected language. When judges ask “why did you make this choice?” anchor your answer in these pillars. “I chose this approach because it is more adaptable — the composable architecture allows the client to evolve without rearchitecting” is stronger than just listing features.

Other Notable Changes (2024-2026)

Flow Orchestrator GA: Multi-step, multi-user processes with stages, steps, and SLA tracking
Dynamic Forms/Actions GA: Record page customization without Visualforce
Pub/Sub API: gRPC-based replacement for CometD streaming; higher throughput for event-driven integration
External Services enhancements: Register external REST APIs declaratively for use in Flow
Data 360 Logging: Offload Flow execution logs to Data Cloud for observability at scale
Debug logs during deployment: Now default to “off” for performance; controlled via enableDebugLogsDuringDeployment in ApexSettings
GraphQL API: For targeted, efficient data queries (reduces API consumption vs. REST)
Einstein Trust Layer: Governs LLM data access, masking PII, zero-retention for prompts

Licensing Deep Dive

Understanding licensing is Domain 1, Objective 1.5. Judges expect you to recommend the correct license mix with cost awareness.

Full CRM Licenses

License	Access	Use Case	Approximate Cost
Sales Cloud	Full CRM + Sales features (Leads, Opportunities, Forecasting, Territory Mgmt)	Sales reps, sales managers	$175-$550/user/mo
Service Cloud	Full CRM + Service features (Cases, Entitlements, Omni-Channel, Knowledge)	Support agents, service managers	$175-$550/user/mo
Sales + Service	Combined Sales and Service functionality	Users who do both sales and support	Bundled pricing

Editions determine feature ceiling: Enterprise, Unlimited, Einstein 1 (formerly Unlimited+).

Platform Licenses

License	Object Access	Use Case	Approximate Cost
Salesforce Platform Starter	10 custom objects; NO standard CRM objects (no Leads, Opportunities, Cases, Campaigns)	Simple custom apps, internal tools, HR workflows	~$25/user/mo
Salesforce Platform Plus	110 custom objects; NO standard CRM objects	Complex custom apps, operations dashboards	~$100/user/mo
Salesforce Platform Login	Same as Platform; pay-per-login (50 credits/login)	Infrequent internal app users	Per-login pricing

Common CTA Mistake

Platform licenses do NOT include access to Leads, Opportunities, Cases, Forecasting, or other standard CRM objects. If a user needs to view Opportunities (even read-only), they need a full CRM license, not a Platform license. Candidates frequently lose points by assigning Platform licenses to users who need CRM object access.

Experience Cloud Licenses

License	Object Access	Roles & Sharing	Reports	Best For
Customer Community	Accounts, Contacts, Cases, custom objects; NO Opportunities, Campaigns	NO role hierarchy; Sharing Sets only	Limited	High-volume self-service portals
Customer Community Plus	All standard + custom objects including Opportunities	Full role hierarchy; standard sharing rules	Full reporting	Portals needing role-based access and visibility
Partner Community	All standard + custom objects; Lead/Opportunity management	Full role hierarchy; partner-specific sharing	Full reporting; delegated admin	Channel/partner management with deal registration
External Apps	Custom objects only (no standard CRM objects)	Configurable	Limited	Custom portal applications, authenticated sites
Channel	Similar to Partner Community with channel-specific features	Full role hierarchy	Full	Reseller/distributor/dealer networks

Pricing models:

Model	How It Works	When to Use
Member-based (named user)	Fixed monthly per user ($5-$35/user/mo depending on license type)	Users who log in frequently (more than ~4x/month)
Login-based	Per 24-hour login session (~$2/session)	Users who log in infrequently; large user bases with low engagement

CTA License Calculation

In your review board presentation, show a license summary table. Example: “1,500 internal sales users (Sales Cloud Enterprise), 200 service agents (Service Cloud Enterprise), 50 IT/ops users (Platform Plus), 10,000 customers (Customer Community login-based), 500 partners (Partner Community member-based).” This demonstrates cost awareness and appropriate license selection.

Identity Licenses

License	Purpose	Key Capability
Identity Only	SSO access without CRM license	Authenticate via Salesforce for access to other apps (Salesforce as IdP); no CRM data access
External Identity	External user self-registration and authentication	Self-service registration, profile management, social login; no CRM object access; cheapest external license

Other License Types

License Type	Description	Example
Feature Licenses	Enable specific features for users who already have a base license	Marketing User, Flow User, Knowledge User, Service Cloud User
Permission Set Licenses	Unlock specific permission sets that require a paid add-on	CRM Analytics, Sales Engagement, Pardot, Einstein features
Chatter Free	Chatter collaboration only (feeds, groups, files); no CRM access	Company-wide collaboration for non-CRM users
Chatter External	Chatter access for people outside the organization	Customer or partner collaboration in Chatter groups
Integration User	API-only license for system-to-system integrations, introduced Spring ‘23; 5 free per Enterprise/Unlimited org, additional at ~$10 each	System-to-system API integration users
Einstein Agent (Agentforce)	Dedicated license for AI agents	Agentforce autonomous agent deployments; per-conversation pricing

Integration User License

The Integration User license is NOT deprecated — it is actively supported. Introduced in Spring ‘23, each Enterprise/Unlimited org receives 5 free Integration User licenses. These are API-only licenses designed for system-to-system integrations. Additional licenses can be purchased at approximately $10/user/month. Use these instead of consuming a full Salesforce license for integration users.

What NOT to Focus On

These products or features rarely appear in CTA scenarios or are too specialized for the review board:

Area	Why You Can Deprioritize	What to Know Instead
Industries Cloud deep dives (Financial Services Cloud, Health Cloud, Manufacturing Cloud specifics)	CTA scenarios are industry-agnostic; you will not be asked FSC-specific questions	Know they exist, that they add industry data models as managed packages, and their licensing implications
CPQ internal mechanics (product rule syntax, pricing waterfall details)	Too specialized; tested in B2B Solution Architect cert, not CTA	Know when to recommend CPQ, its architectural footprint, and that it has its own limits
Pardot / Marketing Cloud Account Engagement internals	Specialized B2B marketing tool; rarely the focus of CTA scenarios	Know it exists as the B2B marketing option, how it syncs with Salesforce (connector vs. native), and when to recommend it vs. SFMC
Salesforce Functions	Retired January 2025 (purchase cutoff October 2023); replaced by Heroku or external compute	Recommend Heroku, AWS Lambda, or similar for compute needs beyond platform limits
IoT Cloud / IoT Explorer	Discontinued; capabilities absorbed into Platform Events and Data Cloud	Use Platform Events for device data ingestion; Data Cloud for IoT data aggregation
Quip	De-emphasized in favor of Slack and native collaboration	Mention Slack for collaboration needs; Quip is not architecturally significant
Specific AppExchange packages	CTA tests architectural judgment, not product-specific knowledge	Know the build-vs-buy framework: when to use AppExchange, evaluation criteria (managed package governor limits, namespace, ISV support model), and the trade-off between control and speed
Einstein feature-by-feature details (Einstein Lead Scoring algorithm, Einstein Opportunity Insights tuning)	Too granular; CTA tests strategic AI positioning	Know when AI adds value, the data quality prerequisites, and the Trust Layer governance model
Visualforce deep development	Legacy technology; CTA expects LWC-first approach	Know Visualforce exists for legacy migration scenarios; recommend LWC for new development; know the security differences (Lightning Locker vs. LWS)

Study Priority

The CTA exam tests breadth of architectural thinking, not depth in any single product. You should be able to speak knowledgeably about any Salesforce product for 2-3 minutes if asked, but you will never be asked to configure CPQ pricing rules or write Marketing Cloud AMPscript. Focus your deep study on the platform itself: sharing model, governor limits, identity, data modeling, integration patterns, and automation.

Cross-Reference Map

This guide connects to many other study areas:

Domains & Scoring — how these products map to the 7 CTA domains
Scenario Patterns — which products tend to appear in which scenario types
System Architecture — org strategy, licensing, reporting decisions
Security — sharing model, identity, Shield
Data Architecture — data modeling, LDV, migration
Solution Architecture — build-vs-buy, declarative-vs-code decisions
Integration — MuleSoft, Heroku, Platform Events, APIs
Integration Decision Guide — when to use which integration technology