CTA Awareness cheat sheet

The CTA (Certified Technical Architect) credential validates the ability to design, review, and defend multi-tenant solutions on the platform; the journey runs from prerequisites through instructor-led review, a proctored multiple-choice exam, and a scenario-based review board.

Core architect competencies: data model and security design, integration and API strategy, identity and access architecture, platform limits and scalability, lifecycle governance, and the ability to communicate trade-offs to both technical and executive audiences.

The exam rewards recognizing patterns and constraints over memorizing UI paths; questions typically present a business requirement plus constraints and ask for the best design or the most likely failure mode.

A solution design always starts from requirements: functional needs, non-functional needs (volume, latency, availability), constraints (licensing, budget, skills), and assumptions that must be validated with the customer.

The review board evaluates the design narrative: problem statement, options considered, why the chosen option wins, risks, mitigations, and a phased delivery plan. Designs without alternatives are usually challenged.

Declarative configuration is preferred over code where it satisfies the requirement; code (Apex, triggers, LWC) is justified when declarative tools cannot meet performance, complexity, or transactional requirements.

Every design decision carries a trade-off: customization increases fit but raises maintenance cost and upgrade risk; standardization lowers cost but may require process change.

Know the difference between a platform limit (hard, cannot be raised), an allocation (per-org entitlement that can be purchased), and a soft guideline (recommended practice).

Architect deliverables: solution design document, data model diagram, integration catalog, security model, non-functional requirements matrix, and a deployment/governance plan.

Standard objects (Account, Contact, Opportunity, Case, Lead, User) should be reused before creating custom objects; custom objects are justified when no standard object carries the semantics or lifecycle.

Relationship types: master-detail implies strong ownership, cascade delete, and roll-up summary support; lookup is loosely coupled and independent; many-to-many requires a junction object with two master-detail relationships.

Roll-up summary fields work only on master-detail relationships; for lookup-based aggregation use declarative roll-up or scheduled/async Apex aggregation.

External ID fields enable upsert, data loading matches, and integration correlation; every integration-facing object should carry a stable external identifier.

The 15-object limit on master-detail relationships per object and the 2 master-detail limit per child object constrain deep ownership hierarchies; plan junction and lookup alternatives early.

Record types plus page layout assignments control business process variation; avoid creating a new object per process variant when record types and picklists suffice.

Data skew (ownership skew, lookup skew) causes record lock contention and sharing performance problems; distribute ownership and avoid hot parent records in high-volume child inserts.

Data lifecycle: archive or delete obsolete records, define retention per object, and use the recycle bin and hard-delete tooling deliberately; large data volumes require indexing and selective queries.

Big objects store very large datasets with asynchronous access and no standard SOQL full-scan performance; use them for audit and historical archives, not for transactional UI needs.

Pattern selection: request-reply (synchronous) for real-time user-facing needs; fire-and-forget for non-critical events; batch for bulk; publish-subscribe for multi-consumer fan-out.

REST API suits resource-oriented, stateless, JSON interactions; SOAP is chosen when a WSDL contract, WS-Security, or strict typed operations are mandated by the partner.

Bulk API 2.0 is the tool for large data volumes (hundreds of thousands to millions of records); it is asynchronous, job-based, and governed by separate batch limits.

Composite API reduces round trips by bundling subrequests in one call; Composite Graph handles multiple unrelated records with references across them.

Platform Events and Change Data Capture support event-driven integration with replay IDs; Pub/Sub API provides gRPC/HTTP streaming access to those event streams.

Outbound messaging and callouts are subject to governor limits: cumulative callout time per transaction, callout size, and the 100-callout limit per transaction.

Idempotency is mandatory for inbound integrations: use external IDs plus upsert, or a dedupe key, so retries do not create duplicates.

Middleware (ESB/iPaaS) is justified when you need orchestration, protocol transformation, retry/queue semantics, or decoupling of many endpoints; point-to-point is acceptable for a few simple flows.

Error handling design: capture failures in a custom error object or platform event, define retry with backoff, and alert on dead-letter thresholds.

The sharing model is layered: organization-wide defaults (OWD) set the baseline, then role hierarchy, sharing rules, teams, manual sharing, and territory hierarchy widen access; Apex sharing recalculates only on explicit invocation.

OWD values: Private, Public Read Only, Public Read/Write, and (for some objects) Controlled by Parent; the most restrictive sensible OWD plus targeted sharing is the recommended posture.

Profiles define object/field permissions and are assigned one per user; permission sets and permission set groups grant additive access and are the preferred way to model job functions.

Record-level access is the union of OWD, role hierarchy (if granted), sharing rules, teams, territories, and manual shares; access cannot be subtracted below OWD except via restrictions such as scoping.

Field-level security governs visibility and editability; it does not prevent SOQL from reading a field in Apex, so code must enforce FLS explicitly with WITH SECURITY_ENFORCED or stripInaccessible.

Authentication options: SAML 2.0 SSO, OpenID Connect, social sign-on, and multi-factor authentication; MFA is required for internal users under the platform's security baseline.

Connected Apps and OAuth flows: authorization code with PKCE for user-context web/mobile, JWT bearer flow for server-to-server, client credentials for machine-to-machine without a user.

Named credentials and external credentials store endpoint and secret material outside code; remote site settings alone are legacy and do not carry authentication.

Shield Platform Encryption encrypts data at rest with customer-controlled keys but preserves case-insensitive search only for deterministic schemes; probabilistic encryption breaks filtering and sorting.

Guest user access is highly restricted: no standard object access by default, sharing via guest user record access settings, and secure Apex must run in system mode with explicit checks.

Multi-tenancy means all tenants share infrastructure; the platform enforces governor limits per transaction to protect the shared pool, so designs must be bulkified and asynchronous where volume demands it.

Execution contexts differ: system mode (Apex without sharing) ignores sharing rules; user mode (with sharing / inherited sharing) enforces them. Choose deliberately and document it.

Asynchronous options: @future (simple callouts), Queueable (chaining, job IDs), Batch Apex (large volumes, chunked), Schedulable (time-based), and Platform Events for decoupled flows.

The order of execution for a DML save matters: validation rules, before triggers, duplicate rules, after triggers, assignment rules, workflows, flows, escalation, roll-ups, and commit.

Lightning Web Components are the modern UI stack; Aura remains for legacy; Visualforce persists for PDFs, email templates, and specific legacy needs.

Declarative automation choice: record-triggered flows for most automation, approval processes for sign-off, and Apex when logic needs recursion control, complex transactions, or callouts in triggers.

Apex trigger frameworks (one trigger per object, handler classes, recursion guards) reduce risk of order-dependent bugs and repeated execution.

Custom metadata types are for configuration that deploys between environments; custom settings are for data-like configuration, and their caching behavior differs.

Namespace and package strategy: managed packages for IP protection and upgradeability; unlocked packages for internal modular delivery.

Selectivity drives query performance: a filter is selective when it returns well under the threshold (broadly <10% of rows, and indexed), so index candidate fields used in WHERE clauses and avoid negative filters like != or NOT IN.

Standard indexes exist on Id, Name, OwnerId, CreatedDate, SystemModstamp, lookup/master-detail foreign keys, and external IDs; custom indexes are requested through support and are limited.

Skinny tables (support-assisted) copy frequently filtered fields to improve large-volume query speed; they must be refreshed after schema changes.

Avoid leading wildcards in SOQL, avoid SELECT in loops, and never issue queries inside for-loops; use relationship queries and maps to reduce round trips.

Bulkify: process collections with single SOQL/DML calls; governor limits are per transaction, so batch size and chunking determine scalability.

Batch Apex default batch size is 200; tuning batch size trades heap and CPU against total number of batches and total elapsed time.

Record locking and UNABLE_TO_LOCK_ROW errors come from concurrent updates to the same parent or skewed data; mitigate with retry logic and data distribution.

Performance testing must use production-like data volumes; a design that passes in a small sandbox can fail at millions of rows due to non-selective queries and sharing recalculation.

Monitor with debug logs, the query plan tool, Apex CPU time limits, and event monitoring for slow pages and API usage.

Environment strategy: sandbox types differ in refresh interval and data copy - Developer, Developer Pro, Partial Copy (template-based sample data), and Full Copy.

Deployment tools: change sets (point-and-click, limited metadata coverage), Salesforce CLI with metadata API or source format, and unlocked/managed second-generation packages for CI/CD.

A DevOps pipeline should include version control, automated tests with required coverage, static analysis (such as PMD rules), a staging validation deployment, and a production deploy with a rollback plan.

Apex test requirements for production deployment: at least 75% overall coverage, all tests passing, and triggers requiring coverage of their own; coverage is a floor, not a quality measure.

Governance artifacts: naming conventions, a metadata ownership map, a release calendar, an integration registry, and an architecture review gate for significant changes.

Change management must consider downstream dependencies: integrations, reports, dashboards, flows, and permission sets referencing renamed or deleted metadata.

Technical debt should be logged and prioritized; hard-coded IDs, unused fields, and overly permissive profiles are common debt items.

Data seeding and masking: use templates for partial sandboxes and anonymize PII before refreshing non-production environments.

Non-functional requirements to elicit explicitly: volume (records, transactions per second), latency, availability, retention, audit, localization, and regulatory constraints.

Design options should be evaluated against weighted criteria (fit, cost, risk, time-to-value, maintainability); the recommendation must state why rejected options lost.

Build vs. buy vs. extend: standard functionality first, then declarative configuration, then custom code, then third-party AppExchange, then external system integration.

Trade-off patterns: synchronous improves UX but couples availability; asynchronous improves resilience but complicates error handling and user feedback.

Licensing and limits are design constraints: API call allocations, storage, sandbox count, and feature licenses can invalidate an otherwise sound design.

Risk register entries should pair each risk with likelihood, impact, owner, and mitigation; unmitigated single points of failure are a common review finding.

Phased delivery reduces risk: prove the data model and security model first, then integration, then scale and optimize.

Assumptions must be documented and validated; a design that silently assumes data quality or volume will be challenged in review.

The review board presentation structure: business context, requirements and constraints, options considered, recommended design with diagrams, risks and mitigations, delivery plan, and open questions.

Diagrams must show system boundaries, data flows, trust boundaries, integration direction and protocol, and where identity is asserted and validated.

Tailor the message: executives need cost, risk, and timeline; engineers need data model, limits, and failure modes. The same design gets two narratives.

Anticipate board challenges: Why not standard functionality? What happens at 10x volume? How is PII protected? What is the rollback plan? Who owns operations?

Quantify claims: cite record volumes, API call counts, latency budgets, and storage estimates rather than qualitative assurances.

Document decisions as ADRs (context, decision, consequences) so future architects understand why a path was chosen.

Security reviews require data classification, access matrix by persona, encryption posture, and audit trail design.

A design that cannot be operated and monitored is incomplete; include alerting, runbooks, and ownership in the review.

The CTA (Certified Technical Architect) credential validates the ability to design, review, and defend multi-tenant solutions on the platform; the journey runs from prerequisites through instructor-led review, a proctored multiple-choice exam, and a scenario-based review board.

Core architect competencies: data model and security design, integration and API strategy, identity and access architecture, platform limits and scalability, lifecycle governance, and the ability to communicate trade-offs to both technical and executive audiences.

The exam rewards recognizing patterns and constraints over memorizing UI paths; questions typically present a business requirement plus constraints and ask for the best design or the most likely failure mode.

A solution design always starts from requirements: functional needs, non-functional needs (volume, latency, availability), constraints (licensing, budget, skills), and assumptions that must be validated with the customer.

The review board evaluates the design narrative: problem statement, options considered, why the chosen option wins, risks, mitigations, and a phased delivery plan. Designs without alternatives are usually challenged.

Declarative configuration is preferred over code where it satisfies the requirement; code (Apex, triggers, LWC) is justified when declarative tools cannot meet performance, complexity, or transactional requirements.

Every design decision carries a trade-off: customization increases fit but raises maintenance cost and upgrade risk; standardization lowers cost but may require process change.

Know the difference between a platform limit (hard, cannot be raised), an allocation (per-org entitlement that can be purchased), and a soft guideline (recommended practice).

