Question 1

What does a Salesforce Architect do, and how is it different from a Consultant or Developer?

Accepted Answer

A Salesforce Architect owns the technical and solution direction of the platform. While Consultants focus on business needs and Developers implement code, Architects make the structural decisions that determine whether the system scales, evolves, and survives. Day-to-day: - Architecture design : data model, security model, integration patterns, deployment strategy. - Technical decisions : build vs buy, code vs config, sync vs async, platform vs custom. - Reviews : code reviews, design reviews, security reviews. - Standards : framework patterns, naming conventions, governance. - Mentorship : developing the next generation of architects. - Stakeholder communication : translating technical realities to executives. Two flavours: - Solution Architect — owns the design at the project / cloud level. Handles cross-component interactions. - Technical Architect — deeper technical, usually enterprise-wide. Often a CTA (Certified Technical Architect). Architects span domains: Sharing & Visibility, Data Architecture, Integration, Identity, Development Lifecycle, Performance. The senior architect's value: making expensive-to-reverse decisions correctly the first time.

Question 2

What are the Salesforce CTA domains?

Accepted Answer

The Certified Technical Architect (CTA) is the pinnacle of Salesforce architecture certifications. The CTA review board evaluates across domains: 1. Communities/Mobile — Experience Cloud architecture, mobile design. 2. Data — data model, large data volume strategies, data lifecycle. 3. Development Lifecycle & Deployment — sandboxes, DX, CI/CD, release management. 4. Integration — APIs, middleware, integration patterns, event-driven architecture. 5. Identity & Access Management — authentication, SSO, OAuth, identity provider integration. 6. Sharing & Visibility — OWD, role hierarchy, sharing rules, Apex managed sharing. Each domain has its own architect-level certification (e.g., Data Architect , Integration Architect ) — passing all six is the path toward the Application Architect + System Architect combo, which combined with hands-on review boards yields the CTA. The CTA review: - Live board review: present a full multi-cloud architecture for a fictional client. - 3 hours of presentation + Q&A. - Pass rate is famously low ( 10-15% per attempt). Why it matters: CTA signifies the deepest expertise on the platform. Roles at $300K+ in major markets. Strategic advisor to CIOs. Path tak

Question 3

What's the difference between Solution Architect and Technical Architect?

Accepted Answer

Both are senior architecture roles but with different scope. Solution Architect (SA): - Project / programme level. - Designs the solution for a specific business problem. - Trade-offs between Salesforce features, customisation, packages, integration. - Cross-cloud (Sales + Service + Marketing + Industries). - Typically reports into a delivery team or leads one. Technical Architect (TA): - Enterprise / platform level. - Sets technical standards across all projects. - Reference architectures. - Code review at the framework level. - Typically reports to CIO / VP Engineering. - Often a Certified Technical Architect (CTA). Overlap: Both make architectural decisions, both engage with business. The split is more about scope: - One project, multiple components - Solution Architect. - Many projects, platform-wide consistency - Technical Architect. Typical career path: Senior Consultant - Solution Architect - Technical Architect - CTA. Title inflation note : many firms call senior consultants "architect" when the role is really senior consultant. The real test: do they own architecture decisions and have authority to enforce them? A good architect's value isn't in the title — it's in making

Question 4

What is a Reference Architecture and why do organizations use them?

Accepted Answer

A Reference Architecture is a pre-defined, validated architectural pattern that solves a common problem. Rather than re-architecting every project, teams reuse the reference. Examples: - Lead-to-Cash Reference Architecture — Marketing Cloud + Sales Cloud + CPQ + ERP. - Customer 360 Reference Architecture — Sales + Service + Experience Cloud + Data Cloud. - Field Service Reference Architecture — Service Cloud + Field Service + IoT + Mobile. - Multi-Org Federation — central org + spoke orgs + Mulesoft + SSO. Components of a reference architecture: - Diagram — visual showing systems, data flow, technologies. - Component descriptions — what each part does. - Trade-offs — why this design vs alternatives. - Variations — how to adapt for specific contexts. - Implementation guides — how to instantiate. Why use them: - Faster start — don't reinvent. - Proven patterns — already validated. - Consistent architecture across projects. - Risk reduction — known patterns have known failure modes. Salesforce publishes reference architectures via: - Architect.salesforce.com — public reference architectures. - Industry-specific — for verticals. - Customer 360 Truth documentation. - Trailhead modules f

Question 5

What is an Architecture Decision Record (ADR) and how do you use it?

Accepted Answer

An Architecture Decision Record (ADR) is a short document capturing a single architectural decision: what you decided, why, what alternatives you considered, what trade-offs you accepted. Format: Why ADRs matter: - Future you / future team — 18 months later, "why did we do it this way?" gets answered. - Onboarding — new architect catches up on history. - Scope discipline — writing the ADR forces clear thinking. - Conflict resolution — when the team disagrees, write the ADR; consider alternatives explicitly. Storage: Confluence, GitHub, internal wiki. Numbered sequentially. ADRs supersede each other rather than getting edited — preserves the historical reasoning. Senior architects make ADR-writing a habit. Without it, architecture drifts; reasons for past decisions get lost. With it, the architecture is auditable. Common pitfalls: - Writing them retroactively — captures the decision but not the live reasoning. - Never updating — Status: "Accepted" forever even when superseded. - Too long — ADRs are 1-2 pages, not 20. - Not searchable — buried in hard-to-find Confluence pages. The discipline pays off measurably over years.

Question 6

What is an Architecture Review Board (ARB) and how do you run one?

Accepted Answer

An Architecture Review Board (ARB) is a forum where significant architecture changes are reviewed by senior technical leadership before commitment. Purpose: - Quality gate — catches bad designs early. - Consistency — enforces standards across projects. - Knowledge sharing — junior architects learn from senior. - Risk identification — surface concerns. - Decision traceability — formal record of significant choices. Membership: - Chair — senior architect (often the CTA / lead architect). - Members — 3-6 senior technical roles spanning relevant domains. - Optional : security architect, data architect, infrastructure architect. Cadence: - Weekly / bi-weekly meetings, depending on volume. - 30-60 minutes per item. - Items submitted in advance (template + diagrams). What goes to ARB: - New custom objects above a threshold. - New integrations. - Data model changes affecting many objects. - Custom code beyond a certain scope (e.g., 500 lines). - New Salesforce clouds being adopted. - Major sandbox / DevOps changes. - Performance / scaling decisions. What does NOT go to ARB: - Routine config changes (validation rules, page layouts). - Tactical bug fixes. - Anything fitting an established re

Question 7

What are non-functional requirements and why do architects care more about them than functional ones?

Accepted Answer

Functional requirements = what the system does. "Users can submit cases via email." Functional reqs come from business analysis. Non-functional requirements (NFRs) = how well the system does it. Performance, security, scalability, availability, maintainability, etc. Categories: - Performance — page load times, transaction throughput, query response. - Scalability — handles N users, M records, growing over time. - Availability — uptime expectations, SLA tier. - Security — authentication strength, encryption, audit, compliance. - Reliability — failure rate, recoverability. - Maintainability — how easy is it to modify, debug, deploy. - Usability — how intuitive for users. - Compatibility — works with existing systems, browsers, devices. - Interoperability — integrates cleanly with other tools. - Compliance — meets regulatory requirements (GDPR, HIPAA, PCI). Why architects care: - Functional reqs are easy to write; NFRs are easy to forget. - Functional bugs are cheap to fix; NFR violations (poor performance, security gaps) are catastrophic. - Architectural decisions are mostly about NFRs — choosing patterns that satisfy them. - "It works" is functional; "it scales / is secure / is fast

Question 8

How is the Salesforce platform different from generic PaaS like Heroku or AWS?

Accepted Answer

Salesforce platform is opinionated PaaS for CRM and business apps. Heroku/AWS are general-purpose platforms. Salesforce platform features: - Pre-built data model (Account, Contact, Opportunity, Case, etc.). - Multi-tenancy with strict governor limits. - Declarative tools (Flow, validation rules, etc.). - Pre-built UI (Lightning Experience, page layouts, dashboards). - AppExchange ecosystem of pre-built solutions. - CRM-specific features (forecasting, case routing, marketing). - Built-in security model (sharing, FLS, profiles, OAuth). - Salesforce-managed infrastructure — you don't manage servers. Trade-offs vs generic PaaS: Salesforce wins for: - CRM-shaped problems (sales, service, marketing). - Business apps with rich UI (forms, lists, reports). - Multi-tenancy with shared schema. - Quick start (most things "just work"). Generic PaaS wins for: - Bespoke applications outside CRM. - Custom data models that don't fit Salesforce. - Heavy compute (image processing, ML inference). - Complete control (own database, own runtime, own libraries). - Lower per-user cost at very high scale. Hybrid pattern (common): - Salesforce for the CRM-shaped front-end + business workflows. - Heroku/AWS f

Question 9

How do you architect a Salesforce solution for scale?

Accepted Answer

Scale comes in dimensions: data volume, user volume, transaction volume, integration volume. Data volume: - Set OWD with performance in mind. Private OWD on millions of records = expensive sharing recalc. - Use Custom Indexes on filter-heavy fields (request via Salesforce Support). - Use Skinny Tables for hot read paths (request via Salesforce). - Avoid Roll-Up Summary on millions of children — use scheduled aggregation instead. - Plan archive strategy — move old data to Big Objects or external warehouses. User volume: - License optimisation (right-size licenses per user). - Permission set groups for bulk assignment. - Performance test with concurrent users; identify bottlenecks. - Lightning page performance — components add up. Transaction volume: - Bulkify triggers, flows. - Async for heavy work; reserve sync for user-facing. - Batch Apex for nightly / scheduled large-data work. - Platform Cache for hot reads. - Selective queries — every SOQL must hit indexes. Integration volume: - Bulk API 2.0 for large inbound data. - Pub/Sub API + CDC for outbound real-time. - Mulesoft / iPaaS for orchestration. - Change Data Capture for replication to data warehouse. - API Limit monitoring —

