Architecture: evaluate single org (unified data, complex governance) vs multi-org (simpler per region, data silos). For AWS scale: single org with Territory Management (geographic hierarchy), Salesforce Shield (encryption + event monitoring), Custom Indexes on all filter fields, Platform Cache for repeated queries, CRMA for reporting (standard reports too slow at this scale), Async Apex for all heavy processing | Performance: no synchronous processing over 1000 records, batch Apex for data operations, Platform Events for real-time decoupled integrations

Real-time pattern: business event in AWS (order created, payment processed) → EventBridge rule → Lambda function → Salesforce REST API creates/updates record | Batch pattern: Redshift data → nightly MuleSoft job → Salesforce bulk API | Document pattern: S3 file upload → Lambda → Salesforce ContentVersion API | Security: Named Credentials in Salesforce for AWS endpoint authentication, IAM roles for Lambda → Salesforce auth | Platform Events: Salesforce event → Amazon SQS → downstream AWS processing

Single org benefits: single customer record (360 view), unified reporting, one admin team, shared AppExchange licenses | Multi-org benefits: data residency compliance (EU data stays in EU org), acquisition integration speed, different security models per business unit | Amazon context: likely uses multiple orgs (AWS commercial, AWS public sector, Amazon Advertising, Amazon Retail) each with very different data models | When to merge: only when business benefit of shared data exceeds migration risk | Key question: do these business units share customers?

Apex limits: 100 SOQL/transaction → batch into IN clauses, 150 DML/transaction → collect in lists, 10MB heap → process in chunks | Batch Apex: Database.Batchable with finish() chaining next batch | Platform Events: high-volume events bypass standard limits (different governor model) | External Objects: for data that doesn't need to live in Salesforce (keep in external system, query via OData) | Big Objects: for archiving millions of historical records | Monitoring: Apex Jobs, Event Log Files, Salesforce Optimizer

Einstein Activity Capture: auto-sync Gmail/Outlook — critical at Amazon scale (50K reps cannot manually log activities). Opportunity Scoring: ML model trained on historical closed deals — needs 1,000+ closed opps minimum. Deal Insights: proactively flags no activity, competitor mentions, close date risk. Forecasting AI: more accurate than rep forecast at scale (removes individual rep optimism bias). Conversation Insights: automatic call coaching at scale — manager cannot listen to all calls but AI can surface key moments | Data quality prerequisite: Einstein is only as good as the data — Activity Capture first.

OWD: start Private for Opportunities (most restrictive — reps see own deals only), Role Hierarchy: AE → Manager → VP → CRO (vertical access), Territory Rules: horizontal access (all deals in my territory regardless of owner), Permission Sets: feature access (CPQ users, Einstein users, Reports-only users) | Field-Level Security: restrict salary data, contract terms | Shield Encryption: SSN, credit card, contract value fields | Event Monitoring: export of customer data, mass data access | Profile: minimal permissions, use Permission Sets for additive access | Never: give System Admin to non-admins

Event-driven design: decouple systems with events so each component is independently scalable | Lambda: stateless transformation and routing (no persistence) | Platform Events: Salesforce native event bus (bypasses standard API limits for high-volume) | Error handling: dead letter queue (SQS DLQ) for failed events → Lambda retry with exponential backoff → alert if max retries exceeded | Idempotency: external ID on Salesforce records ensures duplicate events don't create duplicates | Monitoring: CloudWatch for Lambda + Salesforce Event Log Files for Salesforce side

Product simplification: 300 AWS services → 20 base product types with attributes (region, tier, commitment) | Pricing methods: Percent of Total (support as % of subscription), Block (compute tiers), Consumption (per-unit usage) | Guided Selling: help sales rep configure right AWS bundle for customer use case | CPQ vs RLM: AWS greenfield would likely use RLM (newer, native, attribute-based) not CPQ managed package | Twin Fields: all custom fields mapped to Orders for billing | Approval: large AWS deals → multi-level approval (discount % thresholds)

Scale considerations: 100,000+ partners → LWR (Lightning Web Runtime) for performance vs Aura, CDN for static assets, caching for catalog data | Partner data isolation: Partner Community license + sharing rules ensure partners see only their data | Deal Registration: custom object with approval workflow (partner submits → Amazon channel manager reviews → approved/rejected → 90-day price protection) | Localization: 12+ languages via Translation Workbench | Mobile: Experience Cloud responsive design | SSO: partner SSO via SAML/OAuth for seamless login