Architect deliverables: solution design document, data model diagram, integration catalog, security model, non-functional requirements matrix, and a deployment/governance plan.

Standard objects (Account, Contact, Opportunity, Case, Lead, User) should be reused before creating custom objects; custom objects are justified when no standard object carries the semantics or lifecycle.

Relationship types: master-detail implies strong ownership, cascade delete, and roll-up summary support; lookup is loosely coupled and independent; many-to-many requires a junction object with two master-detail relationships.

Roll-up summary fields work only on master-detail relationships; for lookup-based aggregation use declarative roll-up or scheduled/async Apex aggregation.

External ID fields enable upsert, data loading matches, and integration correlation; every integration-facing object should carry a stable external identifier.

The 15-object limit on master-detail relationships per object and the 2 master-detail limit per child object constrain deep ownership hierarchies; plan junction and lookup alternatives early.

Record types plus page layout assignments control business process variation; avoid creating a new object per process variant when record types and picklists suffice.

Data skew (ownership skew, lookup skew) causes record lock contention and sharing performance problems; distribute ownership and avoid hot parent records in high-volume child inserts.

Data lifecycle: archive or delete obsolete records, define retention per object, and use the recycle bin and hard-delete tooling deliberately; large data volumes require indexing and selective queries.

Big objects store very large datasets with asynchronous access and no standard SOQL full-scan performance; use them for audit and historical archives, not for transactional UI needs.

Pattern selection: request-reply (synchronous) for real-time user-facing needs; fire-and-forget for non-critical events; batch for bulk; publish-subscribe for multi-consumer fan-out.

REST API suits resource-oriented, stateless, JSON interactions; SOAP is chosen when a WSDL contract, WS-Security, or strict typed operations are mandated by the partner.

Bulk API 2.0 is the tool for large data volumes (hundreds of thousands to millions of records); it is asynchronous, job-based, and governed by separate batch limits.

Composite API reduces round trips by bundling subrequests in one call; Composite Graph handles multiple unrelated records with references across them.

Platform Events and Change Data Capture support event-driven integration with replay IDs; Pub/Sub API provides gRPC/HTTP streaming access to those event streams.

Outbound messaging and callouts are subject to governor limits: cumulative callout time per transaction, callout size, and the 100-callout limit per transaction.

Idempotency is mandatory for inbound integrations: use external IDs plus upsert, or a dedupe key, so retries do not create duplicates.

Middleware (ESB/iPaaS) is justified when you need orchestration, protocol transformation, retry/queue semantics, or decoupling of many endpoints; point-to-point is acceptable for a few simple flows.

Error handling design: capture failures in a custom error object or platform event, define retry with backoff, and alert on dead-letter thresholds.

The sharing model is layered: organization-wide defaults (OWD) set the baseline, then role hierarchy, sharing rules, teams, manual sharing, and territory hierarchy widen access; Apex sharing recalculates only on explicit invocation.

OWD values: Private, Public Read Only, Public Read/Write, and (for some objects) Controlled by Parent; the most restrictive sensible OWD plus targeted sharing is the recommended posture.

Profiles define object/field permissions and are assigned one per user; permission sets and permission set groups grant additive access and are the preferred way to model job functions.

Record-level access is the union of OWD, role hierarchy (if granted), sharing rules, teams, territories, and manual shares; access cannot be subtracted below OWD except via restrictions such as scoping.

Field-level security governs visibility and editability; it does not prevent SOQL from reading a field in Apex, so code must enforce FLS explicitly with WITH SECURITY_ENFORCED or stripInaccessible.

Authentication options: SAML 2.0 SSO, OpenID Connect, social sign-on, and multi-factor authentication; MFA is required for internal users under the platform's security baseline.

Connected Apps and OAuth flows: authorization code with PKCE for user-context web/mobile, JWT bearer flow for server-to-server, client credentials for machine-to-machine without a user.

Named credentials and external credentials store endpoint and secret material outside code; remote site settings alone are legacy and do not carry authentication.

Shield Platform Encryption encrypts data at rest with customer-controlled keys but preserves case-insensitive search only for deterministic schemes; probabilistic encryption breaks filtering and sorting.

Guest user access is highly restricted: no standard object access by default, sharing via guest user record access settings, and secure Apex must run in system mode with explicit checks.

Multi-tenancy means all tenants share infrastructure; the platform enforces governor limits per transaction to protect the shared pool, so designs must be bulkified and asynchronous where volume demands it.

Execution contexts differ: system mode (Apex without sharing) ignores sharing rules; user mode (with sharing / inherited sharing) enforces them. Choose deliberately and document it.

Asynchronous options: @future (simple callouts), Queueable (chaining, job IDs), Batch Apex (large volumes, chunked), Schedulable (time-based), and Platform Events for decoupled flows.

The order of execution for a DML save matters: validation rules, before triggers, duplicate rules, after triggers, assignment rules, workflows, flows, escalation, roll-ups, and commit.

Lightning Web Components are the modern UI stack; Aura remains for legacy; Visualforce persists for PDFs, email templates, and specific legacy needs.

Declarative automation choice: record-triggered flows for most automation, approval processes for sign-off, and Apex when logic needs recursion control, complex transactions, or callouts in triggers.

Apex trigger frameworks (one trigger per object, handler classes, recursion guards) reduce risk of order-dependent bugs and repeated execution.

Custom metadata types are for configuration that deploys between environments; custom settings are for data-like configuration, and their caching behavior differs.

Namespace and package strategy: managed packages for IP protection and upgradeability; unlocked packages for internal modular delivery.

Selectivity drives query performance: a filter is selective when it returns well under the threshold (broadly <10% of rows, and indexed), so index candidate fields used in WHERE clauses and avoid negative filters like != or NOT IN.

Standard indexes exist on Id, Name, OwnerId, CreatedDate, SystemModstamp, lookup/master-detail foreign keys, and external IDs; custom indexes are requested through support and are limited.

Skinny tables (support-assisted) copy frequently filtered fields to improve large-volume query speed; they must be refreshed after schema changes.

Avoid leading wildcards in SOQL, avoid SELECT in loops, and never issue queries inside for-loops; use relationship queries and maps to reduce round trips.

Bulkify: process collections with single SOQL/DML calls; governor limits are per transaction, so batch size and chunking determine scalability.

Batch Apex default batch size is 200; tuning batch size trades heap and CPU against total number of batches and total elapsed time.

Record locking and UNABLE_TO_LOCK_ROW errors come from concurrent updates to the same parent or skewed data; mitigate with retry logic and data distribution.

Performance testing must use production-like data volumes; a design that passes in a small sandbox can fail at millions of rows due to non-selective queries and sharing recalculation.

Monitor with debug logs, the query plan tool, Apex CPU time limits, and event monitoring for slow pages and API usage.

Environment strategy: sandbox types differ in refresh interval and data copy - Developer, Developer Pro, Partial Copy (template-based sample data), and Full Copy.

Deployment tools: change sets (point-and-click, limited metadata coverage), Salesforce CLI with metadata API or source format, and unlocked/managed second-generation packages for CI/CD.

A DevOps pipeline should include version control, automated tests with required coverage, static analysis (such as PMD rules), a staging validation deployment, and a production deploy with a rollback plan.

Apex test requirements for production deployment: at least 75% overall coverage, all tests passing, and triggers requiring coverage of their own; coverage is a floor, not a quality measure.

Governance artifacts: naming conventions, a metadata ownership map, a release calendar, an integration registry, and an architecture review gate for significant changes.

Change management must consider downstream dependencies: integrations, reports, dashboards, flows, and permission sets referencing renamed or deleted metadata.

Technical debt should be logged and prioritized; hard-coded IDs, unused fields, and overly permissive profiles are common debt items.

Data seeding and masking: use templates for partial sandboxes and anonymize PII before refreshing non-production environments.

Non-functional requirements to elicit explicitly: volume (records, transactions per second), latency, availability, retention, audit, localization, and regulatory constraints.

Design options should be evaluated against weighted criteria (fit, cost, risk, time-to-value, maintainability); the recommendation must state why rejected options lost.

Build vs. buy vs. extend: standard functionality first, then declarative configuration, then custom code, then third-party AppExchange, then external system integration.

Trade-off patterns: synchronous improves UX but couples availability; asynchronous improves resilience but complicates error handling and user feedback.

Licensing and limits are design constraints: API call allocations, storage, sandbox count, and feature licenses can invalidate an otherwise sound design.

Risk register entries should pair each risk with likelihood, impact, owner, and mitigation; unmitigated single points of failure are a common review finding.

Phased delivery reduces risk: prove the data model and security model first, then integration, then scale and optimize.

Assumptions must be documented and validated; a design that silently assumes data quality or volume will be challenged in review.

The review board presentation structure: business context, requirements and constraints, options considered, recommended design with diagrams, risks and mitigations, delivery plan, and open questions.

Diagrams must show system boundaries, data flows, trust boundaries, integration direction and protocol, and where identity is asserted and validated.

Tailor the message: executives need cost, risk, and timeline; engineers need data model, limits, and failure modes. The same design gets two narratives.

Anticipate board challenges: Why not standard functionality? What happens at 10x volume? How is PII protected? What is the rollback plan? Who owns operations?

Quantify claims: cite record volumes, API call counts, latency budgets, and storage estimates rather than qualitative assurances.

Document decisions as ADRs (context, decision, consequences) so future architects understand why a path was chosen.

Security reviews require data classification, access matrix by persona, encryption posture, and audit trail design.

A design that cannot be operated and monitored is incomplete; include alerting, runbooks, and ownership in the review.

The CTA (Certified Technical Architect) credential validates the ability to design, review, and defend multi-tenant solutions on the platform; the journey runs from prerequisites through instructor-led review, a proctored multiple-choice exam, and a scenario-based review board.

Core architect competencies: data model and security design, integration and API strategy, identity and access architecture, platform limits and scalability, lifecycle governance, and the ability to communicate trade-offs to both technical and executive audiences.

The exam rewards recognizing patterns and constraints over memorizing UI paths; questions typically present a business requirement plus constraints and ask for the best design or the most likely failure mode.

A solution design always starts from requirements: functional needs, non-functional needs (volume, latency, availability), constraints (licensing, budget, skills), and assumptions that must be validated with the customer.

The review board evaluates the design narrative: problem statement, options considered, why the chosen option wins, risks, mitigations, and a phased delivery plan. Designs without alternatives are usually challenged.

Declarative configuration is preferred over code where it satisfies the requirement; code (Apex, triggers, LWC) is justified when declarative tools cannot meet performance, complexity, or transactional requirements.

Every design decision carries a trade-off: customization increases fit but raises maintenance cost and upgrade risk; standardization lowers cost but may require process change.

Know the difference between a platform limit (hard, cannot be raised), an allocation (per-org entitlement that can be purchased), and a soft guideline (recommended practice).

Architect deliverables: solution design document, data model diagram, integration catalog, security model, non-functional requirements matrix, and a deployment/governance plan.

Standard objects (Account, Contact, Opportunity, Case, Lead, User) should be reused before creating custom objects; custom objects are justified when no standard object carries the semantics or lifecycle.

Relationship types: master-detail implies strong ownership, cascade delete, and roll-up summary support; lookup is loosely coupled and independent; many-to-many requires a junction object with two master-detail relationships.

Roll-up summary fields work only on master-detail relationships; for lookup-based aggregation use declarative roll-up or scheduled/async Apex aggregation.

External ID fields enable upsert, data loading matches, and integration correlation; every integration-facing object should carry a stable external identifier.

The 15-object limit on master-detail relationships per object and the 2 master-detail limit per child object constrain deep ownership hierarchies; plan junction and lookup alternatives early.

Record types plus page layout assignments control business process variation; avoid creating a new object per process variant when record types and picklists suffice.

Data skew (ownership skew, lookup skew) causes record lock contention and sharing performance problems; distribute ownership and avoid hot parent records in high-volume child inserts.

Data lifecycle: archive or delete obsolete records, define retention per object, and use the recycle bin and hard-delete tooling deliberately; large data volumes require indexing and selective queries.

Big objects store very large datasets with asynchronous access and no standard SOQL full-scan performance; use them for audit and historical archives, not for transactional UI needs.