Question 10

How do you manage technical debt in a Salesforce org?

Accepted Answer

Technical debt = the cost of past shortcuts. In Salesforce: schema sprawl, deprecated automation tools, complex flows, custom code that should have been declarative, untested code, stale fields, unused customisations. Identify: - Custom field count per object — when nearing 500/800 limit. - Active flow count per object — when many overlap. - Apex test coverage — below 75% blocks deploys. - PMD / static analysis findings — identifies anti-patterns. - Salesforce Optimizer — built-in debt analyzer. - Field utilisation — fields rarely populated. - Code duplication — copy-pasted logic. - Process Builder still active — end-of-life tool. - Manual deployments — vs DX-driven. Quantify: - Maintenance hours spent on debt (vs feature work). - Incidents traced to debt-related root causes. - Time-to-deploy trending. Communicate: - "We can't ship X next quarter because we need to address Y" — tie debt to business outcomes. - Show stakeholders concrete examples of debt's cost. Address: - Tech debt sprints — dedicated capacity (10-20% of team time). - Quarterly cleanup — concentrated effort. - As-you-go — every new feature includes cleanup of related debt. - Major modernisation — periodic large inv

Question 11

How do you do a Technical Discovery (vs business Discovery)?

Accepted Answer

Technical Discovery happens after Business Discovery — translating business requirements into technical architecture. Inputs: - Business Discovery outputs (SDD, requirements, process maps). - Existing technical landscape — Salesforce orgs, systems, integrations. - Constraints — regulatory, infrastructure, team capabilities. Activities: 1. Inventory current technical state: - Salesforce org(s) — editions, licenses, customisations. - Existing custom code — Apex, LWC, Visualforce. - Integration map — external systems, current flows. - Data volume — current and projected. - Tech stack — DevOps tools, version control, CI/CD. - Team skills — admins, developers, architects. 2. Identify technical risks and gaps: - Where do existing patterns break down? - What's the path from current to future state? - Where do we lack expertise? - What dependencies exist on external teams / vendors? 3. Architecture decisions: For each major component: - Buy / build / native? - Sync / async? - Code / config? - Standard / custom? Document each as ADRs. 4. NFR validation: - Performance targets achievable? - Scale projection plausible? - Security requirements satisfied? - Compliance achievable? 5. Integration

Question 12

How do you architect for resilience and graceful degradation?

Accepted Answer

Resilience = the system continues to work (or degrades gracefully) when components fail. Failure modes to design for: - External system down (ERP, payment gateway, third-party API). - Salesforce platform issue (rare but happens). - Network failure between systems. - Slow response (timeout) from dependency. - Database constraint failure (validation, sharing recalc). - Governor limit breach. - Data quality issue propagating. Patterns: 1. Timeout + retry. Every callout has a timeout. Failed calls retry with exponential backoff. 2. Circuit breaker. Track failure rate of external service. After N failures, "open the circuit" — stop calling for a cooldown period. Resume gradually. 3. Fallback paths. When primary service fails, have a fallback: - Display cached data instead of live. - Submit to a queue for later processing. - Show partial UI without the failing component. - Use AI's "best guess" when ML service down. 4. Async over sync. Synchronous calls block the user; async calls queue. Outage causes a backlog instead of user-facing failures. 5. Bulkhead pattern. Isolate failure domains. One slow integration doesn't block the entire org. 6. Monitoring and alerting. Detect failures fast.

Question 13

How do you architect for multi-region (global) Salesforce deployments?

Accepted Answer

Global Salesforce: users in NA, EMEA, APAC. Architecture decisions multiply. Single org vs multi-org: - Single global org — one Salesforce instance for everyone. Simpler, unified data, easier reporting. Constraint: all data lives in one Salesforce data center; data residency may require multi-org. - Multi-org — separate instance per region. Required for data residency (EU data in EU region, etc.); independent scaling per region. Cost: integration, governance, talent. Decision drivers: regulatory data residency, performance/latency, business unit autonomy, M&A history . For single org: - Multi-currency must be enabled (irreversible decision). - Multi-language — Translation Workbench, locale-aware formats. - Time zones — every user has TZ; Business Hours per region. - Sharing model — region-based sharing rules; users see only their region's data. - Region-specific record types for different processes. - Page layouts / Lightning Record Pages per region. For multi-org: - SSO federates user identity across orgs. - Salesforce-to-Salesforce or Mulesoft for cross-org data sync. - Shared customer data — Data Cloud or master data system. - Multi-org reporting — replicate to data warehouse fo

Question 14

How do you make a build-vs-buy decision at architect level?

Accepted Answer

Architect-level build-vs-buy is the recurring question for any non-trivial capability. Three options: 1. Salesforce native — out-of-box features. 2. AppExchange — third-party packaged apps. 3. Custom build — your team creates. Default order: native AppExchange custom. When to buy (AppExchange): - Common problem — many companies have it; vendors solve it. - Solid vendor — established, financially stable, good reviews, security-reviewed. - Customisability — package allows what you'll need. - Cost over time — total cost of ownership beats build. When to build: - Specific business logic — generic solutions don't fit. - Tight integration with custom data model. - Compliance / security requires code your team controls. - Performance critical — packages can't deliver. - Customisation depth needed — beyond what packages support. Hidden costs of buying: - Licensing — recurring; can grow with usage. - Lock-in — switching costs after adoption. - Customisation limits — vendor's roadmap, not yours. - Upgrade pain — vendor's release cadence. - Knowledge concentration — fewer people understand the package. Hidden costs of building: - Maintenance — ongoing forever. - Salesforce platform updates —

Question 15

How do you architect data flow across multiple systems?

Accepted Answer

Multi-system data flow design = which system owns what, how data syncs, what's the latency tolerance. Step 1: Map data domains. For each major entity (Account, Customer, Product, Order, Invoice): - Source of truth — which system owns the canonical version? - Consumers — which systems read it? - Update paths — which systems can change it? Step 2: Define sync patterns per flow. - Real-time sync — sub-second latency. Use Pub/Sub API, CDC, Platform Events. - Near-real-time — minutes. Mulesoft / iPaaS event-driven. - Batch sync — hourly / daily. Bulk API, ETL. - On-demand — pull when needed. External objects via Salesforce Connect. - Event-driven — fire on state change. Platform Events + subscribers. Pick based on: latency requirement, volume, reliability needs. Step 3: Conflict resolution. When multiple systems can update the same field: - Source-of-truth wins — non-source updates are rejected or queued for SOR. - Last write wins — simple but loses data. - Merge logic — application-specific resolution. - Avoidance — design so only one system writes per field. Step 4: Idempotency. Every receiving system must handle duplicate events. Use idempotency keys (External Id) to prevent double-p

Question 16

How do you handle architectural disagreement with stakeholders or other architects?

Accepted Answer

Disagreement is normal in architecture work. Resolution determines outcome quality. Common sources: - Stakeholder vs architect — business want X; you think X causes Y problem. - Architect vs architect — different opinions on technical approach. - Senior vs junior — politics + expertise mismatch. - Vendor vs internal — vendor pushes their solution; internal architect prefers different. Resolution patterns: 1. Surface the disagreement explicitly. Don't paper over. Name the disagreement; describe each position. 2. Identify the underlying interests. People disagree because they value different things. Find the underlying concerns: - Risk aversion? - Performance vs cost trade-off? - Familiarity with one tool? - Past bad experience? - Schedule pressure? Once interests are clear, sometimes a third option satisfies both. 3. Document each option with trade-offs. Write up: Option A (your preference), Option B (their preference), Option C (compromise). Pros/cons of each. 4. Bring data. Performance projections, cost estimates, risk analysis. Move from opinion to evidence. 5. Bring outside perspective. Reference architectures, similar past projects, industry patterns. Sometimes "company X did Z

Question 17

From an architect perspective, when do you choose Apex vs Flow vs declarative tools?

Accepted Answer

The decision pivots on multiple factors at architect level. Always declarative when possible: - Validation rules. - Field updates. - Simple workflows. - Standard reports / dashboards. - Page layouts / Dynamic Forms. - Out-of-box features. Flow when: - Multi-step orchestration. - User-facing screens (Screen Flows). - Conditional logic admins maintain. - Cross-object writes. - Scheduled tasks (Scheduled Flows). - Most automation in modern Salesforce. Apex when: - Performance critical — flows hit governor limits faster. - Bulk operations beyond Flow's reach — millions of records. - Complex error handling — try/catch, partial-success, custom exceptions. - Recursion-aware logic — cleaner in Apex with static guards. - Apex Managed Sharing — flows can't write to tables. - Custom REST/SOAP endpoints . - Complex callouts with retries, transformations . - LWC backing — Apex. Hybrid (often best): - Flow at the orchestration layer — admins maintain. - Apex Invocable Methods for heavy lifting. - Mix gives admin agility without Apex complexity for everything. Architect-level considerations: Maintenance cost: - Flow: admins can maintain, but complex flows are still hard. - Apex: developers requir

Question 18

How do you balance new feature development with platform health?

Accepted Answer