Specific optimizations: Custom Indexes (request from Salesforce) on high-cardinality filter fields, Skinny Tables (Salesforce internal — contact support) for critical list views, Platform Cache (Org cache for config data, Session cache for user-specific), Async Apex for everything beyond 200 records, Continuation (async callout for long-running API calls) | Monitoring: Debug logs (production sampling only), Event Log Files (daily API/report usage), Apex Jobs (batch performance) | Storage: archive records > 2 years old to reduce query scope | Experience Cloud: CDN + LWR for fastest portal performance

Source control: all metadata in Git, no org-based development | Branch strategy: feature branches → develop → staging → main | Scratch orgs: each developer gets isolated scratch org (no shared sandbox conflicts) | CI pipeline: on PR → run Apex tests + PMD static analysis + Jest component tests + check code coverage (minimum 85%) | CD pipeline: on merge to main → deploy to staging → smoke test → deploy to production | Package development: unlocked packages for modular deployment | Conflict resolution: metadata conflicts flagged in PR review | Environment count: scratch orgs (unlimited) + Integration sandbox + Full UAT sandbox + Pre-prod + Production

Platform Events: developer-defined event schema, published explicitly in Apex/Flow/API, 250,000/day standard, durable 72hr retention, use for business process events | CDC: auto-published by Salesforce on any record change, includes changed fields + old/new values, header (transactionKey, sequenceNumber), use for data sync to external systems | Amazon use cases — Platform Events: Order activation triggers provisioning pipeline, Quote accepted triggers contract workflow | CDC: sync Salesforce Account changes to AWS DynamoDB in real-time, sync Case updates to Redshift for analytics | Both subscribe via EmpApi in LWC or Apex trigger or external system via CometD | Key difference: Platform Events = you control when/what; CDC = Salesforce automatically fires on every record change

100M+ records: Custom Indexes mandatory (request via Salesforce Support case) on all fields used in WHERE clauses | Skinny Tables: Salesforce internal feature, contact Support — creates denormalized table for critical list view queries, massive performance improvement | Sharing recalculation: for large orgs, sharing recalc is async and can take hours — defer by disabling then re-enabling after bulk loads | Big Objects: archive records older than 2 years to Big Objects (different storage, query via SOQL with limitations, reduces main object size) | External Objects: if data lives in external system (AWS Redshift), Salesforce Connect + OData adapter queries it without storing in Salesforce | SOQL: always selective (indexed field in WHERE clause), avoid LIKE queries on large objects, use LIMIT + offset for pagination | Monitoring: Query Plan Tool in Developer Console to verify query plan uses index

Apex error logging: custom Error_Log__c (object, record id, error message, stack trace, timestamp, retry count) | Platform Event: on critical error → fire ErrorOccurred__e event → Flow sends Slack/email alert | Integration errors: failed Platform Event → Pub/Sub dead letter topic → Lambda → retry with exponential backoff → alert if max retries exceeded | Retry logic: attempt 1 (immediate) → attempt 2 (5 min) → attempt 3 (30 min) → alert and manual review | Monitoring dashboard: CRMA showing error rate by integration type, daily error trend, error resolution SLA | Amazon-side: CloudWatch alarms on Lambda error rate, API Gateway 5xx errors → SNS → PagerDuty for on-call | Health check: scheduled Apex job every 15 min testing all integration endpoints | Runbook: documented remediation for each error type

Custom Metadata: records deployed via Change Set/DX, accessible in SOQL, visible in test classes without SeeAllData=true, best for: API endpoints by environment, feature flags, configuration tables, pricing thresholds | Custom Settings (Hierarchy): org-level or user/profile level values, accessed via getInstance() in Apex (no SOQL, very fast), best for: user preferences, org-wide switches, frequently accessed config | Custom Settings (List): deprecated — use Custom Metadata instead | Amazon context: API endpoint URLs → Custom Metadata (different values per sandbox/production, deployed automatically), Feature Flags → Custom Metadata (enable/disable features per environment), Rate limits → Hierarchy Custom Settings (different per user group, fast access) | Performance: Custom Settings getInstance() faster than Custom Metadata SOQL query — use Custom Settings for values accessed in high-frequency Apex