Pattern selection: request-reply (synchronous) for real-time user-facing needs; fire-and-forget for non-critical events; batch for bulk; publish-subscribe for multi-consumer fan-out.

REST API suits resource-oriented, stateless, JSON interactions; SOAP is chosen when a WSDL contract, WS-Security, or strict typed operations are mandated by the partner.

Bulk API 2.0 is the tool for large data volumes (hundreds of thousands to millions of records); it is asynchronous, job-based, and governed by separate batch limits.

Composite API reduces round trips by bundling subrequests in one call; Composite Graph handles multiple unrelated records with references across them.

Platform Events and Change Data Capture support event-driven integration with replay IDs; Pub/Sub API provides gRPC/HTTP streaming access to those event streams.

Outbound messaging and callouts are subject to governor limits: cumulative callout time per transaction, callout size, and the 100-callout limit per transaction.

Idempotency is mandatory for inbound integrations: use external IDs plus upsert, or a dedupe key, so retries do not create duplicates.

Middleware (ESB/iPaaS) is justified when you need orchestration, protocol transformation, retry/queue semantics, or decoupling of many endpoints; point-to-point is acceptable for a few simple flows.

Error handling design: capture failures in a custom error object or platform event, define retry with backoff, and alert on dead-letter thresholds.

The sharing model is layered: organization-wide defaults (OWD) set the baseline, then role hierarchy, sharing rules, teams, manual sharing, and territory hierarchy widen access; Apex sharing recalculates only on explicit invocation.

OWD values: Private, Public Read Only, Public Read/Write, and (for some objects) Controlled by Parent; the most restrictive sensible OWD plus targeted sharing is the recommended posture.

Profiles define object/field permissions and are assigned one per user; permission sets and permission set groups grant additive access and are the preferred way to model job functions.

Record-level access is the union of OWD, role hierarchy (if granted), sharing rules, teams, territories, and manual shares; access cannot be subtracted below OWD except via restrictions such as scoping.

Field-level security governs visibility and editability; it does not prevent SOQL from reading a field in Apex, so code must enforce FLS explicitly with WITH SECURITY_ENFORCED or stripInaccessible.

Authentication options: SAML 2.0 SSO, OpenID Connect, social sign-on, and multi-factor authentication; MFA is required for internal users under the platform's security baseline.

Connected Apps and OAuth flows: authorization code with PKCE for user-context web/mobile, JWT bearer flow for server-to-server, client credentials for machine-to-machine without a user.

Named credentials and external credentials store endpoint and secret material outside code; remote site settings alone are legacy and do not carry authentication.

Shield Platform Encryption encrypts data at rest with customer-controlled keys but preserves case-insensitive search only for deterministic schemes; probabilistic encryption breaks filtering and sorting.

Guest user access is highly restricted: no standard object access by default, sharing via guest user record access settings, and secure Apex must run in system mode with explicit checks.

Multi-tenancy means all tenants share infrastructure; the platform enforces governor limits per transaction to protect the shared pool, so designs must be bulkified and asynchronous where volume demands it.

Execution contexts differ: system mode (Apex without sharing) ignores sharing rules; user mode (with sharing / inherited sharing) enforces them. Choose deliberately and document it.

Asynchronous options: @future (simple callouts), Queueable (chaining, job IDs), Batch Apex (large volumes, chunked), Schedulable (time-based), and Platform Events for decoupled flows.

The order of execution for a DML save matters: validation rules, before triggers, duplicate rules, after triggers, assignment rules, workflows, flows, escalation, roll-ups, and commit.

Lightning Web Components are the modern UI stack; Aura remains for legacy; Visualforce persists for PDFs, email templates, and specific legacy needs.

Declarative automation choice: record-triggered flows for most automation, approval processes for sign-off, and Apex when logic needs recursion control, complex transactions, or callouts in triggers.

Apex trigger frameworks (one trigger per object, handler classes, recursion guards) reduce risk of order-dependent bugs and repeated execution.

Custom metadata types are for configuration that deploys between environments; custom settings are for data-like configuration, and their caching behavior differs.

Namespace and package strategy: managed packages for IP protection and upgradeability; unlocked packages for internal modular delivery.

Selectivity drives query performance: a filter is selective when it returns well under the threshold (broadly <10% of rows, and indexed), so index candidate fields used in WHERE clauses and avoid negative filters like != or NOT IN.

Standard indexes exist on Id, Name, OwnerId, CreatedDate, SystemModstamp, lookup/master-detail foreign keys, and external IDs; custom indexes are requested through support and are limited.

Skinny tables (support-assisted) copy frequently filtered fields to improve large-volume query speed; they must be refreshed after schema changes.

Avoid leading wildcards in SOQL, avoid SELECT in loops, and never issue queries inside for-loops; use relationship queries and maps to reduce round trips.

Bulkify: process collections with single SOQL/DML calls; governor limits are per transaction, so batch size and chunking determine scalability.

Batch Apex default batch size is 200; tuning batch size trades heap and CPU against total number of batches and total elapsed time.

Record locking and UNABLE_TO_LOCK_ROW errors come from concurrent updates to the same parent or skewed data; mitigate with retry logic and data distribution.

Performance testing must use production-like data volumes; a design that passes in a small sandbox can fail at millions of rows due to non-selective queries and sharing recalculation.

Monitor with debug logs, the query plan tool, Apex CPU time limits, and event monitoring for slow pages and API usage.

Environment strategy: sandbox types differ in refresh interval and data copy - Developer, Developer Pro, Partial Copy (template-based sample data), and Full Copy.

Deployment tools: change sets (point-and-click, limited metadata coverage), Salesforce CLI with metadata API or source format, and unlocked/managed second-generation packages for CI/CD.

A DevOps pipeline should include version control, automated tests with required coverage, static analysis (such as PMD rules), a staging validation deployment, and a production deploy with a rollback plan.

Apex test requirements for production deployment: at least 75% overall coverage, all tests passing, and triggers requiring coverage of their own; coverage is a floor, not a quality measure.

Governance artifacts: naming conventions, a metadata ownership map, a release calendar, an integration registry, and an architecture review gate for significant changes.

Change management must consider downstream dependencies: integrations, reports, dashboards, flows, and permission sets referencing renamed or deleted metadata.

Technical debt should be logged and prioritized; hard-coded IDs, unused fields, and overly permissive profiles are common debt items.

Data seeding and masking: use templates for partial sandboxes and anonymize PII before refreshing non-production environments.

Non-functional requirements to elicit explicitly: volume (records, transactions per second), latency, availability, retention, audit, localization, and regulatory constraints.

Design options should be evaluated against weighted criteria (fit, cost, risk, time-to-value, maintainability); the recommendation must state why rejected options lost.

Build vs. buy vs. extend: standard functionality first, then declarative configuration, then custom code, then third-party AppExchange, then external system integration.

Trade-off patterns: synchronous improves UX but couples availability; asynchronous improves resilience but complicates error handling and user feedback.

Licensing and limits are design constraints: API call allocations, storage, sandbox count, and feature licenses can invalidate an otherwise sound design.

Risk register entries should pair each risk with likelihood, impact, owner, and mitigation; unmitigated single points of failure are a common review finding.

Phased delivery reduces risk: prove the data model and security model first, then integration, then scale and optimize.

Assumptions must be documented and validated; a design that silently assumes data quality or volume will be challenged in review.

The review board presentation structure: business context, requirements and constraints, options considered, recommended design with diagrams, risks and mitigations, delivery plan, and open questions.

Diagrams must show system boundaries, data flows, trust boundaries, integration direction and protocol, and where identity is asserted and validated.

Tailor the message: executives need cost, risk, and timeline; engineers need data model, limits, and failure modes. The same design gets two narratives.

Anticipate board challenges: Why not standard functionality? What happens at 10x volume? How is PII protected? What is the rollback plan? Who owns operations?

Quantify claims: cite record volumes, API call counts, latency budgets, and storage estimates rather than qualitative assurances.

Document decisions as ADRs (context, decision, consequences) so future architects understand why a path was chosen.

Security reviews require data classification, access matrix by persona, encryption posture, and audit trail design.

A design that cannot be operated and monitored is incomplete; include alerting, runbooks, and ownership in the review.

The CTA (Certified Technical Architect) credential validates the ability to design, review, and defend multi-tenant solutions on the platform; the journey runs from prerequisites through instructor-led review, a proctored multiple-choice exam, and a scenario-based review board.

Core architect competencies: data model and security design, integration and API strategy, identity and access architecture, platform limits and scalability, lifecycle governance, and the ability to communicate trade-offs to both technical and executive audiences.

The exam rewards recognizing patterns and constraints over memorizing UI paths; questions typically present a business requirement plus constraints and ask for the best design or the most likely failure mode.

A solution design always starts from requirements: functional needs, non-functional needs (volume, latency, availability), constraints (licensing, budget, skills), and assumptions that must be validated with the customer.

The review board evaluates the design narrative: problem statement, options considered, why the chosen option wins, risks, mitigations, and a phased delivery plan. Designs without alternatives are usually challenged.

Declarative configuration is preferred over code where it satisfies the requirement; code (Apex, triggers, LWC) is justified when declarative tools cannot meet performance, complexity, or transactional requirements.

Every design decision carries a trade-off: customization increases fit but raises maintenance cost and upgrade risk; standardization lowers cost but may require process change.

Know the difference between a platform limit (hard, cannot be raised), an allocation (per-org entitlement that can be purchased), and a soft guideline (recommended practice).

Architect deliverables: solution design document, data model diagram, integration catalog, security model, non-functional requirements matrix, and a deployment/governance plan.

Standard objects (Account, Contact, Opportunity, Case, Lead, User) should be reused before creating custom objects; custom objects are justified when no standard object carries the semantics or lifecycle.

Relationship types: master-detail implies strong ownership, cascade delete, and roll-up summary support; lookup is loosely coupled and independent; many-to-many requires a junction object with two master-detail relationships.

Roll-up summary fields work only on master-detail relationships; for lookup-based aggregation use declarative roll-up or scheduled/async Apex aggregation.

External ID fields enable upsert, data loading matches, and integration correlation; every integration-facing object should carry a stable external identifier.

The 15-object limit on master-detail relationships per object and the 2 master-detail limit per child object constrain deep ownership hierarchies; plan junction and lookup alternatives early.

Record types plus page layout assignments control business process variation; avoid creating a new object per process variant when record types and picklists suffice.

Data skew (ownership skew, lookup skew) causes record lock contention and sharing performance problems; distribute ownership and avoid hot parent records in high-volume child inserts.

Data lifecycle: archive or delete obsolete records, define retention per object, and use the recycle bin and hard-delete tooling deliberately; large data volumes require indexing and selective queries.

Big objects store very large datasets with asynchronous access and no standard SOQL full-scan performance; use them for audit and historical archives, not for transactional UI needs.

Pattern selection: request-reply (synchronous) for real-time user-facing needs; fire-and-forget for non-critical events; batch for bulk; publish-subscribe for multi-consumer fan-out.

REST API suits resource-oriented, stateless, JSON interactions; SOAP is chosen when a WSDL contract, WS-Security, or strict typed operations are mandated by the partner.

Bulk API 2.0 is the tool for large data volumes (hundreds of thousands to millions of records); it is asynchronous, job-based, and governed by separate batch limits.

Composite API reduces round trips by bundling subrequests in one call; Composite Graph handles multiple unrelated records with references across them.

Platform Events and Change Data Capture support event-driven integration with replay IDs; Pub/Sub API provides gRPC/HTTP streaming access to those event streams.

Outbound messaging and callouts are subject to governor limits: cumulative callout time per transaction, callout size, and the 100-callout limit per transaction.

Idempotency is mandatory for inbound integrations: use external IDs plus upsert, or a dedupe key, so retries do not create duplicates.

Middleware (ESB/iPaaS) is justified when you need orchestration, protocol transformation, retry/queue semantics, or decoupling of many endpoints; point-to-point is acceptable for a few simple flows.

Error handling design: capture failures in a custom error object or platform event, define retry with backoff, and alert on dead-letter thresholds.

The sharing model is layered: organization-wide defaults (OWD) set the baseline, then role hierarchy, sharing rules, teams, manual sharing, and territory hierarchy widen access; Apex sharing recalculates only on explicit invocation.