"Platform health" = the platform's capacity to support features long-term. Performance, security, maintainability, governance. The tension: - New features deliver visible value — fast wins for stakeholders. - Platform health is invisible until it breaks — declining slowly until catastrophe. Without deliberate balance, new features dominate, platform decays. Balance mechanisms: 1. Capacity allocation. Reserve a percentage of team capacity for platform health: - 70% new features. - 20% platform health (tech debt, refactoring, modernisation). - 10% innovation (exploration, learning). The exact ratio depends on org maturity. New orgs: more new features. Mature orgs with debt: more platform. 2. Define "platform health" metrics. - Apex test coverage. - PMD finding count. - Custom field count per object. - Active flow / trigger count. - Sandbox refresh time. - Production incident rate. - Time-to-deploy. - User complaints about performance. Track over time. Trend up or down indicates health direction. 3. Health targets. - Apex test coverage = 85%. - Production incidents per month <= 2. - Time-to-deploy <= 2 hours. - Custom field count per object <= 300. When metrics drift below target, man

Question 19

Walk me through architecting an enterprise multi-org Salesforce program.

Accepted Answer

Multi-org enterprise: 5+ Salesforce orgs across business units / regions / acquisitions. Drivers : - M&A — newly acquired companies on their own Salesforce. - Regulatory — financial services divisions can't share data. - Data residency — EU data in EU, US data in US. - Independent business units — autonomous IT. Architectural approach: 1. Define the org topology. Common patterns: - Hub-and-spoke — central org holds master data; spokes have BU-specific data. - Federation — peer orgs sync via integration; no central authority. - Domain-based — orgs split by data domain (CRM, Service, Marketing). 2. Identity strategy. - SSO via single IdP (Okta, Azure AD, Ping) — users log in once; access multiple orgs based on permissions. - Just-in-time provisioning — create user in target org on first SSO login. - Identity Connect for AD synchronisation. 3. Cross-org data architecture. - Master Data Management (MDM) — single canonical record per customer / product / employee. - Salesforce can be MDM, or external MDM tool (Informatica, Reltio, Stibo). - Replication — Customer record in hub propagates to all spokes. - Federation — query across orgs in real time (Salesforce Connect / external objects)

Question 20

How do you architect a sub-second latency integration between Salesforce and an external system?

Accepted Answer

Sub-second latency means user-facing speed for cross-system operations. Inbound (external - Salesforce): - Apex REST endpoint with optimised processing. - Webhooks with immediate ACK and async processing of heavy work. - Pub/Sub API subscriber on the external side. Outbound (Salesforce - external): - Apex callout from a record-triggered flow (after-save) — synchronous but governor-limited. - Platform Events — event published; external subscribes via Pub/Sub API. Sub-second to subscriber but eventually consistent. - Streaming API for immediate notification . Architectural patterns: 1. Cache the external data in Salesforce. If sub-second display matters but external is too slow: - Periodic sync external - Salesforce. - Display Salesforce-cached version to user. - Refresh in background. 2. Pre-fetch. When user is likely to need external data, fetch in advance during navigation. By the time they need it, it's ready. 3. Concurrent / parallel calls. If user triggers needing 3 external calls, fire all 3 in parallel. Total latency = max of the three, not sum. Tools: Visualforce Continuation (limited), or LWC-side calls to multiple Apex methods simultaneously. 4. Skinny payload. Minimise da

Question 21

How do you architect Salesforce for billions of records?

Accepted Answer

Billions of records is firmly in the territory of Big Objects, archive strategies, and data tiering. Reality check: - Standard Custom Objects: practical limit hundreds of millions. - Big Objects : designed for billions. Index-driven access only. - External warehouses (Snowflake / BigQuery) : for analytics on billions. - Salesforce Connect / External Objects : read-only views from external storage. Strategy: 1. Data tiering. - Hot tier — recent/active records in standard objects. Indexed, queryable normally. - Warm tier — older but still occasionally accessed in Big Objects. - Cold tier — historical/archived in external warehouse. Migration between tiers via scheduled jobs (Batch Apex moving from standard to Big Object; Data Pipeline moving Big Object to external). 2. Read-path optimisation. For hot tier: - Custom Indexes on filter-heavy fields. - Selective queries mandatory. - Skinny Tables for frequently-accessed standard objects. For Big Objects: - Async SOQL for analytical queries. - Index-based queries only — no ad-hoc. For external: - External objects via Salesforce Connect for visibility. - Direct queries against the warehouse from BI tools. 3. Write-path. - Bulk API 2.0 for

Question 22

How do you architect Agentforce / Einstein AI for production use?

Accepted Answer

Agentforce / Einstein in production = AI agents reasoning, calling tools, interacting with Salesforce data, all reliably and at cost. Architecture components: 1. Atlas Reasoning Engine — Salesforce's LLM platform. Available models, prompt structure, response parsing. 2. Einstein Trust Layer — sits between your prompts and the LLM: - PII masking — replaces sensitive data in prompts; un-masks responses. - Audit logging — every prompt and response logged. - Toxicity filtering — blocks inappropriate content. - Bias detection — flags problematic patterns. - Mandatory; not bypassed. 3. Prompt Builder — reusable prompt templates with merge fields. 4. Apex integration — Apex calls AI via or similar. 5. Custom tools / actions — Apex methods registered as agent tools. Agents call them to perform work. 6. Data Cloud — unified data feeding AI for grounding (RAG). Production architecture decisions: 1. Cost management. LLM calls cost. Per-call cost adds up at volume. - Track per-feature usage . - Set per-user quotas if needed. - Cache when appropriate — repeat queries don't need re-inference. - Use lower-cost models when possible (smaller models for simpler tasks). 2. Async invocation. LLM calls

Question 23

Walk me through a CTA-style multi-domain Salesforce solution architecture.

Accepted Answer

A CTA review board scenario: design a complete architecture for a fictional client across all six domains. Sample scenario (typical CTA-style): Global financial services firm. 50,000 internal users in NA, EMEA, APAC. 5M customers. Regulatory: GDPR (EU), SOX, FINRA, MAS. Multi-product (banking, wealth management, insurance). Existing: legacy CRM (Siebel), separate marketing tool (Salesforce Marketing Cloud already), ERP (SAP), compliance system. Goal: unified Salesforce-centred customer experience over 24 months. Architecture across six domains: 1. Sharing & Visibility: - Multi-org : separate Salesforce orgs for NA, EMEA, APAC due to data residency. - OWD : Account Public Read internally; Private for sensitive (HR, deal teams). External: Private. - Role hierarchy mirroring org structure. - Apex Managed Sharing for compliance-driven access (advisor sees only their book). - Communities/Experience Cloud for advisors and customers; Sharing Sets for HVPU. - Audit : Field Audit Trail (Shield) for 7-year regulatory retention. 2. Data Architecture: - Financial Services Cloud for vertical data model (Householding, Financial Account, Insurance Policy). - Custom objects for unique products. -

Question 24

How do you architect graceful degradation when external systems fail?

Accepted Answer

Graceful degradation = system continues to provide value even when dependencies fail. Failure modes: - External API down. - External API slow (timing out). - Network partition. - Salesforce platform incident. - Database constraint failure. Patterns for graceful degradation: 1. Cached fallback. When external is down, serve last-known-good data with staleness disclaimer. 2. Skip optional features. Critical workflow: must work even if optional services down. - Account record must load even if external "credit check" service is down. - Show the record without the credit info; surface message "credit check unavailable". 3. Async backfill. When primary path fails, queue for retry. Retry until success or max attempts. 4. Circuit breaker. After N consecutive failures, stop calling external service for a cooldown period. Avoids piling up calls during known outage. 5. Timeout discipline. Every callout has reasonable timeout. Better to fail fast than block users for minutes. 6. Partial responses. Composite calls fetching from N services: return what succeeded; flag what didn't. 7. Health check + UI banner. If external system unhealthy, show banner: "Some features temporarily unavailable." 8.

Question 25

How do you architect a Salesforce solution that survives Salesforce platform changes?

Accepted Answer

Salesforce releases 3 times per year. Major changes happen: features deprecated (Process Builder, Workflow Rules, Aura), new tools introduced (Flow, LWC, DevOps Center), AI capabilities evolve. Solutions that don't accommodate change become brittle. Principles: 1. Don't depend on what's deprecated. - New code: never Process Builder or Workflow Rules. - New UI: never Aura when LWC fits. - New integrations: prefer Pub/Sub API over CometD. - New deployment: DX over Change Sets. Read release notes; track deprecation timelines. 2. Use abstractions. - Custom Metadata Types for config — easier to adapt. - Interfaces in Apex for swappable implementations. - Feature flags to gradually roll out / roll back features. 3. Prefer declarative when possible. Salesforce evolves declarative tools faster than code. Code you wrote for X feature may need updating; declarative often updates automatically. 4. Avoid private APIs. Salesforce has documented APIs (stable) and undocumented internals (volatile). Build on documented; never on undocumented. 5. Test extensively before production. - Apex test coverage 75%+. - LWC Jest coverage. - Integration tests catching regressions. - Tests fail when platform c

Question 26

What's a recommended trigger framework pattern at architect level?

Accepted Answer

One trigger per object delegating to a handler class. The framework: Components: - TriggerHandler base class — orchestrates context dispatch (beforeInsert, afterUpdate, etc.). - Concrete handlers per object — extend base, override relevant methods. - TriggerHandlerFactory — maps sObject to handler class via Custom Metadata. - Static recursion guard — prevents re-entry. - Handler enable/disable via Custom Metadata for emergency disable. Why it matters: - One trigger per object — avoids "multiple triggers on same object firing in undefined order". - Logic in classes — testable, reusable, refactorable. - Recursion control — explicit. - Disable mechanism — turn off automation in production without redeploying. Open-source options : FFLib's , Kevin O'Hara's TriggerHandler, custom-built. Pick one; standardise across the org. Architect role: enforce one framework org-wide. Mixed frameworks = chaos.

Question 27