Agent design: Service Channel (chat + email), Topics (Account Status, Service Health, Support Cases, Billing Inquiries, Feature Requests), Actions (custom Apex actions calling AWS Service Health API, Salesforce SOQL for account data, Case creation) | Knowledge: Salesforce Knowledge + AWS public documentation | Escalation: confidence threshold not met → escalate to CSM with full conversation context | Containment target: 50-60% of routine inquiries resolved without human | Guardrails: never provide pricing commitments, never promise SLA changes — escalate to human | Data: Agentforce can query Salesforce data natively (Account, Case, Contract) + custom Actions for AWS API calls | 2026: MCP Servers (GA Summer 26) enable direct AWS API access from Agentforce without custom Apex

External Object: looks like Salesforce object, queryable via SOQL, can be related to standard objects (Account → AWS_Consumption__x), accessible in page layouts and list views | Adapters: OData 2.0/4.0 (standard), custom adapter (Apex), cross-org adapter | AWS setup: API Gateway + Lambda → OData-compliant endpoint → Salesforce External Data Source | Use cases: AWS billing data on Account page, EC2 instance inventory linked to Asset, support ticket history from external system | Limitations: no triggers, no workflow, no reports (use SOQL query), no offline (requires live connection) | vs storing in Salesforce: External Objects = zero storage cost + always current data, but slower query and no standard reports | Hybrid: store aggregate data in Salesforce (custom field: AWS_Monthly_Spend__c updated nightly) + External Object for detailed drill-down

Data ownership: Account master in Org A → sync to Org B/C as read-only copies | Sync mechanism: change in Org A → Platform Event fired → AWS EventBridge routes → Lambda → Org B/C REST API upsert | External IDs: Master_ID__c on all synced records (Org A internal ID) → enables idempotent upsert in Org B/C | Conflict: Org A is master for Account — Org B changes to Account fields are rejected (or queued for master approval) | MuleSoft: preferred for complex topologies (A↔B↔C with different field mappings per org) | Heroku Connect: option for simpler PostgreSQL-based sync | Challenges: circular sync prevention (Sync_Source__c field to prevent re-triggering), eventual consistency (not real-time), schema drift (when Org A adds field, Org B needs update) | Monitoring: sync lag dashboard, failed sync queue

@future: simple async, cannot be called from Batch/Queueable, no monitoring, avoid — use Queueable instead | Queueable: implements Queueable interface, System.enqueueJob(), chainable (finish() → enqueueJob(new NextJob())), job ID for monitoring, supports callouts, 50 jobs/transaction | Batch: Database.Batchable, start/execute/finish, best for 10,000+ records, configurable scope (200 default), 5 concurrent | Scheduled: implements Schedulable, System.schedule() with cron, calls Batch or Queueable | Platform Events: highest throughput (250K/day), decoupled, subscriber handles async | Amazon use case: Order activation (Queueable chain: Step1.finish → enqueue Step2 → Step2.finish → enqueue Step3), nightly data sync (Batch), real-time provisioning (Platform Events + Lambda), scheduled reports (Scheduled → Batch)

Encryption types: Probabilistic (maximum security, same value encrypted differently each time — cannot use in SOQL filter, formula, or workflow) vs Deterministic (can be used in SOQL WHERE, sort, group — less secure but functional) | Encrypted field limitations: no formula fields that reference encrypted field, no Apex sorting, no standard filter in list views, no partial search (LIKE) | Key management: Salesforce-managed (default), customer-managed tenant secret (BYOK — you hold the encryption key, Salesforce cannot decrypt), Hardware Security Module (highest compliance) | Amazon use: SSN and salary fields (Probabilistic — never queried), Contract_Value__c (Deterministic — needed in SOQL filters for revenue reports) | Compliance: PCI-DSS, HIPAA, GDPR — Shield satisfies field-level encryption requirement | Testing: encrypted fields in sandbox behave differently (different keys) — test all SOQL/reports before production

Situation: describe the before state with specific pain (3 hours manual, 18% error rate, 2-day delay). Task: your specific ownership. Action: your steps (analysis → design → build → test → train → deploy). Result: specific measurable outcome (reduced from 3 days to 4 hours, saved $180K annually, adoption 94%). | LP mapping: Invent and Simplify (new approach), Deliver Results (measurable outcome) | Avoid: vague answers ("we improved the process"), passive voice ("it was decided"), team credit without personal contribution