OWD values: Private, Public Read Only, Public Read/Write, and (for some objects) Controlled by Parent; the most restrictive sensible OWD plus targeted sharing is the recommended posture.

Profiles define object/field permissions and are assigned one per user; permission sets and permission set groups grant additive access and are the preferred way to model job functions.

Record-level access is the union of OWD, role hierarchy (if granted), sharing rules, teams, territories, and manual shares; access cannot be subtracted below OWD except via restrictions such as scoping.

Field-level security governs visibility and editability; it does not prevent SOQL from reading a field in Apex, so code must enforce FLS explicitly with WITH SECURITY_ENFORCED or stripInaccessible.

Authentication options: SAML 2.0 SSO, OpenID Connect, social sign-on, and multi-factor authentication; MFA is required for internal users under the platform's security baseline.

Connected Apps and OAuth flows: authorization code with PKCE for user-context web/mobile, JWT bearer flow for server-to-server, client credentials for machine-to-machine without a user.

Named credentials and external credentials store endpoint and secret material outside code; remote site settings alone are legacy and do not carry authentication.

Shield Platform Encryption encrypts data at rest with customer-controlled keys but preserves case-insensitive search only for deterministic schemes; probabilistic encryption breaks filtering and sorting.

Guest user access is highly restricted: no standard object access by default, sharing via guest user record access settings, and secure Apex must run in system mode with explicit checks.

Multi-tenancy means all tenants share infrastructure; the platform enforces governor limits per transaction to protect the shared pool, so designs must be bulkified and asynchronous where volume demands it.

Execution contexts differ: system mode (Apex without sharing) ignores sharing rules; user mode (with sharing / inherited sharing) enforces them. Choose deliberately and document it.

Asynchronous options: @future (simple callouts), Queueable (chaining, job IDs), Batch Apex (large volumes, chunked), Schedulable (time-based), and Platform Events for decoupled flows.

The order of execution for a DML save matters: validation rules, before triggers, duplicate rules, after triggers, assignment rules, workflows, flows, escalation, roll-ups, and commit.

Lightning Web Components are the modern UI stack; Aura remains for legacy; Visualforce persists for PDFs, email templates, and specific legacy needs.

Declarative automation choice: record-triggered flows for most automation, approval processes for sign-off, and Apex when logic needs recursion control, complex transactions, or callouts in triggers.

Apex trigger frameworks (one trigger per object, handler classes, recursion guards) reduce risk of order-dependent bugs and repeated execution.

Custom metadata types are for configuration that deploys between environments; custom settings are for data-like configuration, and their caching behavior differs.

Namespace and package strategy: managed packages for IP protection and upgradeability; unlocked packages for internal modular delivery.

Selectivity drives query performance: a filter is selective when it returns well under the threshold (broadly <10% of rows, and indexed), so index candidate fields used in WHERE clauses and avoid negative filters like != or NOT IN.

Standard indexes exist on Id, Name, OwnerId, CreatedDate, SystemModstamp, lookup/master-detail foreign keys, and external IDs; custom indexes are requested through support and are limited.

Skinny tables (support-assisted) copy frequently filtered fields to improve large-volume query speed; they must be refreshed after schema changes.

Avoid leading wildcards in SOQL, avoid SELECT in loops, and never issue queries inside for-loops; use relationship queries and maps to reduce round trips.

Bulkify: process collections with single SOQL/DML calls; governor limits are per transaction, so batch size and chunking determine scalability.

Batch Apex default batch size is 200; tuning batch size trades heap and CPU against total number of batches and total elapsed time.

Record locking and UNABLE_TO_LOCK_ROW errors come from concurrent updates to the same parent or skewed data; mitigate with retry logic and data distribution.

Performance testing must use production-like data volumes; a design that passes in a small sandbox can fail at millions of rows due to non-selective queries and sharing recalculation.

Monitor with debug logs, the query plan tool, Apex CPU time limits, and event monitoring for slow pages and API usage.

Environment strategy: sandbox types differ in refresh interval and data copy - Developer, Developer Pro, Partial Copy (template-based sample data), and Full Copy.

Deployment tools: change sets (point-and-click, limited metadata coverage), Salesforce CLI with metadata API or source format, and unlocked/managed second-generation packages for CI/CD.

A DevOps pipeline should include version control, automated tests with required coverage, static analysis (such as PMD rules), a staging validation deployment, and a production deploy with a rollback plan.

Apex test requirements for production deployment: at least 75% overall coverage, all tests passing, and triggers requiring coverage of their own; coverage is a floor, not a quality measure.

Governance artifacts: naming conventions, a metadata ownership map, a release calendar, an integration registry, and an architecture review gate for significant changes.

Change management must consider downstream dependencies: integrations, reports, dashboards, flows, and permission sets referencing renamed or deleted metadata.

Technical debt should be logged and prioritized; hard-coded IDs, unused fields, and overly permissive profiles are common debt items.

Data seeding and masking: use templates for partial sandboxes and anonymize PII before refreshing non-production environments.

Non-functional requirements to elicit explicitly: volume (records, transactions per second), latency, availability, retention, audit, localization, and regulatory constraints.

Design options should be evaluated against weighted criteria (fit, cost, risk, time-to-value, maintainability); the recommendation must state why rejected options lost.

Build vs. buy vs. extend: standard functionality first, then declarative configuration, then custom code, then third-party AppExchange, then external system integration.

Trade-off patterns: synchronous improves UX but couples availability; asynchronous improves resilience but complicates error handling and user feedback.

Licensing and limits are design constraints: API call allocations, storage, sandbox count, and feature licenses can invalidate an otherwise sound design.

Risk register entries should pair each risk with likelihood, impact, owner, and mitigation; unmitigated single points of failure are a common review finding.

Phased delivery reduces risk: prove the data model and security model first, then integration, then scale and optimize.

Assumptions must be documented and validated; a design that silently assumes data quality or volume will be challenged in review.

The review board presentation structure: business context, requirements and constraints, options considered, recommended design with diagrams, risks and mitigations, delivery plan, and open questions.

Diagrams must show system boundaries, data flows, trust boundaries, integration direction and protocol, and where identity is asserted and validated.

Tailor the message: executives need cost, risk, and timeline; engineers need data model, limits, and failure modes. The same design gets two narratives.

Anticipate board challenges: Why not standard functionality? What happens at 10x volume? How is PII protected? What is the rollback plan? Who owns operations?

Quantify claims: cite record volumes, API call counts, latency budgets, and storage estimates rather than qualitative assurances.

Document decisions as ADRs (context, decision, consequences) so future architects understand why a path was chosen.

Security reviews require data classification, access matrix by persona, encryption posture, and audit trail design.

A design that cannot be operated and monitored is incomplete; include alerting, runbooks, and ownership in the review.

The CTA (Certified Technical Architect) credential validates the ability to design, review, and defend multi-tenant solutions on the platform; the journey runs from prerequisites through instructor-led review, a proctored multiple-choice exam, and a scenario-based review board.

Core architect competencies: data model and security design, integration and API strategy, identity and access architecture, platform limits and scalability, lifecycle governance, and the ability to communicate trade-offs to both technical and executive audiences.

The exam rewards recognizing patterns and constraints over memorizing UI paths; questions typically present a business requirement plus constraints and ask for the best design or the most likely failure mode.

A solution design always starts from requirements: functional needs, non-functional needs (volume, latency, availability), constraints (licensing, budget, skills), and assumptions that must be validated with the customer.

The review board evaluates the design narrative: problem statement, options considered, why the chosen option wins, risks, mitigations, and a phased delivery plan. Designs without alternatives are usually challenged.

Declarative configuration is preferred over code where it satisfies the requirement; code (Apex, triggers, LWC) is justified when declarative tools cannot meet performance, complexity, or transactional requirements.

Every design decision carries a trade-off: customization increases fit but raises maintenance cost and upgrade risk; standardization lowers cost but may require process change.

Know the difference between a platform limit (hard, cannot be raised), an allocation (per-org entitlement that can be purchased), and a soft guideline (recommended practice).

Architect deliverables: solution design document, data model diagram, integration catalog, security model, non-functional requirements matrix, and a deployment/governance plan.

Standard objects (Account, Contact, Opportunity, Case, Lead, User) should be reused before creating custom objects; custom objects are justified when no standard object carries the semantics or lifecycle.

Relationship types: master-detail implies strong ownership, cascade delete, and roll-up summary support; lookup is loosely coupled and independent; many-to-many requires a junction object with two master-detail relationships.

Roll-up summary fields work only on master-detail relationships; for lookup-based aggregation use declarative roll-up or scheduled/async Apex aggregation.

External ID fields enable upsert, data loading matches, and integration correlation; every integration-facing object should carry a stable external identifier.

The 15-object limit on master-detail relationships per object and the 2 master-detail limit per child object constrain deep ownership hierarchies; plan junction and lookup alternatives early.

Record types plus page layout assignments control business process variation; avoid creating a new object per process variant when record types and picklists suffice.

Data skew (ownership skew, lookup skew) causes record lock contention and sharing performance problems; distribute ownership and avoid hot parent records in high-volume child inserts.

Data lifecycle: archive or delete obsolete records, define retention per object, and use the recycle bin and hard-delete tooling deliberately; large data volumes require indexing and selective queries.

Big objects store very large datasets with asynchronous access and no standard SOQL full-scan performance; use them for audit and historical archives, not for transactional UI needs.

Pattern selection: request-reply (synchronous) for real-time user-facing needs; fire-and-forget for non-critical events; batch for bulk; publish-subscribe for multi-consumer fan-out.

REST API suits resource-oriented, stateless, JSON interactions; SOAP is chosen when a WSDL contract, WS-Security, or strict typed operations are mandated by the partner.

Bulk API 2.0 is the tool for large data volumes (hundreds of thousands to millions of records); it is asynchronous, job-based, and governed by separate batch limits.

Composite API reduces round trips by bundling subrequests in one call; Composite Graph handles multiple unrelated records with references across them.

Platform Events and Change Data Capture support event-driven integration with replay IDs; Pub/Sub API provides gRPC/HTTP streaming access to those event streams.

Outbound messaging and callouts are subject to governor limits: cumulative callout time per transaction, callout size, and the 100-callout limit per transaction.

Idempotency is mandatory for inbound integrations: use external IDs plus upsert, or a dedupe key, so retries do not create duplicates.

Middleware (ESB/iPaaS) is justified when you need orchestration, protocol transformation, retry/queue semantics, or decoupling of many endpoints; point-to-point is acceptable for a few simple flows.

Error handling design: capture failures in a custom error object or platform event, define retry with backoff, and alert on dead-letter thresholds.

The sharing model is layered: organization-wide defaults (OWD) set the baseline, then role hierarchy, sharing rules, teams, manual sharing, and territory hierarchy widen access; Apex sharing recalculates only on explicit invocation.

OWD values: Private, Public Read Only, Public Read/Write, and (for some objects) Controlled by Parent; the most restrictive sensible OWD plus targeted sharing is the recommended posture.

Profiles define object/field permissions and are assigned one per user; permission sets and permission set groups grant additive access and are the preferred way to model job functions.

Record-level access is the union of OWD, role hierarchy (if granted), sharing rules, teams, territories, and manual shares; access cannot be subtracted below OWD except via restrictions such as scoping.

Field-level security governs visibility and editability; it does not prevent SOQL from reading a field in Apex, so code must enforce FLS explicitly with WITH SECURITY_ENFORCED or stripInaccessible.

Authentication options: SAML 2.0 SSO, OpenID Connect, social sign-on, and multi-factor authentication; MFA is required for internal users under the platform's security baseline.

Connected Apps and OAuth flows: authorization code with PKCE for user-context web/mobile, JWT bearer flow for server-to-server, client credentials for machine-to-machine without a user.

Named credentials and external credentials store endpoint and secret material outside code; remote site settings alone are legacy and do not carry authentication.

Shield Platform Encryption encrypts data at rest with customer-controlled keys but preserves case-insensitive search only for deterministic schemes; probabilistic encryption breaks filtering and sorting.