What are common LWC architecture patterns?

Accepted Answer

1. Container-Presenter pattern. Container component owns state and Apex calls; presentation components are stateless and receive data via . 2. Lightning Message Service (LMS). Cross-tree communication via Message Channels. Decouples siblings. 3. Custom Events for parent-child. Children dispatch CustomEvent; parents handle. Standard pattern. 4. Composition over inheritance. LWC doesn't support inheritance; use composition. Mixins via JS modules. 5. Lightning Data Service (LDS). Use / for single-record CRUD without writing Apex. Cached, FLS-aware. 6. reactive data. Reactive data binding. Records refresh automatically when underlying data changes. 7. Imperative Apex for actions. User actions call Apex imperatively; results update component state. 8. Custom Property API. properties as the public interface; private properties not exposed. 9. Lazy loading. Heavy components load on demand ( gates rendering). 10. Component reuse via slots. lets parent inject content into child layout. Architect role : define standards for component organisation, naming, public interfaces, testing, and styling. Without standards, LWC codebases drift.

Question 28

How do you use Custom Metadata Types as an architecture pattern?

Accepted Answer

Custom Metadata Types (CMDTs) are a powerful architectural primitive — config + metadata + cache, all in one. Patterns: 1. Feature flags. - with boolean. - Apex / Flow checks . 2. Integration endpoints. - with endpoint URL, timeout, etc. - Apex callouts read from CMDT, not hardcoded. 3. Business rules. - with criteria + threshold. - Apex / Flow walks CMDT records to find matching rule. 4. Mappings. - for code-to-record-type translations. - Integrations look up via CMDT. 5. Trigger handler routing. - mapping sObject - handler class. - Trigger framework reads CMDT to dispatch. 6. Validation rule complexity. - Validation rules can reference CMDT via . Threshold values defined in CMDT, not hardcoded. 7. Per-environment config. - CMDT records can vary across orgs; deploy specific values per env. Why CMDT works for these: - Deployable — values move with code. - Cached — no SOQL governor cost. - Type-safe — fields have types, validated at deploy. - Queryable from formula and validation rules . - Packageable — managed packages can ship CMDT. Anti-pattern: Custom Settings for what should be CMDT. Custom Settings data doesn't deploy; CMDT does. Architect insight: CMDT-driven architecture let

Question 29

What's an architect-level Apex code review checklist?

Accepted Answer

Code review at architect level looks beyond syntax. Key checks: Bulkification: - No SOQL or DML in loops. - Methods accept Lists, not single records. - Maps for O(1) lookups; not List.contains. Governor limits: - Selective queries. - Stay well under SOQL/DML/CPU/heap thresholds. - Async for heavy work. Test coverage: - 75% minimum (production gate). - 85%+ targeted; meaningful tests. - @TestSetup data factories. - Negative test cases. - Bulk tests (200 records). - for permission paths. - Mocks for external dependencies. Sharing: - Explicit / / . - Default class declaration explicit, not implicit. Error handling: - try/catch where appropriate. - Custom exceptions for business errors. - Errors logged to custom log object. - Meaningful error messages. Security: - SOQL injection protection (bind variables). - FLS / CRUD checks via or explicit. - No hardcoded user IDs. - No hardcoded passwords / API keys. Performance: - No N+1 query patterns. - Cache reused queries. - Async for slow ops. - Wired Apex methods marked where possible. Maintainability: - One responsibility per class. - Clear naming. - Limited side effects. - Comments for non-obvious decisions. Style: - Follows project conven

Question 30

What's a comprehensive testing strategy at architect level?

Accepted Answer

Testing isn't just Apex tests. A comprehensive strategy: 1. Unit tests (Apex): - Per class, per method. - 75% coverage minimum, 85%+ target. - Bulk tests (200 records). - Mock dependencies. - Negative cases (validation, permissions). 2. LWC unit tests (Jest): - Per component. - Test public API, not implementation. - Mock Apex methods, LDS, LMS. - Async resolution patterns. 3. Integration tests: - End-to-end across systems. - Test data prep + teardown. - Mock external services in test env. 4. UI tests (Cypress / Playwright): - User journeys. - Visual regression where useful. - Run against UAT sandbox. 5. Performance tests: - Load test under expected concurrent users. - Page render times under data volume. - Bulk operation timing. 6. Security tests: - Penetration testing. - OWASP checks. - Permission audits. 7. UAT: - Business user testing. - Real scenarios. - Sign-off gate. 8. Production monitoring: - Synthetic transactions periodically. - Error rate monitoring. - Real-user monitoring. Test tooling stack: - Apex unit tests (built-in). - Jest for LWC. - PMD / ESLint for static analysis. - Cypress / Playwright for UI. - Provar / Tosca for end-to-end (some orgs). - Custom test data fac

Question 31

How do you architect CI/CD for a Salesforce project?

Accepted Answer

Goal : code goes from PR - sandbox - production with quality gates and minimal manual work. Components: 1. Source control. - Git repository (GitHub / GitLab / Bitbucket). - Branch strategy: feature branches off ; to for production. 2. Salesforce DX. - Source format metadata. - defines structure. - Scratch orgs for feature dev. 3. CI/CD platform. - GitHub Actions, GitLab CI, Bitbucket Pipelines, Jenkins, CircleCI. - Or Salesforce DevOps Center for in-platform. 4. Pipeline stages: On PR open: - Create scratch org. - Deploy source to scratch. - Run all Apex tests with coverage. - Run PMD / ESLint. - Run Jest tests. - Validate metadata. - Comment on PR with results. - Delete scratch org. On merge to develop: - Validate-only deploy to UAT sandbox. - If clean, deploy. - Run smoke tests. - Notify team. On merge to main: - Validate-only deploy to production. - Manual approval gate. - Deploy to production. - Run smoke tests. - Notify team. 5. Quality gates: - 75% Apex coverage. - PMD findings under threshold. - ESLint clean. - All tests pass. - Security review passed (for sensitive changes). 6. Secrets management. - Per-org auth tokens stored as CI secrets. - JWT-based auth for headless CI.

Question 32

How do you architect logging and monitoring for a Salesforce org?

Accepted Answer

Salesforce has built-in observability that's adequate for small orgs and inadequate for enterprise. Built-in: - Debug Logs — Apex execution detail. Limited retention; user-specific. - Login History — every login. 6-month retention. - Setup Audit Trail — metadata changes. 6 months. - Field History Tracking — record changes. 18-24 months. - Apex Exception Email — failures emailed to admin. Beyond built-in: 1. Custom error log object. capturing every uncaught exception, async failure, integration error. Persistent. Reportable. 2. Event Monitoring (Shield). - Detailed runtime events: API calls, logins, report exports, file downloads, slow queries. - Hourly file delivery. - Stream to S3 / SIEM. 3. External SIEM integration. - Splunk / Datadog / Sumo Logic. - Centralised observability across systems. - Alerting on anomalies. 4. Application-level metrics. - Custom counters via Custom Metadata or platform events. - Track user journeys, feature usage, performance. 5. Integration health dashboards. - Per integration: success rate, latency, error rate. - Alert on threshold crossing. 6. Synthetic monitoring. - Periodic test transactions exercising critical paths. - Catch outages before users n

Question 33

How do you architect caching in Salesforce?

Accepted Answer

Caching reduces redundant work — query, callout, computation. Cache types: 1. Apex Platform Cache. - Org Cache — shared across users; for org-wide data. - Session Cache — per-user; for user-specific. - API: , . - TTL configurable. - Capacity tied to license. - Up to 100 KB per value. 2. Custom Metadata Type cache. - CMDT auto-cached. is essentially free. - Best for static-ish config. 3. Lightning Data Service cache. - LWC results cached client-side. - Shared across components on same page. 4. Record cache via SOQL. - Apex transaction-level cache: same SOQL within transaction returns same data. - Useful for utility methods called repeatedly. 5. CDN / Static Resources. - Static assets cached at browser / CDN. 6. External cache (Redis / Memcache). - Via Heroku / external infra. - For high-volume, complex caching beyond Salesforce limits. Architectural questions: - What to cache? Frequently-read, rarely-changed data. Country lists. Tax rates. Permission profiles. - Where to cache? Org Cache for shared data. Session for user-specific. CMDT for static. - How long? TTL based on staleness tolerance. 1 hour for moderately-changing; 24 hours for stable. - Eviction policy? TTL or LRU. - Cache

Question 34

How do you architect event-driven systems on Salesforce?

Accepted Answer

Event-driven architecture (EDA) : components communicate via events rather than direct calls. Salesforce supports this natively. Salesforce EDA primitives: - Platform Events — custom event types ( suffix). - Change Data Capture (CDC) — auto-events on record changes. - Pub/Sub API — modern subscriber protocol. - Streaming API / CometD — older subscriber protocol. EDA patterns: 1. System decoupling. System A publishes event. System B (and C, D) subscribes. A doesn't know who's listening; B doesn't know A is sending. 2. Async workflows. User triggers action - event published - async subscribers process - results published as new event - next system reacts. 3. Replay / catch-up. Subscribers persist state of "last processed event". Catch up after downtime. 4. Event sourcing (lite). Sequence of events represents state. Replay events to reconstruct. 5. Saga pattern. Distributed transaction across systems via events. Each system reacts to events; compensating actions on failure. Use cases: - Order fulfilment chain — Order Created - Inventory Allocated - Shipping Scheduled - Customer Notified. - Customer 360 sync — Account Updated event - downstream systems sync. - Audit logging — every bus

Question 35

When does Mulesoft beat custom integration code?

Accepted Answer