Key elements: show you made a deliberate scope decision (not a panic cut), communicated what was deferred and why, delivered the highest-value items first, documented what was deferred for Phase 2 | Frugality angle: what did you build without needing? | Bias for Action: moved quickly on the reversible decisions | Trade-off: clearly articulate what you chose not to build and why | Result: delivery outcome + customer satisfaction despite constraints | Never say: "we worked 80-hour weeks" — Amazon does not celebrate overwork as a virtue

Structure: what was the failure specifically (missed date, wrong solution, production issue), what was YOUR contribution to the failure (not the team), what you did when you discovered it (speed of escalation), how you communicated it (proactive vs reactive), what the outcome was (recovered or not), what you learned and changed | Critical: never throw others under the bus. Never say "the client kept changing requirements." Take ownership of what you could have controlled | LP: Ownership means no excuses — "I should have caught this earlier," "I should have validated this assumption"

Setup: what was the conventional wisdom or stakeholder preference? What data did you gather to evaluate it? What did the data show? What was the decision? What happened? | Data sources: user adoption reports, activity data, A/B test results, CSAT scores, win rate analysis | Example: stakeholder wanted 12 opportunity stages, data showed reps skipped middle stages 67% of time → proposed and implemented 7 stages → win rate improved | Backbone: you made an unpopular recommendation based on data | Result: the data-driven decision was vindicated

Disagreement story structure: what was the disagreement (technical approach, prioritization, timeline), how did you present your position (data, examples, risks), how did you listen to their position (what they taught you), what was the resolution, how fully did you commit | Critical: show genuine listening — "they made a valid point I had not considered" | Disagree and Commit: if decision went against you, show you fully committed to execution with no passive resistance | Result: professional relationship strengthened despite disagreement

Questions to ask first: shared customer records across regions? Same sales process everywhere? Data residency requirements (GDPR)? | Architecture: Single org (shared 360 view) vs multi-org (compliance). Territory: geographic (Country → Region → District → Rep). Sharing: Private OWD + Territory rules. Performance: indexes on all filter fields, Platform Cache for config data. Integration: EventBridge for real-time AWS events. Reporting: CRMA (standard reports too slow at this scale). Compliance: Shield encryption for contract data, event monitoring for exports | Deployment: Salesforce DX, CI/CD pipeline for 15-country release management

Volume architecture: Archive cases >90 days to Big Objects (keeps Case object small, fast queries). Custom Indexes: CaseNumber, Status, OwnerId, CreatedDate (all common filters). Bot: Einstein Bot handles 40-50% of routine inquiries (password reset, order status, billing questions) before reaching agent — reduces human case volume to 500-600K. Omni-Channel: intelligent routing prevents queue bottlenecks. Macros: bulk macros for outage scenarios (1000+ cases same issue). Email: On-demand Email-to-Case for attachments. Async Flows: high-volume case creation uses Platform Events + async Flow to avoid trigger limits | Reporting: CRMA for SLA analytics (standard dashboards too slow at this volume)

Data model: Account → AWS_Commitment__c (committed spend, start/end date, credit amount) → AWS_Consumption__c (daily usage from AWS Cost Explorer API) | Integration: AWS Cost Explorer API → Lambda (nightly) → Salesforce Bulk API upsert consumption records | Formula: Credit_Utilization__c = Total_Consumed__c / Committed_Amount__c | Alert: Flow: Utilization > 80% → Task for rep + email | Renewal: Scheduled Flow: 90 days before commitment end → create Renewal Opportunity | Dashboard: CRMA showing consumption trend, utilization by account, commitments expiring next 30/60/90 days | Business value: rep sees customer about to overage → upsell conversation

Data residency: Salesforce Hyperforce enables EU data stored in EU AWS regions. Field-level: PII fields encrypted with Shield (name, email, phone, address). Consent: custom Consent__c object (consent type, date, source, withdrawal date) linked to Contact. Subject Access Request: custom workflow — request received → 30-day SLA → automated data extract → email to subject. Right to Erasure: Flow: erasure request → anonymize fields (GDPR does not require deletion if legitimate interest exists) → log completion. Data exports: Event Monitoring tracks mass data exports for audit. DPA: Salesforce signs Data Processing Addendum for GDPR compliance at platform level. Privacy by Design: new fields require Data Protection Officer review before creation.