Guest user access is highly restricted: no standard object access by default, sharing via guest user record access settings, and secure Apex must run in system mode with explicit checks.

Multi-tenancy means all tenants share infrastructure; the platform enforces governor limits per transaction to protect the shared pool, so designs must be bulkified and asynchronous where volume demands it.

Execution contexts differ: system mode (Apex without sharing) ignores sharing rules; user mode (with sharing / inherited sharing) enforces them. Choose deliberately and document it.

Asynchronous options: @future (simple callouts), Queueable (chaining, job IDs), Batch Apex (large volumes, chunked), Schedulable (time-based), and Platform Events for decoupled flows.

The order of execution for a DML save matters: validation rules, before triggers, duplicate rules, after triggers, assignment rules, workflows, flows, escalation, roll-ups, and commit.

Lightning Web Components are the modern UI stack; Aura remains for legacy; Visualforce persists for PDFs, email templates, and specific legacy needs.

Declarative automation choice: record-triggered flows for most automation, approval processes for sign-off, and Apex when logic needs recursion control, complex transactions, or callouts in triggers.

Apex trigger frameworks (one trigger per object, handler classes, recursion guards) reduce risk of order-dependent bugs and repeated execution.

Custom metadata types are for configuration that deploys between environments; custom settings are for data-like configuration, and their caching behavior differs.

Namespace and package strategy: managed packages for IP protection and upgradeability; unlocked packages for internal modular delivery.

Selectivity drives query performance: a filter is selective when it returns well under the threshold (broadly <10% of rows, and indexed), so index candidate fields used in WHERE clauses and avoid negative filters like != or NOT IN.

Standard indexes exist on Id, Name, OwnerId, CreatedDate, SystemModstamp, lookup/master-detail foreign keys, and external IDs; custom indexes are requested through support and are limited.

Skinny tables (support-assisted) copy frequently filtered fields to improve large-volume query speed; they must be refreshed after schema changes.

Avoid leading wildcards in SOQL, avoid SELECT in loops, and never issue queries inside for-loops; use relationship queries and maps to reduce round trips.

Bulkify: process collections with single SOQL/DML calls; governor limits are per transaction, so batch size and chunking determine scalability.

Batch Apex default batch size is 200; tuning batch size trades heap and CPU against total number of batches and total elapsed time.

Record locking and UNABLE_TO_LOCK_ROW errors come from concurrent updates to the same parent or skewed data; mitigate with retry logic and data distribution.

Performance testing must use production-like data volumes; a design that passes in a small sandbox can fail at millions of rows due to non-selective queries and sharing recalculation.

Monitor with debug logs, the query plan tool, Apex CPU time limits, and event monitoring for slow pages and API usage.

Environment strategy: sandbox types differ in refresh interval and data copy - Developer, Developer Pro, Partial Copy (template-based sample data), and Full Copy.

Deployment tools: change sets (point-and-click, limited metadata coverage), Salesforce CLI with metadata API or source format, and unlocked/managed second-generation packages for CI/CD.

A DevOps pipeline should include version control, automated tests with required coverage, static analysis (such as PMD rules), a staging validation deployment, and a production deploy with a rollback plan.

Apex test requirements for production deployment: at least 75% overall coverage, all tests passing, and triggers requiring coverage of their own; coverage is a floor, not a quality measure.

Governance artifacts: naming conventions, a metadata ownership map, a release calendar, an integration registry, and an architecture review gate for significant changes.

Change management must consider downstream dependencies: integrations, reports, dashboards, flows, and permission sets referencing renamed or deleted metadata.

Technical debt should be logged and prioritized; hard-coded IDs, unused fields, and overly permissive profiles are common debt items.

Data seeding and masking: use templates for partial sandboxes and anonymize PII before refreshing non-production environments.

Non-functional requirements to elicit explicitly: volume (records, transactions per second), latency, availability, retention, audit, localization, and regulatory constraints.

Design options should be evaluated against weighted criteria (fit, cost, risk, time-to-value, maintainability); the recommendation must state why rejected options lost.

Build vs. buy vs. extend: standard functionality first, then declarative configuration, then custom code, then third-party AppExchange, then external system integration.

Trade-off patterns: synchronous improves UX but couples availability; asynchronous improves resilience but complicates error handling and user feedback.

Licensing and limits are design constraints: API call allocations, storage, sandbox count, and feature licenses can invalidate an otherwise sound design.

Risk register entries should pair each risk with likelihood, impact, owner, and mitigation; unmitigated single points of failure are a common review finding.

Phased delivery reduces risk: prove the data model and security model first, then integration, then scale and optimize.

Assumptions must be documented and validated; a design that silently assumes data quality or volume will be challenged in review.

The review board presentation structure: business context, requirements and constraints, options considered, recommended design with diagrams, risks and mitigations, delivery plan, and open questions.

Diagrams must show system boundaries, data flows, trust boundaries, integration direction and protocol, and where identity is asserted and validated.

Tailor the message: executives need cost, risk, and timeline; engineers need data model, limits, and failure modes. The same design gets two narratives.

Anticipate board challenges: Why not standard functionality? What happens at 10x volume? How is PII protected? What is the rollback plan? Who owns operations?

Quantify claims: cite record volumes, API call counts, latency budgets, and storage estimates rather than qualitative assurances.

Document decisions as ADRs (context, decision, consequences) so future architects understand why a path was chosen.

Security reviews require data classification, access matrix by persona, encryption posture, and audit trail design.

A design that cannot be operated and monitored is incomplete; include alerting, runbooks, and ownership in the review.

The CTA (Certified Technical Architect) credential validates the ability to design, review, and defend multi-tenant solutions on the platform; the journey runs from prerequisites through instructor-led review, a proctored multiple-choice exam, and a scenario-based review board.

Core architect competencies: data model and security design, integration and API strategy, identity and access architecture, platform limits and scalability, lifecycle governance, and the ability to communicate trade-offs to both technical and executive audiences.

The exam rewards recognizing patterns and constraints over memorizing UI paths; questions typically present a business requirement plus constraints and ask for the best design or the most likely failure mode.

A solution design always starts from requirements: functional needs, non-functional needs (volume, latency, availability), constraints (licensing, budget, skills), and assumptions that must be validated with the customer.

The review board evaluates the design narrative: problem statement, options considered, why the chosen option wins, risks, mitigations, and a phased delivery plan. Designs without alternatives are usually challenged.

Declarative configuration is preferred over code where it satisfies the requirement; code (Apex, triggers, LWC) is justified when declarative tools cannot meet performance, complexity, or transactional requirements.

Every design decision carries a trade-off: customization increases fit but raises maintenance cost and upgrade risk; standardization lowers cost but may require process change.

Know the difference between a platform limit (hard, cannot be raised), an allocation (per-org entitlement that can be purchased), and a soft guideline (recommended practice).

Architect deliverables: solution design document, data model diagram, integration catalog, security model, non-functional requirements matrix, and a deployment/governance plan.

Standard objects (Account, Contact, Opportunity, Case, Lead, User) should be reused before creating custom objects; custom objects are justified when no standard object carries the semantics or lifecycle.

Relationship types: master-detail implies strong ownership, cascade delete, and roll-up summary support; lookup is loosely coupled and independent; many-to-many requires a junction object with two master-detail relationships.

Roll-up summary fields work only on master-detail relationships; for lookup-based aggregation use declarative roll-up or scheduled/async Apex aggregation.

External ID fields enable upsert, data loading matches, and integration correlation; every integration-facing object should carry a stable external identifier.

The 15-object limit on master-detail relationships per object and the 2 master-detail limit per child object constrain deep ownership hierarchies; plan junction and lookup alternatives early.

Record types plus page layout assignments control business process variation; avoid creating a new object per process variant when record types and picklists suffice.

Data skew (ownership skew, lookup skew) causes record lock contention and sharing performance problems; distribute ownership and avoid hot parent records in high-volume child inserts.

Data lifecycle: archive or delete obsolete records, define retention per object, and use the recycle bin and hard-delete tooling deliberately; large data volumes require indexing and selective queries.

Big objects store very large datasets with asynchronous access and no standard SOQL full-scan performance; use them for audit and historical archives, not for transactional UI needs.

Pattern selection: request-reply (synchronous) for real-time user-facing needs; fire-and-forget for non-critical events; batch for bulk; publish-subscribe for multi-consumer fan-out.

REST API suits resource-oriented, stateless, JSON interactions; SOAP is chosen when a WSDL contract, WS-Security, or strict typed operations are mandated by the partner.

Bulk API 2.0 is the tool for large data volumes (hundreds of thousands to millions of records); it is asynchronous, job-based, and governed by separate batch limits.

Composite API reduces round trips by bundling subrequests in one call; Composite Graph handles multiple unrelated records with references across them.

Platform Events and Change Data Capture support event-driven integration with replay IDs; Pub/Sub API provides gRPC/HTTP streaming access to those event streams.

Outbound messaging and callouts are subject to governor limits: cumulative callout time per transaction, callout size, and the 100-callout limit per transaction.

Idempotency is mandatory for inbound integrations: use external IDs plus upsert, or a dedupe key, so retries do not create duplicates.

Middleware (ESB/iPaaS) is justified when you need orchestration, protocol transformation, retry/queue semantics, or decoupling of many endpoints; point-to-point is acceptable for a few simple flows.

Error handling design: capture failures in a custom error object or platform event, define retry with backoff, and alert on dead-letter thresholds.

The sharing model is layered: organization-wide defaults (OWD) set the baseline, then role hierarchy, sharing rules, teams, manual sharing, and territory hierarchy widen access; Apex sharing recalculates only on explicit invocation.

OWD values: Private, Public Read Only, Public Read/Write, and (for some objects) Controlled by Parent; the most restrictive sensible OWD plus targeted sharing is the recommended posture.

Profiles define object/field permissions and are assigned one per user; permission sets and permission set groups grant additive access and are the preferred way to model job functions.

Record-level access is the union of OWD, role hierarchy (if granted), sharing rules, teams, territories, and manual shares; access cannot be subtracted below OWD except via restrictions such as scoping.

Field-level security governs visibility and editability; it does not prevent SOQL from reading a field in Apex, so code must enforce FLS explicitly with WITH SECURITY_ENFORCED or stripInaccessible.

Authentication options: SAML 2.0 SSO, OpenID Connect, social sign-on, and multi-factor authentication; MFA is required for internal users under the platform's security baseline.

Connected Apps and OAuth flows: authorization code with PKCE for user-context web/mobile, JWT bearer flow for server-to-server, client credentials for machine-to-machine without a user.

Named credentials and external credentials store endpoint and secret material outside code; remote site settings alone are legacy and do not carry authentication.

Shield Platform Encryption encrypts data at rest with customer-controlled keys but preserves case-insensitive search only for deterministic schemes; probabilistic encryption breaks filtering and sorting.

Guest user access is highly restricted: no standard object access by default, sharing via guest user record access settings, and secure Apex must run in system mode with explicit checks.

Multi-tenancy means all tenants share infrastructure; the platform enforces governor limits per transaction to protect the shared pool, so designs must be bulkified and asynchronous where volume demands it.

Execution contexts differ: system mode (Apex without sharing) ignores sharing rules; user mode (with sharing / inherited sharing) enforces them. Choose deliberately and document it.

Asynchronous options: @future (simple callouts), Queueable (chaining, job IDs), Batch Apex (large volumes, chunked), Schedulable (time-based), and Platform Events for decoupled flows.

The order of execution for a DML save matters: validation rules, before triggers, duplicate rules, after triggers, assignment rules, workflows, flows, escalation, roll-ups, and commit.

Lightning Web Components are the modern UI stack; Aura remains for legacy; Visualforce persists for PDFs, email templates, and specific legacy needs.

Declarative automation choice: record-triggered flows for most automation, approval processes for sign-off, and Apex when logic needs recursion control, complex transactions, or callouts in triggers.

Apex trigger frameworks (one trigger per object, handler classes, recursion guards) reduce risk of order-dependent bugs and repeated execution.

Custom metadata types are for configuration that deploys between environments; custom settings are for data-like configuration, and their caching behavior differs.

Namespace and package strategy: managed packages for IP protection and upgradeability; unlocked packages for internal modular delivery.