Mulesoft Anypoint Platform is Salesforce's integration platform. Used between Salesforce and other systems for orchestration, transformation, error handling. When Mulesoft wins: - Multiple systems to orchestrate (Salesforce + ERP + warehouse + CRM + commerce). - Reusable integrations — same flow used by many systems. - Complex transformations — DataWeave makes mapping declarative. - API management — Anypoint API Manager for external API publishing, throttling, versioning. - Reliability needs — built-in retry, dead-letter queues, monitoring. - Centralised governance — single place to see/manage integrations. - Enterprise scale — designed for high-volume, mission-critical. - Already use Mulesoft — leverage existing investment. When custom wins: - Single integration — Mulesoft overhead not justified. - Simple Salesforce REST callout — straightforward Apex. - No Mulesoft expertise in the team. - Tight Salesforce-specific logic — staying in Apex is easier. - Cost — Mulesoft licensing is significant. - Speed for simple cases — custom may ship faster. Hybrid pattern: Many orgs use Mulesoft for system-to-system orchestration AND custom Apex for Salesforce-specific business logic. Each play

Question 36

What's a systematic approach to performance tuning a slow Salesforce org?

Accepted Answer

Performance tuning starts with measurement, not assumptions. Step 1: Measure. - Lightning Performance Analysis in Salesforce. - Browser DevTools for client-side render time. - Debug logs with FINEST level for transaction analysis. - Event Monitoring for slow query and slow Apex. - User-reported pain points — qualitative. Identify what's actually slow. Don't optimise based on hunches. Step 2: Diagnose. For each slow path: - SOQL queries — non-selective, missing indexes, too many. - DML — large bulk inserts, validation rules firing on every record. - Triggers and flows — unbulkified, recursion. - Lightning page composition — too many components, heavy LWCs. - Network — slow callouts, unfiled latency. - Sharing recalc — pending sharing operations. Step 3: Prioritise. - High user impact + high frequency — fix first. - Quick wins — significant improvement with low effort. - Long tail — many small inefficiencies; address as opportunity. Step 4: Optimise. For each hotspot: SOQL: - Index hits via WHERE on indexed fields. - Custom Indexes via Salesforce Support. - Selective queries (avoid full table scans). - Skinny Tables for hot reads. Triggers / Flow: - Bulkify. - Move sync work to async

Question 37

How do you architect security across all layers in Salesforce?

Accepted Answer

Security is layered. Each layer addresses different threats. Layer 1: Identity (Authentication). - MFA mandatory for all users. - SSO via Okta / Azure AD / Ping for enterprise. - My Domain required for SSO and Lightning. - Connected Apps for OAuth integrations; minimum scopes. - Session settings strict (15-min timeout, IP restrictions, secure cookies). - Login Flows for additional verification on high-risk logins. Layer 2: Authorisation (What you can do). - Profiles minimal; baseline only. - Permission Set Groups model job functions. - Muting Permission Sets to narrow within groups. - Object permissions least-privilege. - System permissions audited (View All Data, Modify All Data). Layer 3: Record-level access (Sharing). - OWD per object based on data sensitivity. - Role hierarchy mirroring org chart. - Sharing rules for cross-team access. - Apex Managed Sharing for complex logic. - External user sharing (Sharing Sets, Share Groups for HVPU). Layer 4: Field-level access (FLS). - FLS enforced via Profile / Permission Set. - Encrypted fields (Shield Platform Encryption) for Restricted / Mission Critical. - Field Audit Trail (Shield) for sensitive field history. Layer 5: Data protecti

Question 38

How do you architect encryption (Shield, masking, in-transit) in Salesforce?

Accepted Answer

Encryption types: 1. Encryption in transit. - TLS / HTTPS automatically applied to all Salesforce traffic. - Mutual TLS for advanced authentication. - VPN / private connections for highly secure integrations. This is automatic; you don't configure but should know. 2. Encryption at rest — Salesforce-managed (default). - All data on Salesforce servers encrypted at rest. - Salesforce manages the keys. - No additional cost. - Adequate for most data. 3. Shield Platform Encryption (Salesforce-purchased). - Tenant-managed keys — your org has its own encryption keys. - Field-level encryption — encrypt selected fields (Account.Phone, Contact.Email, custom fields). - File encryption — encrypt files. - Bring Your Own Key (BYOK) — derive keys outside Salesforce, import. - Cache-only Key Service — keys never stored. Trade-offs: - Encrypted fields can break some declarative features (formulas referencing them, certain SOQL filters). - Encryption keys can be revoked, rendering data unreadable. - Performance impact (typically minimal). 4. Field-Level Security (FLS). Not strictly encryption but controls who can see fields. FLS is layered with encryption — encrypted but visible vs encrypted and hidd

Question 39

When do you use Heroku Connect vs Salesforce Connect?

Accepted Answer

Both bring external data into Salesforce, but with different approaches. Salesforce Connect: - Exposes external data as External Objects ( suffix). - Read-only by default; some write support with extra config. - Each query goes to the external system in real time (or with light caching). - Best for: occasional access, current data needed, large external datasets you don't want to copy. - OData adapter, REST adapter, or custom adapter. Heroku Connect: - Bidirectional sync between Salesforce and a Heroku Postgres database. - Data is copied (not virtual). - Sync runs continuously; Postgres is kept current. - Best for: high-volume data needs, Heroku-based apps that read/write Salesforce data, custom analytics on Postgres. Architectural comparison: | | Salesforce Connect | Heroku Connect | |---|---|---| | Direction | Mostly read | Bidirectional | | Data location | External | Postgres copy | | Latency | Real-time | Sync interval | | Read performance | External-system-bound | Fast (local Postgres) | | Volume | Limited per query | High | | Cost | Per-license | Heroku Connect SKU | Use cases: Salesforce Connect: - Showing inventory from ERP in Salesforce account view. - Read-only browsing o

Question 40

How do you architect Lightning pages for performance?

Accepted Answer

Lightning page composition affects render time directly. Architecture matters. Composition guidelines: 1. Minimise component count. Each component costs render time. 30 components = noticeable lag. Prefer 5-10 carefully chosen. 2. Use Standard components first. , , , etc. Salesforce-optimised; better than reinvented. 3. Lazy load. Components in collapsed accordions / non-default tabs render only when shown. Use gates with . 4. Cache data. Apex methods. LDS for record data. 5. Tabbed layouts. Default tab loads only its components; other tabs lazy-load on click. 6. Component-level filters. Show/hide components based on user, record type, profile, criteria. Don't render what users don't need. 7. Reduce DOM size. Long lists virtualised ( virtualises). 1000-item lists rendered manually = slow. 8. Static resources for heavy assets. Images, JS libraries cached at CDN. 9. Avoid synchronous Apex on render. is async; no blocking render. Imperative Apex blocks; defer until user-triggered. 10. Optimise custom LWCs. - Avoid heavy work. - runs every render; keep tight. - Memoize expensive computations. 11. Profile. - Lightning Performance Analysis identifies slow components. - Browser DevTools P

Question 41

What are advanced LWC composition patterns?

Accepted Answer

Beyond basic parent-child, LWC supports compositional patterns for complex UI. 1. Slots for layout. Parent component defines layout; child fills in. Like CSS Flexbox + named slots. 2. Higher-order components (mixins). Reusable behavior shared across components via JS modules. 3. Dynamic component rendering. Render different components based on data: 4. Render-prop pattern (functional composition). Component A provides data; component B (passed in) renders it. 5. Container / Presenter. Container fetches data; Presenter receives via and renders. Stateless presenters easier to test. 6. Event-driven coordination. Sibling components don't talk directly; coordinate via Lightning Message Service or parent-mediated events. 7. Service layer. Custom JS modules for shared logic (validation, formatting, computation). Imported by multiple components. 8. State management. For complex apps: - Lightning Message Service for cross-tree state. - Wire-driven data for reactive updates. - For Redux-style state: third-party patterns or build your own. 9. Async patterns. - for reactive. - Imperative for one-off. - Loading states / spinners. - Error states. 10. Progressive enhancement. - Basic functionalit

Question 42

When do you use OmniStudio (FlexCards, OmniScripts, Integration Procedures) vs standard Salesforce?

Accepted Answer

OmniStudio is Salesforce's declarative framework for vertical / industry-specific applications. Originally Vlocity; now part of Industries Cloud. Components: - FlexCards — declarative UI cards, more flexible than Lightning Record Pages. - OmniScripts — guided workflows (think Wizard) with branching logic. - Integration Procedures (IP) — declarative server-side integrations and data orchestration. - DataRaptors — declarative data transformations between Salesforce and external. When OmniStudio beats standard: - Industry Cloud licensing — included. - Complex multi-step workflows with branching, validation, callouts. OmniScripts handle these declaratively. - Highly customised UI — FlexCards more flexible than Lightning Record Pages. - Server-side orchestration — Integration Procedures handle complex flows without writing Apex. - Declarative team — admins can build what would otherwise need devs. When standard Salesforce beats OmniStudio: - No Industry Cloud — OmniStudio licensed separately at significant cost. - Simple workflows — standard Flow handles fine. - Team familiar with Apex / LWC — standard stack often better than OmniStudio's curve. - Performance-critical — OmniScripts have

Question 43

How do you architect documentation for a Salesforce program?

Accepted Answer