Selectivity drives query performance: a filter is selective when it returns well under the threshold (broadly <10% of rows, and indexed), so index candidate fields used in WHERE clauses and avoid negative filters like != or NOT IN.

Standard indexes exist on Id, Name, OwnerId, CreatedDate, SystemModstamp, lookup/master-detail foreign keys, and external IDs; custom indexes are requested through support and are limited.

Skinny tables (support-assisted) copy frequently filtered fields to improve large-volume query speed; they must be refreshed after schema changes.

Avoid leading wildcards in SOQL, avoid SELECT in loops, and never issue queries inside for-loops; use relationship queries and maps to reduce round trips.

Bulkify: process collections with single SOQL/DML calls; governor limits are per transaction, so batch size and chunking determine scalability.

Batch Apex default batch size is 200; tuning batch size trades heap and CPU against total number of batches and total elapsed time.

Record locking and UNABLE_TO_LOCK_ROW errors come from concurrent updates to the same parent or skewed data; mitigate with retry logic and data distribution.

Performance testing must use production-like data volumes; a design that passes in a small sandbox can fail at millions of rows due to non-selective queries and sharing recalculation.

Monitor with debug logs, the query plan tool, Apex CPU time limits, and event monitoring for slow pages and API usage.

Environment strategy: sandbox types differ in refresh interval and data copy - Developer, Developer Pro, Partial Copy (template-based sample data), and Full Copy.

Deployment tools: change sets (point-and-click, limited metadata coverage), Salesforce CLI with metadata API or source format, and unlocked/managed second-generation packages for CI/CD.

A DevOps pipeline should include version control, automated tests with required coverage, static analysis (such as PMD rules), a staging validation deployment, and a production deploy with a rollback plan.

Apex test requirements for production deployment: at least 75% overall coverage, all tests passing, and triggers requiring coverage of their own; coverage is a floor, not a quality measure.

Governance artifacts: naming conventions, a metadata ownership map, a release calendar, an integration registry, and an architecture review gate for significant changes.

Change management must consider downstream dependencies: integrations, reports, dashboards, flows, and permission sets referencing renamed or deleted metadata.

Technical debt should be logged and prioritized; hard-coded IDs, unused fields, and overly permissive profiles are common debt items.

Data seeding and masking: use templates for partial sandboxes and anonymize PII before refreshing non-production environments.

Non-functional requirements to elicit explicitly: volume (records, transactions per second), latency, availability, retention, audit, localization, and regulatory constraints.

Design options should be evaluated against weighted criteria (fit, cost, risk, time-to-value, maintainability); the recommendation must state why rejected options lost.

Build vs. buy vs. extend: standard functionality first, then declarative configuration, then custom code, then third-party AppExchange, then external system integration.

Trade-off patterns: synchronous improves UX but couples availability; asynchronous improves resilience but complicates error handling and user feedback.

Licensing and limits are design constraints: API call allocations, storage, sandbox count, and feature licenses can invalidate an otherwise sound design.

Risk register entries should pair each risk with likelihood, impact, owner, and mitigation; unmitigated single points of failure are a common review finding.

Phased delivery reduces risk: prove the data model and security model first, then integration, then scale and optimize.

Assumptions must be documented and validated; a design that silently assumes data quality or volume will be challenged in review.

The review board presentation structure: business context, requirements and constraints, options considered, recommended design with diagrams, risks and mitigations, delivery plan, and open questions.

Diagrams must show system boundaries, data flows, trust boundaries, integration direction and protocol, and where identity is asserted and validated.

Tailor the message: executives need cost, risk, and timeline; engineers need data model, limits, and failure modes. The same design gets two narratives.

Anticipate board challenges: Why not standard functionality? What happens at 10x volume? How is PII protected? What is the rollback plan? Who owns operations?

Quantify claims: cite record volumes, API call counts, latency budgets, and storage estimates rather than qualitative assurances.

Document decisions as ADRs (context, decision, consequences) so future architects understand why a path was chosen.

Security reviews require data classification, access matrix by persona, encryption posture, and audit trail design.

A design that cannot be operated and monitored is incomplete; include alerting, runbooks, and ownership in the review.

The CTA (Certified Technical Architect) credential validates the ability to design, review, and defend multi-tenant solutions on the platform; the journey runs from prerequisites through instructor-led review, a proctored multiple-choice exam, and a scenario-based review board.

Core architect competencies: data model and security design, integration and API strategy, identity and access architecture, platform limits and scalability, lifecycle governance, and the ability to communicate trade-offs to both technical and executive audiences.

The exam rewards recognizing patterns and constraints over memorizing UI paths; questions typically present a business requirement plus constraints and ask for the best design or the most likely failure mode.

A solution design always starts from requirements: functional needs, non-functional needs (volume, latency, availability), constraints (licensing, budget, skills), and assumptions that must be validated with the customer.

The review board evaluates the design narrative: problem statement, options considered, why the chosen option wins, risks, mitigations, and a phased delivery plan. Designs without alternatives are usually challenged.

Declarative configuration is preferred over code where it satisfies the requirement; code (Apex, triggers, LWC) is justified when declarative tools cannot meet performance, complexity, or transactional requirements.

Every design decision carries a trade-off: customization increases fit but raises maintenance cost and upgrade risk; standardization lowers cost but may require process change.

Know the difference between a platform limit (hard, cannot be raised), an allocation (per-org entitlement that can be purchased), and a soft guideline (recommended practice).

Architect deliverables: solution design document, data model diagram, integration catalog, security model, non-functional requirements matrix, and a deployment/governance plan.

Standard objects (Account, Contact, Opportunity, Case, Lead, User) should be reused before creating custom objects; custom objects are justified when no standard object carries the semantics or lifecycle.

Relationship types: master-detail implies strong ownership, cascade delete, and roll-up summary support; lookup is loosely coupled and independent; many-to-many requires a junction object with two master-detail relationships.

Roll-up summary fields work only on master-detail relationships; for lookup-based aggregation use declarative roll-up or scheduled/async Apex aggregation.

External ID fields enable upsert, data loading matches, and integration correlation; every integration-facing object should carry a stable external identifier.

The 15-object limit on master-detail relationships per object and the 2 master-detail limit per child object constrain deep ownership hierarchies; plan junction and lookup alternatives early.

Record types plus page layout assignments control business process variation; avoid creating a new object per process variant when record types and picklists suffice.

Data skew (ownership skew, lookup skew) causes record lock contention and sharing performance problems; distribute ownership and avoid hot parent records in high-volume child inserts.

Data lifecycle: archive or delete obsolete records, define retention per object, and use the recycle bin and hard-delete tooling deliberately; large data volumes require indexing and selective queries.

Big objects store very large datasets with asynchronous access and no standard SOQL full-scan performance; use them for audit and historical archives, not for transactional UI needs.

Pattern selection: request-reply (synchronous) for real-time user-facing needs; fire-and-forget for non-critical events; batch for bulk; publish-subscribe for multi-consumer fan-out.

REST API suits resource-oriented, stateless, JSON interactions; SOAP is chosen when a WSDL contract, WS-Security, or strict typed operations are mandated by the partner.

Bulk API 2.0 is the tool for large data volumes (hundreds of thousands to millions of records); it is asynchronous, job-based, and governed by separate batch limits.

Composite API reduces round trips by bundling subrequests in one call; Composite Graph handles multiple unrelated records with references across them.

Platform Events and Change Data Capture support event-driven integration with replay IDs; Pub/Sub API provides gRPC/HTTP streaming access to those event streams.

Outbound messaging and callouts are subject to governor limits: cumulative callout time per transaction, callout size, and the 100-callout limit per transaction.

Idempotency is mandatory for inbound integrations: use external IDs plus upsert, or a dedupe key, so retries do not create duplicates.

Middleware (ESB/iPaaS) is justified when you need orchestration, protocol transformation, retry/queue semantics, or decoupling of many endpoints; point-to-point is acceptable for a few simple flows.

Error handling design: capture failures in a custom error object or platform event, define retry with backoff, and alert on dead-letter thresholds.

The sharing model is layered: organization-wide defaults (OWD) set the baseline, then role hierarchy, sharing rules, teams, manual sharing, and territory hierarchy widen access; Apex sharing recalculates only on explicit invocation.

OWD values: Private, Public Read Only, Public Read/Write, and (for some objects) Controlled by Parent; the most restrictive sensible OWD plus targeted sharing is the recommended posture.

Profiles define object/field permissions and are assigned one per user; permission sets and permission set groups grant additive access and are the preferred way to model job functions.

Record-level access is the union of OWD, role hierarchy (if granted), sharing rules, teams, territories, and manual shares; access cannot be subtracted below OWD except via restrictions such as scoping.

Field-level security governs visibility and editability; it does not prevent SOQL from reading a field in Apex, so code must enforce FLS explicitly with WITH SECURITY_ENFORCED or stripInaccessible.

Authentication options: SAML 2.0 SSO, OpenID Connect, social sign-on, and multi-factor authentication; MFA is required for internal users under the platform's security baseline.

Connected Apps and OAuth flows: authorization code with PKCE for user-context web/mobile, JWT bearer flow for server-to-server, client credentials for machine-to-machine without a user.

Named credentials and external credentials store endpoint and secret material outside code; remote site settings alone are legacy and do not carry authentication.

Shield Platform Encryption encrypts data at rest with customer-controlled keys but preserves case-insensitive search only for deterministic schemes; probabilistic encryption breaks filtering and sorting.

Guest user access is highly restricted: no standard object access by default, sharing via guest user record access settings, and secure Apex must run in system mode with explicit checks.

Multi-tenancy means all tenants share infrastructure; the platform enforces governor limits per transaction to protect the shared pool, so designs must be bulkified and asynchronous where volume demands it.

Execution contexts differ: system mode (Apex without sharing) ignores sharing rules; user mode (with sharing / inherited sharing) enforces them. Choose deliberately and document it.

Asynchronous options: @future (simple callouts), Queueable (chaining, job IDs), Batch Apex (large volumes, chunked), Schedulable (time-based), and Platform Events for decoupled flows.

The order of execution for a DML save matters: validation rules, before triggers, duplicate rules, after triggers, assignment rules, workflows, flows, escalation, roll-ups, and commit.

Lightning Web Components are the modern UI stack; Aura remains for legacy; Visualforce persists for PDFs, email templates, and specific legacy needs.

Declarative automation choice: record-triggered flows for most automation, approval processes for sign-off, and Apex when logic needs recursion control, complex transactions, or callouts in triggers.

Apex trigger frameworks (one trigger per object, handler classes, recursion guards) reduce risk of order-dependent bugs and repeated execution.

Custom metadata types are for configuration that deploys between environments; custom settings are for data-like configuration, and their caching behavior differs.

Namespace and package strategy: managed packages for IP protection and upgradeability; unlocked packages for internal modular delivery.

Selectivity drives query performance: a filter is selective when it returns well under the threshold (broadly <10% of rows, and indexed), so index candidate fields used in WHERE clauses and avoid negative filters like != or NOT IN.

Standard indexes exist on Id, Name, OwnerId, CreatedDate, SystemModstamp, lookup/master-detail foreign keys, and external IDs; custom indexes are requested through support and are limited.

Skinny tables (support-assisted) copy frequently filtered fields to improve large-volume query speed; they must be refreshed after schema changes.

Avoid leading wildcards in SOQL, avoid SELECT in loops, and never issue queries inside for-loops; use relationship queries and maps to reduce round trips.

Bulkify: process collections with single SOQL/DML calls; governor limits are per transaction, so batch size and chunking determine scalability.

Batch Apex default batch size is 200; tuning batch size trades heap and CPU against total number of batches and total elapsed time.

Record locking and UNABLE_TO_LOCK_ROW errors come from concurrent updates to the same parent or skewed data; mitigate with retry logic and data distribution.

Performance testing must use production-like data volumes; a design that passes in a small sandbox can fail at millions of rows due to non-selective queries and sharing recalculation.

Monitor with debug logs, the query plan tool, Apex CPU time limits, and event monitoring for slow pages and API usage.

Environment strategy: sandbox types differ in refresh interval and data copy - Developer, Developer Pro, Partial Copy (template-based sample data), and Full Copy.