Documentation is infrastructure. Done well, it scales the team's knowledge. Documentation tiers: 1. Strategic / decision-level. - Architecture Decision Records (ADRs) — significant decisions, rationale. - Solution Design Documents — per project. - Roadmap — multi-year direction. - Investment justifications — why we chose Salesforce, why this stack. Audience: leadership, future architects. 2. Reference / authoritative. - Data model documentation — every object, field, relationship. - Integration map — every flow, source, target, frequency, ownership. - Sharing model documentation — visualised. - Security architecture — layered approach. - Naming conventions and standards. Audience: anyone working on the platform. 3. Operational / runbooks. - Common admin tasks — step-by-step. - Troubleshooting guides — symptom - likely cause - fix. - Disaster recovery — outage response. - Hypercare runbook — issue triage. Audience: ops team, on-call. 4. User-facing. - Quick reference per persona — common tasks. - Process documentation — how to handle scenarios. - FAQ — common questions answered. - In-app guidance — tooltips, walkthroughs in Salesforce. Audience: end users. 5. Developer / Technical.

Question 44

How do you architect Salesforce for high availability?

Accepted Answer

High availability (HA) = system stays up despite failures. Salesforce as a SaaS provides baseline HA; architects layer on top. Salesforce-provided HA: - Multi-instance deployment — Salesforce runs in geographically distributed data centers. - 99.95% uptime SLA — measured monthly. - Automatic failover within data center. - Salesforce Trust dashboard for status. - Disaster Recovery (DR) with Recovery Time Objective (RTO) 12 hours. You don't manage the infrastructure; Salesforce does. Where architects influence HA: 1. Avoid single points of failure (SPOFs) in custom code. - Don't depend on one specific user for scheduled jobs (deactivation kills jobs). - Don't depend on one external system without fallback. - Don't depend on one Connected App without backup. 2. Resilient integrations. - Retries, dead-letter queues, circuit breakers. - Asynchronous patterns where possible. - Idempotent operations. 3. Capacity planning. - API call limits not exhausted by single integration. - Storage limits monitored, expanded before crisis. - Sandbox capacity available for emergency dev. 4. Disaster recovery. - Backup strategy — Salesforce native + external backup tools. - Restore testing — periodic dr

Question 45

How do you architect a major architectural migration (e.g., Aura -> LWC, monolith -> microservices)?

Accepted Answer

Big architectural migrations (years-long) require deliberate strategy. Pattern: strangler fig. Don't rewrite the whole monolith at once. Build new components alongside old; migrate users gradually; eventually retire old. Named after the strangler fig tree, which grows around its host until the host dies. Phases: 1. Assess. - Inventory current architecture. - Identify components. - Categorize by complexity, business value, technical debt. - Estimate migration effort per component. 2. Define target. - New architectural pattern. - Standards. - Reference architecture. - Success metrics. 3. Pilot. - Migrate one small component. - Validate the approach. - Iterate based on lessons. 4. Sequence. - High-value, low-complexity first (quick wins). - Or critical-path-blocking-other-work first. - Build dependencies into sequence. 5. Build incrementally. - New work in new architecture. - Old work continues in old architecture. - Coexistence during transition. - Both serve users; gradually shift load. 6. Migrate. - Component by component. - Test each migration thoroughly. - Rollback capability. - Communication to users. 7. Decommission. - When new replaces old completely, remove the old. - Final c

Question 46

How do you architect Salesforce for HIPAA / GDPR / PCI compliance?

Accepted Answer

Compliance shapes architecture deeply. Each regulation has specific requirements. HIPAA (US Healthcare): - PHI (Protected Health Information) must be encrypted at rest and in transit. - Business Associate Agreement (BAA) with Salesforce — required. - Audit trails of every PHI access. - Authorisation tracking — who accesses what, when. - Right of access — patient can request their records. Salesforce features: - Health Cloud with HIPAA features. - Shield Platform Encryption for PHI fields. - Field Audit Trail for retention. - Event Monitoring for runtime audit. - Salesforce signs BAA for HIPAA-eligible licenses. GDPR (EU): - Lawful basis for processing personal data. - Right to access — user can request their data. - Right to be forgotten — user can request deletion. - Right to portability — user can request data export. - Data minimisation — collect only what's needed. - Breach notification — within 72 hours. - Privacy by design — built in, not bolted on. - DPO (Data Protection Officer) for some orgs. Salesforce features: - Privacy Center — consent management, data subject requests. - Data Classification metadata. - Field Audit Trail . - Right-to-be-forgotten workflows (custom or v

Question 47

How do you architect a Salesforce + Heroku + AWS hybrid solution?

Accepted Answer

Hybrid architectures are common when Salesforce alone isn't enough. Roles: Salesforce — system of engagement. - CRM workflows, Service, Sales. - Lightning UI for users. - Business automation. Heroku — application platform. - Custom apps not fitting Salesforce model. - Heavy compute (image processing, ML). - Microservices. - Customer-facing custom UIs. - Postgres for non-Salesforce data. AWS — infrastructure / services. - Storage (S3) for files / archives. - Compute (Lambda) for specific functions. - AI/ML services (SageMaker, Bedrock). - Data warehouse (Redshift). - Streaming (Kinesis). - Operations (CloudWatch). Integration patterns: Salesforce <- Heroku: - Heroku Connect for bidirectional Postgres sync. - Salesforce Connect for read-only external object access. - Custom REST APIs in both directions. - Platform Events + Heroku subscribers for async. Salesforce <- AWS: - AWS PrivateLink for secure VPC connections. - AWS Lambda triggered by Salesforce events. - S3 for file storage referenced by Salesforce. - EventBridge for event routing. - API Gateway for managed APIs. Heroku <- AWS: - Common backend; use AWS services from Heroku apps. Use cases: 1. Customer portal. - Heroku hosts

Question 48

How do you handle Salesforce instance / data center moves?

Accepted Answer

Salesforce occasionally moves orgs between data centers (instance migrations) for capacity, region, or platform reasons. Common scenarios: - Hyperforce migration — Salesforce's modern infrastructure. Many orgs being migrated to Hyperforce. - Region change — moving an org's data center for latency / regulatory. - Sandbox refresh from a different instance — rare. Implications: 1. URL changes. - My Domain URL changes post-migration (e.g., - already mitigates). - Connected Apps callbacks may need update. - External integrations referencing instance URL need update. - Bookmarks and shortcuts by users break. 2. IP address changes. - Allowlisted IPs in external systems' firewalls need update. - Salesforce's outbound IPs for callouts change. 3. Performance characteristics. - Latency to / from external systems may change. - Data center proximity — different region means different ping. 4. Feature parity. - Hyperforce vs traditional — feature parity is high but not 100%. Some specific features may differ. 5. Sandbox refreshes. - After migration, sandbox refresh patterns may change. Preparation: 1. Salesforce communicates migration window in advance (often 60+ days notice). 2. Inventory: - Al

Question 49

How do you architect analytics across many systems (Salesforce + ERP + Marketing + Web)?

Accepted Answer

Cross-system analytics requires unified data, beyond what any single system can deliver. Architectural pattern: data warehouse + BI layer. 1. Data ingestion. - Salesforce — CDC + Mulesoft / native Snowflake connector / Heroku Connect. - ERP — vendor-specific (SAP HANA replication, Oracle GoldenGate, etc.) or custom ETL. - Marketing Cloud — APIs + ETL. - Web analytics — Google Analytics export, Mixpanel API, Segment. - Other — bespoke connectors as needed. All flow into a central warehouse. 2. Data warehouse. - Snowflake — most common modern choice. - BigQuery — Google ecosystem. - Redshift — AWS. - Databricks — for data science workloads. Warehouse holds ALL the data; processed for analytics. 3. Transformation. - dbt (data build tool) — SQL-based transformation; declarative. - Custom ETL — Python / Node / Spark. - Mulesoft / iPaaS — for orchestration. Transformation: clean, normalise, join across sources, build summary tables. 4. Storage tiers. - Raw layer — exactly as ingested. - Cleansed layer — standardised, deduped. - Conformed layer — joined across sources. - Mart layer — domain-specific (sales mart, marketing mart). 5. BI layer. - Tableau — visualisation, exploration. - Power

Question 50

How does a Salesforce architect stay current as the platform evolves?

Accepted Answer

Salesforce evolves rapidly. Architects who stop learning become obsolete. Continuous learning sources: 1. Release notes. - Every Salesforce release (3/year) has hundreds of features. - Read seasonal release notes — at least skim for relevance. - Identify features affecting your orgs. - Test in sandboxes; adopt where useful. 2. Trailhead. - Free, official, structured learning. - New Trailmixes for emerging topics (AI, Agentforce, Industry Clouds). - Architect Trail for senior topics. 3. Salesforce events. - Dreamforce — annual SF event; major announcements. - TrailblazerDX — developer-focused. - World Tour — regional events. - Industry summits . 4. Trailblazer Community. - Online forums — Q&A. - User Groups — local meetups. - Slack communities — informal Q&A and networking. 5. Industry sources. - Salesforce Architects website (architect.salesforce.com). - Salesforce Ben blog. - Apex Hours YouTube channel. - Sometimes Lightning podcast. - Twitter / LinkedIn Salesforce voices. 6. Stack Exchange (Salesforce). - Searching solves immediate problems. - Answering builds expertise. - Reputation builds professional brand. 7. Beta programs. - Salesforce Beta — early access. - Trailblazer Pre-

Question 51

How do you govern DevOps practices across multiple Salesforce teams?

Accepted Answer

Multiple teams + shared platform = DevOps governance matters. Standards: branching strategy, naming conventions, deployment workflow, code review process, test coverage thresholds, rollback procedures. Tooling: standardise on one DevOps platform (DevOps Center, Gearset, Copado). Don't let teams pick differently — incompatibilities later. Governance bodies: DevOps Council with team leads. Sets standards, reviews violations, evolves practices. Metrics: deploy frequency, time-to-deploy, change failure rate, mean time to recovery (the DORA metrics). Track per team; benchmark. Training: every engineer onboards through standard DevOps practices. Architect role: define standards, enforce via reviews, evolve as platform changes.

Question 52

How is Salesforce architecture different for B2B vs B2C?

Accepted Answer

B2B : selling to companies. Account-Contact-Opportunity. Multi-stakeholder deals. Standard data model fits. B2C : selling to consumers. Account = person (Person Accounts). High volume. Different tooling stack. Differences: - Data model : B2B uses Account+Contact; B2C uses Person Accounts (irreversible decision). - Volume : B2B has thousands of accounts; B2C has millions+. LDV strategy mandatory. - Marketing : B2B uses Pardot/MCAE; B2C uses Marketing Cloud Engagement. - Sharing : B2B more permissive often; B2C strict per-customer. - Privacy : B2C subject to GDPR/CCPA; B2B less regulated typically. - Self-service : B2C heavily uses Experience Cloud portals; B2B uses partner portals. - Integration : B2B integrates with ERP for orders; B2C integrates with commerce / payment. Architectural decisions per scenario. Hybrid B2B/B2C: many orgs serve both. Person Accounts + Business Accounts coexist; record types differentiate.

Question 53

How do you architect for mobile in Salesforce?

Accepted Answer

Mobile = field service, sales reps in customer meetings, service agents in remote locations. Native Salesforce Mobile App: - Out-of-the-box for any org. No build. - Renders Lightning pages with Phone form factor variations. - Compact Layouts for highlight panels. - Offline limited (Briefcase feature for some objects). Field Service Mobile App: - Specialised for field technicians. - Rich offline: download work orders, sync when online. - Map navigation, signature capture, photo upload. Custom mobile apps via Mobile SDK: - React Native, Swift, Kotlin via Mobile SDK. - Authentication via OAuth Connected App. - Offline-first design where needed. - For specific use cases beyond what Salesforce Mobile offers. Architectural decisions: - Use Salesforce Mobile by default — free, automatic. - Field Service Mobile for technicians. - Custom Mobile SDK for specific UX requirements. - Hybrid web app (Heroku-hosted) for cross-org scenarios. Test on real devices. What works on desktop fails on mobile.

Question 54

What patterns exist for AI integration on Salesforce?

Accepted Answer

Native Salesforce AI: - Einstein AI — embedded scoring, predictions, classifications. - Agentforce — autonomous AI agents. - Atlas Reasoning Engine — Salesforce's LLM platform. - Prompt Builder — reusable prompt templates. External AI: - OpenAI / Anthropic / Google APIs called from Apex. - AWS Bedrock / SageMaker for AWS-hosted models. - Azure OpenAI for Azure ecosystems. Patterns: 1. Generative actions. - User triggers; LLM generates (email draft, summary, recommendation). - Apex calls LLM via Connect API or external API. 2. Classification. - Records auto-classified (case category, lead score). - Trained on historical Salesforce data. 3. Conversational interfaces. - Chatbots (Einstein Bots) handle initial contact. - Hand off to human when needed. 4. Agent assist. - AI suggests responses to agents in real time. - Agent reviews and accepts. 5. Document understanding. - AI extracts data from uploaded docs. - Populate Salesforce records automatically. Architecture decisions: - Trust Layer mandatory for sensitive data. - Fallback paths when AI unavailable. - Cost monitoring per call. - Human-in-the-loop for high-stakes. - Audit every AI decision.

Question 55

How do you manage vendor relationships as a Salesforce architect?

Accepted Answer

Multiple vendors typical: Salesforce, AppExchange ISVs, Mulesoft, Heroku, AWS, consulting firms. Practices: 1. Track vendor health. - Financial stability. - Roadmap alignment. - Support quality. - Customer references. 2. Negotiate contracts. - Multi-year for discount; lock-in trade-off. - Bundle deals where possible. - Renewal date awareness; don't auto-renew without review. 3. Manage SLAs. - Each vendor's SLA — uptime, response, resolution. - Track against actual. - Escalate on breaches. 4. Avoid lock-in. - Open APIs over proprietary. - Avoid deep customisation of vendor packages — hard to switch. - Plan exit costs. 5. Centralise vendor management. - One person / team coordinates across vendors. - Avoids each project starting from scratch. 6. Annual reviews. - Each vendor reviewed: still aligned? Still healthy? - Replace under-performing vendors. Architect role : provide technical input to vendor decisions. Recognise red flags before contract signing.

Question 56

How do you build and grow an architecture team?

Accepted Answer

Team composition: - Lead Architect — sets direction, mentors. - Domain Architects — Data, Integration, Security, Sharing. - Solution Architects — project-level. - Senior Engineers transitioning to architect. Hiring: - External hire for specialised expertise. - Internal promotion for cultural fit and platform knowledge. - Mix is typical. Roles to define: - Who reviews code at architect level? - Who chairs ARB? - Who owns standards documentation? - Who runs architect community of practice? Skill development: - Trailhead Architect Trail. - Domain certifications progressing toward CTA. - Mentorship from senior architects. - Conference attendance. - Stretch projects. Architect community of practice: - Monthly internal meetups. - Tech talks and demos. - Code reviews. - Knowledge sharing. Career progression paths: - Solution Architect - Senior SA - Principal . - Technical Architect - Senior TA - CTA . - Hybrid roles — Solution + Technical at smaller orgs. Common pitfalls: - No architecture team — architects scattered, no consistency. - Ivory tower — architects detached from actual delivery. - Senior-only team — no juniors learning. - No mentorship — knowledge stays with individuals. Senio

Question 57

How do you architect Salesforce for an M&A scenario?

Accepted Answer

M&A: Company A acquires Company B. Both have Salesforce. Decisions: Option 1: Migrate B into A's org. - Pro: single source of truth. - Con: complex data migration, business disruption. - Best when: cultures align, B is small relative to A. Option 2: Keep both orgs separate. - Pro: minimal disruption. - Con: data silos, double licensing, operational complexity. - Best when: legal separation required, business units autonomous. Option 3: Hub-and-spoke (multi-org). - Central org with shared customer master. - A and B as spokes. - Mulesoft sync between. - Best when: long-term coexistence, want unified analytics. Option 4: Phased consolidation. - Start separate; migrate over 12-24 months. - Risk-managed approach. Considerations: - Data residency — different regions may force separation. - Regulatory — HR / financial separation requirements. - Customer overlap — shared customers benefit from unified view. - Licensing cost — duplicate often expensive. - Operational load — managing two orgs is real work. - Cultural fit — forcing one team to adopt another's patterns is hard. Architectural blueprint: - Discovery — understand both orgs. - Decision with leadership. - Migration plan if consolid

Question 58

How do you architect risk management for a Salesforce program?

Accepted Answer

Architectural risk register beyond project-level risks. Categories: Technical risks: - Scalability ceiling approaching. - Single integration point of failure. - Deprecated platform features in critical paths. - Performance regression at growth thresholds. Operational risks: - Talent dependency on key individuals. - Vendor instability. - Knowledge documented inadequately. - Backup / disaster recovery untested. Strategic risks: - Salesforce roadmap divergence from current implementation. - Industry / competitor moves. - Regulatory shifts. - M&A possibilities. Process per risk: - Identify — surface risks proactively. - Score — probability × impact. - Assign owner. - Mitigation — actions to reduce probability or impact. - Contingency — what if it materialises. - Track — review monthly. Mitigation patterns: - Scalability : design for 10x current volume. - Single integration : identify alternatives, build resilience. - Deprecated features : track timeline; migrate before forced. - Talent dependency : knowledge sharing, pair programming, documentation. - Vendor instability : monitor health, plan exits. Reporting: - Quarterly to leadership. - Top risks visible. - Mitigation progress tracke

Question 59

How do you architect disaster recovery for Salesforce?

Accepted Answer

Disaster Recovery (DR) = restoring service after major incident: data center failure, ransomware, severe data corruption, prolonged outage. Salesforce-provided DR: - Multi-region replication — Salesforce replicates between data centers. - RPO (Recovery Point Objective) 4 hours. - RTO (Recovery Time Objective) 12 hours. - Disaster scenarios Salesforce handles: data center outage, regional failure. If standard DR meets your needs: trust Salesforce. When you need more: - Customer-data corruption — Salesforce replicates the corruption. Need point-in-time recovery from before corruption. - Ransomware / malicious deletion — bad actors with admin access can delete; DR needs prior version. - Legal hold — maintain pristine snapshot for litigation. - Compliance — RPO < 4 hours required. Beyond-Salesforce DR: 1. Backup tools: - OwnBackup (Own Company) — most common. - Spanning — alternative. - Gearset — has backup features. - Custom export — Bulk API + S3. 2. Backup what: - Data (records). - Metadata (objects, fields, code). - Files / attachments . - Configuration . 3. Backup cadence: - Daily incremental typical. - Full weekly for completeness. - Continuous for highest-RPO needs. 4. Restore t

Question 60

Walk me through architecting a complex data migration to Salesforce.

Accepted Answer

Data migration architecture for legacy CRM - Salesforce, several million records, 50+ source tables. Phase 1: Discovery (2-4 weeks): - Source inventory — every table, row count, field count, data quality assessment. - Profile data — completeness, distribution, anomalies, duplicates. - Dependencies — parent-child relationships, circular references. - Target Salesforce model — designed in business Discovery. Phase 2: Mapping (2-4 weeks): - Field-level mapping spreadsheet: source.field - target.field. - Transformation rules — formatting, defaults, lookups, conditional logic. - Picklist value mappings — source values - Salesforce values. - Owner mapping — source users - Salesforce users. - External Id strategy — for stable referencing. Phase 3: Tooling (1-2 weeks): - Bulk API 2.0 for inbound data. - Mulesoft / Talend / custom Python for transformations. - Salesforce Data Loader for smaller migrations. - Custom Apex for complex transformations. Phase 4: Iterative migration testing: Pass 1: Tiny sample (10-100 rows). Validate end-to-end, mapping, error handling. Pass 2: Subset (1-10% of volume). Performance check; identify scaling issues. Pass 3: Full volume in sandbox. Time the run; reh