Deployment tools: change sets (point-and-click, limited metadata coverage), Salesforce CLI with metadata API or source format, and unlocked/managed second-generation packages for CI/CD.

A DevOps pipeline should include version control, automated tests with required coverage, static analysis (such as PMD rules), a staging validation deployment, and a production deploy with a rollback plan.

Apex test requirements for production deployment: at least 75% overall coverage, all tests passing, and triggers requiring coverage of their own; coverage is a floor, not a quality measure.

Governance artifacts: naming conventions, a metadata ownership map, a release calendar, an integration registry, and an architecture review gate for significant changes.

Change management must consider downstream dependencies: integrations, reports, dashboards, flows, and permission sets referencing renamed or deleted metadata.

Technical debt should be logged and prioritized; hard-coded IDs, unused fields, and overly permissive profiles are common debt items.

Data seeding and masking: use templates for partial sandboxes and anonymize PII before refreshing non-production environments.

Non-functional requirements to elicit explicitly: volume (records, transactions per second), latency, availability, retention, audit, localization, and regulatory constraints.

Design options should be evaluated against weighted criteria (fit, cost, risk, time-to-value, maintainability); the recommendation must state why rejected options lost.

Build vs. buy vs. extend: standard functionality first, then declarative configuration, then custom code, then third-party AppExchange, then external system integration.

Trade-off patterns: synchronous improves UX but couples availability; asynchronous improves resilience but complicates error handling and user feedback.

Licensing and limits are design constraints: API call allocations, storage, sandbox count, and feature licenses can invalidate an otherwise sound design.

Risk register entries should pair each risk with likelihood, impact, owner, and mitigation; unmitigated single points of failure are a common review finding.

Phased delivery reduces risk: prove the data model and security model first, then integration, then scale and optimize.

Assumptions must be documented and validated; a design that silently assumes data quality or volume will be challenged in review.

The review board presentation structure: business context, requirements and constraints, options considered, recommended design with diagrams, risks and mitigations, delivery plan, and open questions.

Diagrams must show system boundaries, data flows, trust boundaries, integration direction and protocol, and where identity is asserted and validated.

Tailor the message: executives need cost, risk, and timeline; engineers need data model, limits, and failure modes. The same design gets two narratives.

Anticipate board challenges: Why not standard functionality? What happens at 10x volume? How is PII protected? What is the rollback plan? Who owns operations?

Quantify claims: cite record volumes, API call counts, latency budgets, and storage estimates rather than qualitative assurances.

Document decisions as ADRs (context, decision, consequences) so future architects understand why a path was chosen.

Security reviews require data classification, access matrix by persona, encryption posture, and audit trail design.

A design that cannot be operated and monitored is incomplete; include alerting, runbooks, and ownership in the review.

The CTA (Certified Technical Architect) credential validates the ability to design, review, and defend multi-tenant solutions on the platform; the journey runs from prerequisites through instructor-led review, a proctored multiple-choice exam, and a scenario-based review board.

Core architect competencies: data model and security design, integration and API strategy, identity and access architecture, platform limits and scalability, lifecycle governance, and the ability to communicate trade-offs to both technical and executive audiences.

The exam rewards recognizing patterns and constraints over memorizing UI paths; questions typically present a business requirement plus constraints and ask for the best design or the most likely failure mode.

A solution design always starts from requirements: functional needs, non-functional needs (volume, latency, availability), constraints (licensing, budget, skills), and assumptions that must be validated with the customer.

The review board evaluates the design narrative: problem statement, options considered, why the chosen option wins, risks, mitigations, and a phased delivery plan. Designs without alternatives are usually challenged.

Declarative configuration is preferred over code where it satisfies the requirement; code (Apex, triggers, LWC) is justified when declarative tools cannot meet performance, complexity, or transactional requirements.

Every design decision carries a trade-off: customization increases fit but raises maintenance cost and upgrade risk; standardization lowers cost but may require process change.

Know the difference between a platform limit (hard, cannot be raised), an allocation (per-org entitlement that can be purchased), and a soft guideline (recommended practice).

Architect deliverables: solution design document, data model diagram, integration catalog, security model, non-functional requirements matrix, and a deployment/governance plan.

Standard objects (Account, Contact, Opportunity, Case, Lead, User) should be reused before creating custom objects; custom objects are justified when no standard object carries the semantics or lifecycle.

Relationship types: master-detail implies strong ownership, cascade delete, and roll-up summary support; lookup is loosely coupled and independent; many-to-many requires a junction object with two master-detail relationships.

Roll-up summary fields work only on master-detail relationships; for lookup-based aggregation use declarative roll-up or scheduled/async Apex aggregation.

External ID fields enable upsert, data loading matches, and integration correlation; every integration-facing object should carry a stable external identifier.

The 15-object limit on master-detail relationships per object and the 2 master-detail limit per child object constrain deep ownership hierarchies; plan junction and lookup alternatives early.

Record types plus page layout assignments control business process variation; avoid creating a new object per process variant when record types and picklists suffice.

Data skew (ownership skew, lookup skew) causes record lock contention and sharing performance problems; distribute ownership and avoid hot parent records in high-volume child inserts.

Data lifecycle: archive or delete obsolete records, define retention per object, and use the recycle bin and hard-delete tooling deliberately; large data volumes require indexing and selective queries.

Big objects store very large datasets with asynchronous access and no standard SOQL full-scan performance; use them for audit and historical archives, not for transactional UI needs.

Pattern selection: request-reply (synchronous) for real-time user-facing needs; fire-and-forget for non-critical events; batch for bulk; publish-subscribe for multi-consumer fan-out.

REST API suits resource-oriented, stateless, JSON interactions; SOAP is chosen when a WSDL contract, WS-Security, or strict typed operations are mandated by the partner.

Bulk API 2.0 is the tool for large data volumes (hundreds of thousands to millions of records); it is asynchronous, job-based, and governed by separate batch limits.

Composite API reduces round trips by bundling subrequests in one call; Composite Graph handles multiple unrelated records with references across them.

Platform Events and Change Data Capture support event-driven integration with replay IDs; Pub/Sub API provides gRPC/HTTP streaming access to those event streams.

Outbound messaging and callouts are subject to governor limits: cumulative callout time per transaction, callout size, and the 100-callout limit per transaction.

Idempotency is mandatory for inbound integrations: use external IDs plus upsert, or a dedupe key, so retries do not create duplicates.

Middleware (ESB/iPaaS) is justified when you need orchestration, protocol transformation, retry/queue semantics, or decoupling of many endpoints; point-to-point is acceptable for a few simple flows.

Error handling design: capture failures in a custom error object or platform event, define retry with backoff, and alert on dead-letter thresholds.

The sharing model is layered: organization-wide defaults (OWD) set the baseline, then role hierarchy, sharing rules, teams, manual sharing, and territory hierarchy widen access; Apex sharing recalculates only on explicit invocation.

OWD values: Private, Public Read Only, Public Read/Write, and (for some objects) Controlled by Parent; the most restrictive sensible OWD plus targeted sharing is the recommended posture.

Profiles define object/field permissions and are assigned one per user; permission sets and permission set groups grant additive access and are the preferred way to model job functions.

Record-level access is the union of OWD, role hierarchy (if granted), sharing rules, teams, territories, and manual shares; access cannot be subtracted below OWD except via restrictions such as scoping.

Field-level security governs visibility and editability; it does not prevent SOQL from reading a field in Apex, so code must enforce FLS explicitly with WITH SECURITY_ENFORCED or stripInaccessible.

Authentication options: SAML 2.0 SSO, OpenID Connect, social sign-on, and multi-factor authentication; MFA is required for internal users under the platform's security baseline.

Connected Apps and OAuth flows: authorization code with PKCE for user-context web/mobile, JWT bearer flow for server-to-server, client credentials for machine-to-machine without a user.

Named credentials and external credentials store endpoint and secret material outside code; remote site settings alone are legacy and do not carry authentication.

Shield Platform Encryption encrypts data at rest with customer-controlled keys but preserves case-insensitive search only for deterministic schemes; probabilistic encryption breaks filtering and sorting.

Guest user access is highly restricted: no standard object access by default, sharing via guest user record access settings, and secure Apex must run in system mode with explicit checks.

Multi-tenancy means all tenants share infrastructure; the platform enforces governor limits per transaction to protect the shared pool, so designs must be bulkified and asynchronous where volume demands it.

Execution contexts differ: system mode (Apex without sharing) ignores sharing rules; user mode (with sharing / inherited sharing) enforces them. Choose deliberately and document it.

Asynchronous options: @future (simple callouts), Queueable (chaining, job IDs), Batch Apex (large volumes, chunked), Schedulable (time-based), and Platform Events for decoupled flows.

The order of execution for a DML save matters: validation rules, before triggers, duplicate rules, after triggers, assignment rules, workflows, flows, escalation, roll-ups, and commit.

Lightning Web Components are the modern UI stack; Aura remains for legacy; Visualforce persists for PDFs, email templates, and specific legacy needs.

Declarative automation choice: record-triggered flows for most automation, approval processes for sign-off, and Apex when logic needs recursion control, complex transactions, or callouts in triggers.

Apex trigger frameworks (one trigger per object, handler classes, recursion guards) reduce risk of order-dependent bugs and repeated execution.

Custom metadata types are for configuration that deploys between environments; custom settings are for data-like configuration, and their caching behavior differs.

Namespace and package strategy: managed packages for IP protection and upgradeability; unlocked packages for internal modular delivery.

Selectivity drives query performance: a filter is selective when it returns well under the threshold (broadly <10% of rows, and indexed), so index candidate fields used in WHERE clauses and avoid negative filters like != or NOT IN.

Standard indexes exist on Id, Name, OwnerId, CreatedDate, SystemModstamp, lookup/master-detail foreign keys, and external IDs; custom indexes are requested through support and are limited.

Skinny tables (support-assisted) copy frequently filtered fields to improve large-volume query speed; they must be refreshed after schema changes.

Avoid leading wildcards in SOQL, avoid SELECT in loops, and never issue queries inside for-loops; use relationship queries and maps to reduce round trips.

Bulkify: process collections with single SOQL/DML calls; governor limits are per transaction, so batch size and chunking determine scalability.

Batch Apex default batch size is 200; tuning batch size trades heap and CPU against total number of batches and total elapsed time.

Record locking and UNABLE_TO_LOCK_ROW errors come from concurrent updates to the same parent or skewed data; mitigate with retry logic and data distribution.

Performance testing must use production-like data volumes; a design that passes in a small sandbox can fail at millions of rows due to non-selective queries and sharing recalculation.

Monitor with debug logs, the query plan tool, Apex CPU time limits, and event monitoring for slow pages and API usage.

Environment strategy: sandbox types differ in refresh interval and data copy - Developer, Developer Pro, Partial Copy (template-based sample data), and Full Copy.

Deployment tools: change sets (point-and-click, limited metadata coverage), Salesforce CLI with metadata API or source format, and unlocked/managed second-generation packages for CI/CD.

A DevOps pipeline should include version control, automated tests with required coverage, static analysis (such as PMD rules), a staging validation deployment, and a production deploy with a rollback plan.

Apex test requirements for production deployment: at least 75% overall coverage, all tests passing, and triggers requiring coverage of their own; coverage is a floor, not a quality measure.

Governance artifacts: naming conventions, a metadata ownership map, a release calendar, an integration registry, and an architecture review gate for significant changes.

Change management must consider downstream dependencies: integrations, reports, dashboards, flows, and permission sets referencing renamed or deleted metadata.

Technical debt should be logged and prioritized; hard-coded IDs, unused fields, and overly permissive profiles are common debt items.

Data seeding and masking: use templates for partial sandboxes and anonymize PII before refreshing non-production environments.

Non-functional requirements to elicit explicitly: volume (records, transactions per second), latency, availability, retention, audit, localization, and regulatory constraints.

Design options should be evaluated against weighted criteria (fit, cost, risk, time-to-value, maintainability); the recommendation must state why rejected options lost.

Build vs. buy vs. extend: standard functionality first, then declarative configuration, then custom code, then third-party AppExchange, then external system integration.