Question 61

How do you architect Industries Cloud (e.g., Financial Services, Health) implementations?

Accepted Answer

Industries Clouds = Salesforce verticals with pre-built data models, OmniStudio components, industry-specific features. Architectural considerations: 1. Vertical fit. Validate the Industry Cloud's data model genuinely fits before committing. Too much customisation defeats the purpose. 2. OmniStudio integration. Industries Clouds heavily use OmniStudio (FlexCards, OmniScripts, Integration Procedures, DataRaptors). Architects design with OmniStudio patterns. 3. Hybrid with standard. Industries Cloud + Sales Cloud + Service Cloud common. Account/Contact shared; vertical objects layered on. 4. Custom code minimised. Industries Cloud favours declarative + OmniStudio. Custom Apex / LWC reserved for what they can't do. 5. Vertical integrations. Each Industries Cloud has expected integrations: Health - EMR systems; Financial Services - core banking; etc. 6. Compliance. Industries Clouds often pre-configured for vertical compliance (HIPAA for Health, FINRA/SEC for Financial Services). Architects ensure config is leveraged. 7. Talent. Industries Cloud talent is specialised. Smaller pool than core Salesforce. Plan accordingly. 8. Roadmap alignment. Salesforce evolves Industries Clouds with pl

Question 62

How do you architect a Salesforce modernization program (vs greenfield)?

Accepted Answer

Modernization = improving an existing org. Different from greenfield. Discovery: - Inventory what exists. - Categorize by health (good / fair / poor / deprecated). - Identify pain — performance, quality, adoption issues. - Quantify — current cost / time-to-deploy / defect rate. Strategy components: 1. Tech debt cleanup. - Process Builder - Flow. - Aura - LWC. - Custom code review and refactoring. - Field cleanup (unused, redundant). - Profile sprawl resolution. 2. Platform upgrades. - DX adoption (DevOps Center / CLI). - CI/CD pipeline setup. - Sandbox strategy. - Standardised tooling. 3. UX modernisation. - Lightning Experience adoption. - Dynamic Forms. - Modern Lightning Record Pages. 4. Security tightening. - Permission audit. - Sharing model review. - MFA, SSO enforcement. - Shield adoption where needed. 5. Performance optimisation. - Slow components / queries identified. - Bulkification. - Caching strategy. 6. Governance establishment. - Center of Excellence stand-up. - Architecture Review Board. - Standards documentation. Phased approach: - Phase 1 (foundation) : critical fixes, governance. - Phase 2 (UX/performance) : visible improvements. - Phase 3 (advanced) : AI, advance

Question 63

How do you architect a comprehensive data strategy?

Accepted Answer

Data strategy = governance, quality, integration, retention, analytics — all coordinated. Components: 1. Data ownership. Per object / domain: who owns the data? Data Steward role per domain. 2. Master Data Management. - Single canonical version per entity (Customer, Product, Employee). - Salesforce as MDM, or external MDM tool. - Cross-system reconciliation. 3. Data quality. - Validation rules. - Duplicate management. - Cleansing schedule. - Quality dashboards / scorecards. 4. Data lifecycle. - Retention per data type. - Archive strategy (Big Object / external). - Deletion / anonymisation workflows. - Compliance with regulations. 5. Data integration. - System-of-record per object. - Sync patterns. - Conflict resolution. - Audit trail. 6. Data classification. - Sensitivity levels. - Compliance categories. - Drives encryption / sharing decisions. 7. Analytics architecture. - Operational reporting in Salesforce. - Cross-system in warehouse + BI. - Real-time vs batch. - AI / ML inputs. 8. Data governance. - Council with data stewards. - Standards documentation. - Change request process for schema. - Data quality reviews. 9. Talent. - Data engineers for warehouse. - Data architects for

Question 64

How do you architect for innovation (new features, AI, experimentation)?

Accepted Answer

Innovation requires architecture that supports experimentation without breaking production. Patterns: 1. Feature flags. - Toggle features on/off without deploy. - Gradual rollout to subsets of users. - Quick rollback if issues. - A/B testing. Stored in Custom Metadata; checked at runtime. 2. Sandbox-based experimentation. - Try new features in scratch / dev sandboxes. - No risk to production. - Validate before promotion. 3. Beta program participation. - Salesforce beta — pre-release access. - Trailblazer Pre-Release — try before public. - Early feedback to Salesforce; influence direction. 4. Innovation budget. - 10-20% of team capacity for exploration. - Without dedicated time, innovation never happens. 5. Innovation showcase / hackathons. - Periodic events to try new things. - Best ideas graduate to production. 6. Strategic alignment. - Innovation should align with business strategy. - "Just because we can" usually fails. 7. Decoupled architecture for safety. - New features in new components, decoupled from core. - If experiment fails, core unaffected. - Easy to remove. 8. Customer feedback loops. - Innovation in close contact with users. - Iterate based on response. 9. Failure to

Salesforce Architect interview questions

Top 10 must-know

All 100 questions

Easy

Medium

Hard

Top 10 must-know

1What does a Salesforce Architect do, and how is it different from a Consultant or Developer?easy

2What are the Salesforce CTA domains?easy

3What's the difference between Solution Architect and Technical Architect?easy

4What is an Architecture Decision Record (ADR) and how do you use it?easy

5How do you architect a Salesforce solution for scale?medium

6From an architect perspective, when do you choose Apex vs Flow vs declarative tools?medium

7Walk me through architecting an enterprise multi-org Salesforce program.hard

8Walk me through a CTA-style multi-domain Salesforce solution architecture.hard

9How do you architect security across all layers in Salesforce?medium

10What habits separate junior architects from senior ones?hard

All 100 questions

Easy

What does a Salesforce Architect do, and how is it different from a Consultant or Developer?easy

What are the Salesforce CTA domains?easy

What's the difference between Solution Architect and Technical Architect?easy

What is a Reference Architecture and why do organizations use them?easy

What is an Architecture Decision Record (ADR) and how do you use it?easy

What is an Architecture Review Board (ARB) and how do you run one?easy

What are non-functional requirements and why do architects care more about them than functional ones?easy

How is the Salesforce platform different from generic PaaS like Heroku or AWS?easy

What's a recommended trigger framework pattern at architect level?easy

What are common LWC architecture patterns?easy

How do you use Custom Metadata Types as an architecture pattern?easy

What's an architect-level Apex code review checklist?easy

What's a comprehensive testing strategy at architect level?easy

How do you govern DevOps practices across multiple Salesforce teams?easy

How is Salesforce architecture different for B2B vs B2C?easy

How do you architect for mobile in Salesforce?easy

What patterns exist for AI integration on Salesforce?easy

How do you manage vendor relationships as a Salesforce architect?easy

How do you do capacity planning for Salesforce?easy

How do you optimize Salesforce costs at architect level?easy

How does Salesforce compare with AWS / Azure / GCP from architecture perspective?easy

How do you architect for long-term sustainability (years to decades)?easy

How do you manage an architecture team day-to-day?easy

Medium

How do you architect a Salesforce solution for scale?medium

How do you manage technical debt in a Salesforce org?medium

How do you do a Technical Discovery (vs business Discovery)?medium

How do you architect for resilience and graceful degradation?medium

How do you architect for multi-region (global) Salesforce deployments?medium

How do you make a build-vs-buy decision at architect level?medium

How do you architect data flow across multiple systems?medium

How do you handle architectural disagreement with stakeholders or other architects?medium

From an architect perspective, when do you choose Apex vs Flow vs declarative tools?medium

How do you balance new feature development with platform health?medium

How do you architect CI/CD for a Salesforce project?medium

How do you architect logging and monitoring for a Salesforce org?medium

How do you architect caching in Salesforce?medium

How do you architect event-driven systems on Salesforce?medium

When does Mulesoft beat custom integration code?medium

What's a systematic approach to performance tuning a slow Salesforce org?medium

How do you architect security across all layers in Salesforce?medium

How do you architect encryption (Shield, masking, in-transit) in Salesforce?medium

When do you use Heroku Connect vs Salesforce Connect?medium

How do you architect Lightning pages for performance?medium

What are advanced LWC composition patterns?medium

When do you use OmniStudio (FlexCards, OmniScripts, Integration Procedures) vs standard Salesforce?medium

How do you architect documentation for a Salesforce program?medium

How do you build and grow an architecture team?medium

How do you architect Salesforce for an M&A scenario?medium

How do you architect risk management for a Salesforce program?medium

How do you architect disaster recovery for Salesforce?medium

Walk me through architecting a complex data migration to Salesforce.medium

How do you architect Industries Cloud (e.g., Financial Services, Health) implementations?medium

How do you architect a Salesforce modernization program (vs greenfield)?medium

How do you architect a comprehensive data strategy?medium

How do you architect for innovation (new features, AI, experimentation)?medium

How do you architect Sales + Service + Marketing + Field Service together?medium

When does Salesforce serve as a platform (PaaS) vs CRM application?medium

How do you architect for deprecated Salesforce features?medium

How do you architect Mulesoft as the integration backbone?medium

How does Data Cloud fit into a Salesforce architecture?medium

How do you architect IoT integration with Salesforce?medium

How do you architect cyber security incident response for Salesforce?medium

How do you architect multi-region active-active for Salesforce?medium

How do you architect for data residency requirements?medium

How do you architect developer tooling for Salesforce?medium

How do you architect communication channels for an architecture program?medium