Trade-off patterns: synchronous improves UX but couples availability; asynchronous improves resilience but complicates error handling and user feedback.

Licensing and limits are design constraints: API call allocations, storage, sandbox count, and feature licenses can invalidate an otherwise sound design.

Risk register entries should pair each risk with likelihood, impact, owner, and mitigation; unmitigated single points of failure are a common review finding.

Phased delivery reduces risk: prove the data model and security model first, then integration, then scale and optimize.

Assumptions must be documented and validated; a design that silently assumes data quality or volume will be challenged in review.

The review board presentation structure: business context, requirements and constraints, options considered, recommended design with diagrams, risks and mitigations, delivery plan, and open questions.

Diagrams must show system boundaries, data flows, trust boundaries, integration direction and protocol, and where identity is asserted and validated.

Tailor the message: executives need cost, risk, and timeline; engineers need data model, limits, and failure modes. The same design gets two narratives.

Anticipate board challenges: Why not standard functionality? What happens at 10x volume? How is PII protected? What is the rollback plan? Who owns operations?

Quantify claims: cite record volumes, API call counts, latency budgets, and storage estimates rather than qualitative assurances.

Document decisions as ADRs (context, decision, consequences) so future architects understand why a path was chosen.

Security reviews require data classification, access matrix by persona, encryption posture, and audit trail design.

A design that cannot be operated and monitored is incomplete; include alerting, runbooks, and ownership in the review.

The CTA (Certified Technical Architect) credential validates the ability to design, review, and defend multi-tenant solutions on the platform; the journey runs from prerequisites through instructor-led review, a proctored multiple-choice exam, and a scenario-based review board.

Core architect competencies: data model and security design, integration and API strategy, identity and access architecture, platform limits and scalability, lifecycle governance, and the ability to communicate trade-offs to both technical and executive audiences.

The exam rewards recognizing patterns and constraints over memorizing UI paths; questions typically present a business requirement plus constraints and ask for the best design or the most likely failure mode.

A solution design always starts from requirements: functional needs, non-functional needs (volume, latency, availability), constraints (licensing, budget, skills), and assumptions that must be validated with the customer.

The review board evaluates the design narrative: problem statement, options considered, why the chosen option wins, risks, mitigations, and a phased delivery plan. Designs without alternatives are usually challenged.

Declarative configuration is preferred over code where it satisfies the requirement; code (Apex, triggers, LWC) is justified when declarative tools cannot meet performance, complexity, or transactional requirements.

Every design decision carries a trade-off: customization increases fit but raises maintenance cost and upgrade risk; standardization lowers cost but may require process change.

Know the difference between a platform limit (hard, cannot be raised), an allocation (per-org entitlement that can be purchased), and a soft guideline (recommended practice).

Architect deliverables: solution design document, data model diagram, integration catalog, security model, non-functional requirements matrix, and a deployment/governance plan.

Standard objects (Account, Contact, Opportunity, Case, Lead, User) should be reused before creating custom objects; custom objects are justified when no standard object carries the semantics or lifecycle.

Relationship types: master-detail implies strong ownership, cascade delete, and roll-up summary support; lookup is loosely coupled and independent; many-to-many requires a junction object with two master-detail relationships.

Roll-up summary fields work only on master-detail relationships; for lookup-based aggregation use declarative roll-up or scheduled/async Apex aggregation.

External ID fields enable upsert, data loading matches, and integration correlation; every integration-facing object should carry a stable external identifier.

The 15-object limit on master-detail relationships per object and the 2 master-detail limit per child object constrain deep ownership hierarchies; plan junction and lookup alternatives early.

Record types plus page layout assignments control business process variation; avoid creating a new object per process variant when record types and picklists suffice.

Data skew (ownership skew, lookup skew) causes record lock contention and sharing performance problems; distribute ownership and avoid hot parent records in high-volume child inserts.

Data lifecycle: archive or delete obsolete records, define retention per object, and use the recycle bin and hard-delete tooling deliberately; large data volumes require indexing and selective queries.

Big objects store very large datasets with asynchronous access and no standard SOQL full-scan performance; use them for audit and historical archives, not for transactional UI needs.

Pattern selection: request-reply (synchronous) for real-time user-facing needs; fire-and-forget for non-critical events; batch for bulk; publish-subscribe for multi-consumer fan-out.

REST API suits resource-oriented, stateless, JSON interactions; SOAP is chosen when a WSDL contract, WS-Security, or strict typed operations are mandated by the partner.

Bulk API 2.0 is the tool for large data volumes (hundreds of thousands to millions of records); it is asynchronous, job-based, and governed by separate batch limits.

Composite API reduces round trips by bundling subrequests in one call; Composite Graph handles multiple unrelated records with references across them.

Platform Events and Change Data Capture support event-driven integration with replay IDs; Pub/Sub API provides gRPC/HTTP streaming access to those event streams.

Outbound messaging and callouts are subject to governor limits: cumulative callout time per transaction, callout size, and the 100-callout limit per transaction.

Idempotency is mandatory for inbound integrations: use external IDs plus upsert, or a dedupe key, so retries do not create duplicates.

Middleware (ESB/iPaaS) is justified when you need orchestration, protocol transformation, retry/queue semantics, or decoupling of many endpoints; point-to-point is acceptable for a few simple flows.

Error handling design: capture failures in a custom error object or platform event, define retry with backoff, and alert on dead-letter thresholds.

The sharing model is layered: organization-wide defaults (OWD) set the baseline, then role hierarchy, sharing rules, teams, manual sharing, and territory hierarchy widen access; Apex sharing recalculates only on explicit invocation.

OWD values: Private, Public Read Only, Public Read/Write, and (for some objects) Controlled by Parent; the most restrictive sensible OWD plus targeted sharing is the recommended posture.

Profiles define object/field permissions and are assigned one per user; permission sets and permission set groups grant additive access and are the preferred way to model job functions.

Record-level access is the union of OWD, role hierarchy (if granted), sharing rules, teams, territories, and manual shares; access cannot be subtracted below OWD except via restrictions such as scoping.

Field-level security governs visibility and editability; it does not prevent SOQL from reading a field in Apex, so code must enforce FLS explicitly with WITH SECURITY_ENFORCED or stripInaccessible.

Authentication options: SAML 2.0 SSO, OpenID Connect, social sign-on, and multi-factor authentication; MFA is required for internal users under the platform's security baseline.

Connected Apps and OAuth flows: authorization code with PKCE for user-context web/mobile, JWT bearer flow for server-to-server, client credentials for machine-to-machine without a user.

Named credentials and external credentials store endpoint and secret material outside code; remote site settings alone are legacy and do not carry authentication.

Shield Platform Encryption encrypts data at rest with customer-controlled keys but preserves case-insensitive search only for deterministic schemes; probabilistic encryption breaks filtering and sorting.

Guest user access is highly restricted: no standard object access by default, sharing via guest user record access settings, and secure Apex must run in system mode with explicit checks.

Multi-tenancy means all tenants share infrastructure; the platform enforces governor limits per transaction to protect the shared pool, so designs must be bulkified and asynchronous where volume demands it.

Execution contexts differ: system mode (Apex without sharing) ignores sharing rules; user mode (with sharing / inherited sharing) enforces them. Choose deliberately and document it.

Asynchronous options: @future (simple callouts), Queueable (chaining, job IDs), Batch Apex (large volumes, chunked), Schedulable (time-based), and Platform Events for decoupled flows.

The order of execution for a DML save matters: validation rules, before triggers, duplicate rules, after triggers, assignment rules, workflows, flows, escalation, roll-ups, and commit.

Lightning Web Components are the modern UI stack; Aura remains for legacy; Visualforce persists for PDFs, email templates, and specific legacy needs.

Declarative automation choice: record-triggered flows for most automation, approval processes for sign-off, and Apex when logic needs recursion control, complex transactions, or callouts in triggers.

Apex trigger frameworks (one trigger per object, handler classes, recursion guards) reduce risk of order-dependent bugs and repeated execution.

Custom metadata types are for configuration that deploys between environments; custom settings are for data-like configuration, and their caching behavior differs.

Namespace and package strategy: managed packages for IP protection and upgradeability; unlocked packages for internal modular delivery.

Selectivity drives query performance: a filter is selective when it returns well under the threshold (broadly <10% of rows, and indexed), so index candidate fields used in WHERE clauses and avoid negative filters like != or NOT IN.

Standard indexes exist on Id, Name, OwnerId, CreatedDate, SystemModstamp, lookup/master-detail foreign keys, and external IDs; custom indexes are requested through support and are limited.

Skinny tables (support-assisted) copy frequently filtered fields to improve large-volume query speed; they must be refreshed after schema changes.

Avoid leading wildcards in SOQL, avoid SELECT in loops, and never issue queries inside for-loops; use relationship queries and maps to reduce round trips.

Bulkify: process collections with single SOQL/DML calls; governor limits are per transaction, so batch size and chunking determine scalability.

Batch Apex default batch size is 200; tuning batch size trades heap and CPU against total number of batches and total elapsed time.

Record locking and UNABLE_TO_LOCK_ROW errors come from concurrent updates to the same parent or skewed data; mitigate with retry logic and data distribution.

Performance testing must use production-like data volumes; a design that passes in a small sandbox can fail at millions of rows due to non-selective queries and sharing recalculation.

Monitor with debug logs, the query plan tool, Apex CPU time limits, and event monitoring for slow pages and API usage.

Environment strategy: sandbox types differ in refresh interval and data copy - Developer, Developer Pro, Partial Copy (template-based sample data), and Full Copy.

Deployment tools: change sets (point-and-click, limited metadata coverage), Salesforce CLI with metadata API or source format, and unlocked/managed second-generation packages for CI/CD.

A DevOps pipeline should include version control, automated tests with required coverage, static analysis (such as PMD rules), a staging validation deployment, and a production deploy with a rollback plan.

Apex test requirements for production deployment: at least 75% overall coverage, all tests passing, and triggers requiring coverage of their own; coverage is a floor, not a quality measure.

Governance artifacts: naming conventions, a metadata ownership map, a release calendar, an integration registry, and an architecture review gate for significant changes.

Change management must consider downstream dependencies: integrations, reports, dashboards, flows, and permission sets referencing renamed or deleted metadata.

Technical debt should be logged and prioritized; hard-coded IDs, unused fields, and overly permissive profiles are common debt items.

Data seeding and masking: use templates for partial sandboxes and anonymize PII before refreshing non-production environments.

Non-functional requirements to elicit explicitly: volume (records, transactions per second), latency, availability, retention, audit, localization, and regulatory constraints.

Design options should be evaluated against weighted criteria (fit, cost, risk, time-to-value, maintainability); the recommendation must state why rejected options lost.

Build vs. buy vs. extend: standard functionality first, then declarative configuration, then custom code, then third-party AppExchange, then external system integration.

Trade-off patterns: synchronous improves UX but couples availability; asynchronous improves resilience but complicates error handling and user feedback.

Licensing and limits are design constraints: API call allocations, storage, sandbox count, and feature licenses can invalidate an otherwise sound design.

Risk register entries should pair each risk with likelihood, impact, owner, and mitigation; unmitigated single points of failure are a common review finding.

Phased delivery reduces risk: prove the data model and security model first, then integration, then scale and optimize.

Assumptions must be documented and validated; a design that silently assumes data quality or volume will be challenged in review.

The review board presentation structure: business context, requirements and constraints, options considered, recommended design with diagrams, risks and mitigations, delivery plan, and open questions.

Diagrams must show system boundaries, data flows, trust boundaries, integration direction and protocol, and where identity is asserted and validated.

Tailor the message: executives need cost, risk, and timeline; engineers need data model, limits, and failure modes. The same design gets two narratives.

Anticipate board challenges: Why not standard functionality? What happens at 10x volume? How is PII protected? What is the rollback plan? Who owns operations?

Quantify claims: cite record volumes, API call counts, latency budgets, and storage estimates rather than qualitative assurances.

Document decisions as ADRs (context, decision, consequences) so future architects understand why a path was chosen.

Security reviews require data classification, access matrix by persona, encryption posture, and audit trail design.

A design that cannot be operated and monitored is incomplete; include alerting, runbooks, and ownership in the review.