Every query Salesforce runs adds WHERE OrgID = ? automatically | Custom fields = UDD metadata rows, not new DB columns | Schema changes never require DB downtime | The optimizer must work extra hard because queries hit shared tables with billions of rows | Governor limits exist to protect shared resources from one tenant starving others

Apex compiles at SAVE time — runtime errors are logic errors, not syntax | The sandboxed execution prevents file system and network access by default | Governor limits are enforced via bytecode instrumentation — not optional | The Apex runtime is separate from the Force.com web server — they communicate via internal APIs | Every Apex transaction gets its own isolated governor limit context

Governor limits are NOT a developer convenience — they are architectural necessity for multi-tenancy | Crossing a limit throws an exception that halts the transaction — not a warning | The async framework (Batch/Queueable) has looser limits because it runs in a managed, isolated queue | Platform Cache exists to reduce DB load from repeated queries across multiple users

Before triggers: read/modify fields before save — no record ID available yet | After triggers: record ID exists, can create related records, but field changes need another DML | Flows run AFTER triggers — a common source of unexpected re-triggering | Multiple automation tools on the same object means multiple executions in one save | Recursive trigger prevention must be implemented at the architect level, not just the developer level

Metadata API is asynchronous — large deployments queue and run in the background | Tooling API is synchronous — ideal for real-time IDE interactions | Connect API abstracts complex multi-object operations into single endpoints | SFDX CLI uses Metadata API under the hood for deployments | Never use Metadata API for data operations — that's what REST/Bulk API is for

Zero DDL = zero table locks = zero downtime for schema changes | The UDD has a finite number of SLOT columns — this is why there's a limit on custom fields per object (~500) | Different data types use different physical tables: strings in MT_DATA, large text in MT_CLOB, long text in MT_LONG | Deleting a custom field marks the slot as available in UDD but doesn't change the physical table

@future cannot be called from Batch Apex execute() — use Queueable instead | Queueable supports typed parameters (unlike @future which only accepts primitives) | Batch Apex has a maximum of 5 concurrent running jobs per org | Transaction Finalizers (Queueable) enable reliable async processing with success/failure handling | Scheduled Apex is the entry point — actual work should delegate to Batch or Queueable

LWC is built on W3C Web Components standard — skills transfer to non-Salesforce development | Locker Service prevents cross-namespace DOM access — important for AppExchange security | @wire is declarative data fetching — reactive, cached, auto-refreshed on record changes | LWC on mobile uses the same component model as desktop — no separate codebase needed | Visualforce is not deprecated but receives no new features — architects should prefer LWC

Trusted: every architecture decision has a security implication — evaluate it explicitly | Easy: if an admin can't maintain it without a developer, the architecture has a complexity debt | Adaptable: architecture should handle 10x current volume without redesign | Aligned: every technical decision should map to a business outcome the stakeholder cares about | Anti-pattern: building technically impressive solutions that nobody uses

Presentation tier is stateless — user sessions managed via cookie-based authentication | Logic tier is where governor limits are enforced — it's the most critical architectural tier | Data tier is shared infrastructure — no org gets dedicated database resources | The key architectural constraint: you cannot bypass the Logic tier to access Data directly — no direct DB access for customers | External integrations must go through the Logic tier APIs, never direct DB connections

Platform Cache has a capacity limit per org — monitor usage to avoid evictions | Never cache sensitive PII in Platform Cache — it is not encrypted at rest | Always implement cache-aside pattern: check cache → if miss, query DB → store in cache | Cache invalidation strategy is the hardest part — stale cache data causes production bugs | Platform Cache is NOT a replacement for proper query optimization

Release notes publish 6+ weeks before go-live — architect must review | Deprecated API versions affect integrations — client integrations using old API versions break silently after retirement | Sandbox refresh timing matters: if your sandbox isn't refreshed to the latest release, UAT misses release-specific issues | Critical Updates can be turned on by admins or activated by Salesforce automatically on a deadline | Architect responsibility: maintain a release management calendar and review 'Before the Release' items

@future calls inherit NO limits from the caller — they start fresh | Batch Apex start() method is synchronous with tighter limits; execute() and finish() are async with relaxed limits | A chain of Queueable jobs each get a fresh governor context — this is why chaining is used to work around limits | The maximum stack depth for Queueable chaining is not officially documented but practically ~5 chains deep before platform instability | Batch Apex's scope size directly determines how many records each execute() processes — affects limit consumption

publishAfterCommit vs publishImmediately matters architecturally — publishImmediately fires even if the transaction rolls back | Platform Events do NOT participate in Salesforce transactions — a rolled-back DML does not roll back a published event | Event subscribers run in their own transaction with fresh limits | High-volume Platform Events (HVPEs) have no per-org volume limit vs standard Platform Events

Composite API reduces round trips — critical for mobile and high-latency integrations | If any sub-request fails and allOrNone=true, all sub-requests roll back | Reference IDs must be unique within a composite request | Cannot mix Composite and Bulk API — they solve different scale problems | Composite API counts against API call limits — 25 sub-requests = 25 API calls consumed

Salesforce best practice: Declarative First, Programmatic Second | Flow has nearly closed the gap with Apex for most use cases — complex branching, loops, record operations, subflows, callout actions | Apex is required when: complex business logic exceeds Flow capability, performance requires set/map operations, callouts need custom error handling, or bulk processing needs fine-grained control | Mixed architecture: Flow for orchestration, Apex for complex computation invoked from Flow via Invocable Actions

LimitException cannot be caught with a try-catch — it immediately terminates the transaction | Limits.getQueries() and Limits.getLimitQueries() let you check current usage programmatically | The System.Limits class is your architect's tool for monitoring limit consumption in code | Limits are per transaction, not per class or per method — all Apex in one transaction shares one limit pool | Exception to remember: @future and Queueable jobs that exceed limits fail silently unless Transaction Finalizers are used

CoE prevents org sprawl — multiple teams building on Salesforce without standards creates unmaintainable technical debt | Architecture Review Board (ARB): every new solution design reviewed against established patterns before build | Pattern Library: approved solutions for common problems (sharing model, integration patterns, naming conventions) | Release Calendar: all changes follow a defined deployment cadence — no ad-hoc production deployments | Capacity Management: monitor API usage, storage, governor limit trends before they become production incidents

Guest user context is a critical security consideration — misconfigured OWD or sharing rules can expose org data publicly via Experience Cloud | Experience Cloud runs on Salesforce's CDN infrastructure — static resources cached globally for performance | The guest user profile controls what unauthenticated visitors can see/do — architect this with least-privilege | Partner Community users have different license capabilities than Customer Community users — license architecture matters | Content Management System (CMS) in Experience Cloud separates content from code — enables non-developer content updates

SmartStore (offline storage) uses SQLite with AES-256 encryption — security architect must review offline data sensitivity | Mobile SDK handles OAuth token refresh automatically | The choice between native mobile and mobile LWC is often driven by offline requirements and IT MDM policies | Progressive Web App (PWA) is an emerging middle ground — browser-based with some offline capability via service workers

A query is selective if the filter returns <10% of total records for indexed fields, <33% for non-indexed | Skinny tables must be requested from Salesforce Support — not self-serve | Custom indexes cannot be created on long text fields, multi-select picklists, or encrypted fields | Owner ID and Record Type ID are automatically indexed | Divisions require careful planning — once enabled, they're difficult to remove

Big Object index fields are immutable — you cannot add/change index fields after creation without rebuilding | Async SOQL aggregates Big Object data into Custom Objects for reporting | Big Objects cannot be deleted from the UI — only via Async SOQL or the delete DML statement in Apex | The index definition order determines query capability — leading index fields must be in every query

External Objects have no record storage in Salesforce — data lives in the source system | Every query on an External Object makes a real-time HTTP call to the source OData endpoint — latency implications | External Objects do NOT support: Apex triggers, workflows, process builder, reports (limited), sharing rules | External Lookup: child in Salesforce, parent in External Object | Indirect Lookup: relates to a unique custom field instead of Salesforce record ID | Cross-Org Adapter: use Salesforce Connect to expose one Salesforce org's data in another

Monitor storage quarterly — not annually | ContentDocument (Files) often consumes more storage than record data | Attachments (legacy) and Files (ContentVersion) both count against File Storage | Archiving to Big Objects reduces data storage consumption | External File Storage via Files Connect keeps files in S3/SharePoint — counts against file storage only minimally | Custom reports on ContentDocument size can identify the biggest storage consumers

The 50,000 row limit per transaction (200M in Batch) is the most common architect constraint | SOQL FOR UPDATE acquires row locks — use cautiously in bulk operations | Relationship queries (parent-to-child) cannot exceed 20,000 child records in the subquery | Semi-joins and anti-joins (WHERE Id NOT IN (SELECT...)) can be more efficient than fetching IDs in Apex then using them in another query | SOQL injection is possible if dynamic SOQL is used with user-controlled input — architect must enforce String.escapeSingleQuotes()

Data Classification in Salesforce: mark fields as Public, Internal, Confidential, Restricted — drives retention policies | Right to erasure cannot be implemented with standard Salesforce delete (data is soft-deleted then purged after 15 days) — need anonymization for immediate compliance | Consent Management: standard Salesforce Individual object tracks consent by contact/lead | Shield Platform Encryption: encrypts data at rest — search, formulas, and reports on encrypted fields have limitations | Hyperforce region selection: EU customers can mandate EU data residency

Data Cloud is NOT the same as Salesforce CRM — it's a separate platform with a separate data model | Data Lake Objects (DLOs): raw ingested data | Data Model Objects (DMOs): standardized model based on Salesforce's global schema | Identity Resolution: Data Cloud's AI engine that merges duplicate profiles across sources | Data Actions: near-real-time writes from Data Cloud back to Salesforce CRM objects | Einstein features in Sales Cloud/Service Cloud can use Data Cloud segments for AI predictions

Share tables: Salesforce maintains implicit share tables (AccountShare, ContactShare, OpportunityShare) that record every user's access to every record — adding up to billions of rows in large orgs | OWD change triggers full sharing recalculation — should never be done in business hours for large orgs | Adding a new sharing rule for a single object can trigger partial recalculation for that object only | The deferSharing flag in Apex can temporarily skip sharing calc during bulk imports — re-enable after | Criteria-based sharing rules are more expensive than ownership-based rules

Custom Metadata is the MODERN choice — everything Custom Settings does, Custom Metadata does better except for user/profile-specific settings | Custom Settings list type enables user/profile-level settings — no Custom Metadata equivalent | Custom Labels only for UI strings and internationalization — NOT for business logic configuration | Custom Metadata can have lookup relationships to other Custom Metadata types | Custom Settings are not deployable — each org must configure them separately post-deployment

Standard indexed fields: Id, Name, OwnerId, RecordTypeId, CreatedDate, SystemModstamp, custom ExternalId fields | Non-selective filters: IS NULL, IS NOT NULL on large datasets, non-leading LIKE ('%value'), OR conditions that combine non-indexed fields, formulas in WHERE | The query optimizer logs (available via SOQL query plan in Developer Console) show whether an index is used | Adding LIMIT does NOT make a query selective — it limits rows returned but the scan still runs | For reports and list views, filters on indexed fields are essential for LDV performance

Retention policy per object is the architect's first deliverable | Hard delete via Bulk API bypasses 15-day recycle bin — irreversible | Archive during off-peak Scheduled Batch | Big Object archival near-zero storage cost

Never filter on formula fields in SOQL for LDV objects (>1M records) | Solution: Flow or Trigger stores formula value to a separate indexed Number field | Roll-up Summary fields cause parent record locking on high-volume child DML

SOSL for user-driven search — partial word matching | SOQL for programmatic filtering — exact values | SOSL cannot use WHERE clause | 20 SOSL limit per transaction vs 100 SOQL | Multi-object search is SOSL's unique capability

Creates automatic index on the field | Upsert is inherently idempotent — same External ID, same record, no duplicates | Relationship by External ID in Bulk API: reference parent by external key in child CSV | Case-sensitive — mismatched casing creates duplicates

Junction Object inherits sharing from BOTH parents — user must have access to both | Rollup Summary fields enabled from both sides | Multi-select picklist is an anti-pattern for anything requiring filtering, reporting, or relationship traversal

Profiles set the MINIMUM — Permission Sets only ADD permissions, never restrict | OWD sets the MAXIMUM restriction — sharing rules can only OPEN access, never restrict | FLS in Apex: use WITH SECURITY_ENFORCED or Schema.describeSObjectResult() to enforce FLS in Apex code | @without sharing bypasses record security but NOT FLS | Shield encryption impacts: search, formulas, reports on encrypted fields have limitations

Share tables are automatically updated when sharing rules change (recalculation), ownership changes, or manual sharing is granted | @without sharing in Apex bypasses the Share table JOIN — runs as system, sees ALL records | @with sharing enforces Share table filtering (default for most contexts) | @inherited sharing inherits the sharing context from the calling code — use for reusable utility classes | The Share table JOIN is the source of LDV performance issues on objects with complex sharing rules

Two encryption modes: Probabilistic (stronger, no SOQL filter) and Deterministic (weaker, allows exact SOQL match) | BYOK (Bring Your Own Key): customer manages the KEK, Salesforce manages the DEK — compromise of the KEK doesn't expose data without both | Shield is additive — must be enabled per field per object | Search (SOSL) is supported for deterministic encryption only | Rotating encryption keys is a scheduled operation — not instantaneous

Implicit sharing is invisible in the UI — it doesn't appear in sharing rules or manual sharing lists | Account OWD Private doesn't prevent the Account owner from seeing related Contacts (implicit sharing) | Portal implicit: community user sees their own Account's Cases even without explicit Case sharing — this is portal implicit sharing | Implicit sharing cannot be disabled or overridden | Territory Management adds another implicit sharing layer on top of the standard model | Guest user implicit sharing: guest users in Experience Cloud have implicit access to public group shared records

JWT Bearer requires a pre-authorized Connected App with digital certificate — the integration user approves once, then tokens issue without user interaction | Named Credentials abstract OAuth from code — the architect should prefer them over hardcoded OAuth logic | Client Credentials flow (Spring 2023+) is replacing JWT Bearer for machine-to-machine — simpler setup | Refresh token rotation: best practice is to implement refresh token renewal rather than re-authentication on every call | Connected App OAuth policies: IP relaxation, refresh token validity, and permitted users all have security architecture implications

Territory 2.0 operates as an additional sharing mechanism — it doesn't replace Role Hierarchy | An Account assigned to a Territory is shared to all users in that Territory AND all users above them in the Territory hierarchy | Territory rules can auto-assign Accounts based on criteria (revenue, industry, geography) | Territories affect Opportunity sharing: Enable Territory Forecasts to include territory-based Opp access in forecasting | Mixed model risk: users with both Territory and Role Hierarchy access may see more records than intended — audit regularly

@without sharing is a privilege escalation — treat it as such in code reviews | If misused in a visualforce page or API endpoint, a user with no record access can be elevated to see all records | @inherited sharing is the safer default for utility classes — they behave appropriately in both user and system contexts | FLS is NEVER bypassed by @without sharing — field-level restrictions still apply | Audit: regularly search your codebase for @without sharing usage and verify each is justified

CORS whitelist: required for any external web app making REST/Connect API calls to Salesforce from the browser | CSP Trusted Sites: required for LWC components loading external JavaScript, CSS, fonts, or frames | Lightning Locker Service also implements namespace isolation within Salesforce — one LWC component cannot access another namespace's DOM | CSP violations appear as browser console errors — often missed during development if testing without CSP enforcement | Static resources (uploaded JS libraries) bypass external CSP restrictions — prefer this for third-party JS in LWC

Admin-approved users only: only users with the Connected App listed in their Profile/PermSet can authenticate — prevents unauthorized OAuth access | OAuth scopes: never grant 'Full' scope to integration Connected Apps — use 'api', 'refresh_token', specific object scopes | IP relaxation: 'Relax IP restrictions' is a security risk — avoid it; use token-based authentication instead | Refresh token expiry: short-lived refresh tokens force re-authentication — balance security with usability | Mobile SDK Connected Apps: separate from web integration apps — configure mobile-specific policies

Just-in-Time (JIT) Provisioning: SAML assertion can auto-create Salesforce users on first login — eliminates manual user provisioning | MyDomain is required for SSO — enables SP-initiated SSO and custom login branding | SAML attribute mapping: IdP attributes (email, department) map to Salesforce user fields | SP-initiated vs IdP-initiated SSO: SP-initiated (user goes to Salesforce first, redirected to IdP) vs IdP-initiated (user goes to IdP portal, clicks Salesforce app) | Certificate expiry: SAML signing certificates expire — architect must establish renewal monitoring

External OWD is SEPARATE from internal OWD — architect this explicitly | Sharing Sets are the community-specific sharing mechanism | Data leakage risk: too-open external OWD lets partners see each other's records | Quarterly audit of external OWD and Sharing Set configurations

Must happen BEFORE developers access the sandbox | Email→random@fake.com, Phone→000-000-0000, Name→Test User [ID] | GDPR, HIPAA, PCI-DSS all require PII masking in non-production | Salesforce Data Mask configures masking rules applied automatically on sandbox refresh

Requires a custom RowCause (Sharing Reason) created in Setup first | Persists through ownership transfers — manual sharing does not | @without sharing bypasses sharing entirely — different from explicit sharing | insert AccountShare records with custom RowCause in Apex

@without sharing bypasses record security but NOT FLS | WITH USER_MODE is the modern complete solution | FLS enforcement mandatory for AppExchange security review | Security.stripInaccessible() preferred for API endpoints — graceful degradation vs exception

Probabilistic: no SOQL filter, no formula, no rollup — maximum security | Deterministic: allows exact SOQL match — enables duplicate detection | BYOK (Bring Your Own Key): customer manages key encryption key | Key rotation is a scheduled operation — not instantaneous | Shield encryption does NOT protect EAC (Einstein Activity Capture) data

Bulk API 2.0 improvements over 1.0: no XML, simpler batch management, automatic chunking | REST API Composite resource reduces round trips for related operations | SOAP API enterprise vs partner WSDL: enterprise is org-specific (strongly typed), partner is generic (weakly typed, one WSDL for all orgs) | Streaming API vs Platform Events: PushTopics are SOQL-based (deprecated direction), Platform Events are the modern architectural choice | API consumption counts: every sub-request in Composite API counts as one API call

publishAfterCommit (default): events fire only after the publishing transaction commits — consistent with DML outcomes | publishImmediately: fires regardless of transaction outcome — creates events for rolled-back operations | Idempotent subscribers are essential because at-least-once delivery means handling duplicates | ReplayId: every event has a ReplayId — subscribers can request replay from a specific ID after downtime | High-volume Platform Events (HVPEs): no per-org volume limit (vs standard Platform Events) | Dead letter queue: Salesforce does not provide a native DLQ — architects must implement their own via a Failed_Event__c custom object

Bulk API 2.0 Query jobs: extract records as CSV — useful for large data exports | PK Chunking is automatic in Bulk API 2.0 — splits large object queries into primary-key-based chunks | Hard delete operation: Bulk API can permanently delete records (bypasses recycle bin) — requires permission | Failed records file: Bulk API 2.0 provides a separate CSV of failed records with error messages — process these separately | Bulk API uses a separate server infrastructure — doesn't count toward synchronous API governor limits

External ID field: define a field as External ID — the upsert operation automatically deduplicates | Idempotency key in Platform Events: include a UUID from the source in every event, subscriber checks if this UUID has been processed before | Salesforce Duplicate Rules: last-resort protection — they don't replace idempotent design | REST API upsert endpoint: PATCH /sobjects/Account/ExternalId__c/{value} is inherently idempotent | Saga pattern for distributed transactions: each step is idempotent, with compensating transactions for failure

Loop prevention is the #1 failure mode in bidirectional sync | System of Record (SoR) designation: which system owns which field — Salesforce owns sales fields, SAP owns financial fields | Change Data Capture from Salesforce can replace Platform Events for SAP notification — lower implementation cost | MuleSoft as middleware provides transformation, error handling, and retry logic — preferred over point-to-point | Field-level sync: don't sync ALL fields bidirectionally — only sync fields that SAP and Salesforce both need to see

Named Credentials enforce Remote Site Settings automatically — no separate whitelist needed | External Credentials (Spring 2023+): new model that separates authentication from endpoint definition — supports per-user or per-org credential sets | Legacy Named Credentials: single credential per named credential (org-wide) | Per-user Named Credentials: different OAuth tokens per user — enables user-context integrations | Credentials stored in Named Credentials cannot be accessed by Apex — only referenced via callout: prefix | Change management: rotating credentials only requires Named Credential update, not code deployment

Composite Graph vs Composite: Composite = one sequential chain; Composite Graph = multiple parallel trees in one call | 500 sub-request limit makes Composite Graph suitable for moderate bulk scenarios | allOrNone behavior: if any graph fails, all graphs in the request fail (atomic) | Composite Graph is ideal for: creating multiple independent records sets in one API call (e.g., creating 10 customer-with-contact pairs in one request) | Not suitable for true bulk operations — use Bulk API 2.0 for 10K+ records

CDC publishes ONLY changed fields — full record not included unless all fields changed | ChangeType header: CREATE, UPDATE, DELETE, UNDELETE — subscribers must handle all four | Gap events: if the subscriber's last processed ReplayId is older than 72 hours, a gap event is delivered indicating missed events | CDC is ideal for data replication patterns — replicate Salesforce data to a data warehouse, data lake, or external cache | CDC with Apex trigger subscriber: @isTest cannot test CDC events natively — use Test.getEventBus().deliver()

API limit = 1,000 + (200 per license) for most orgs | Monitor via: Setup > System Overview, or the REST endpoint /limits | Polling anti-pattern: checking Salesforce for updates every N minutes consumes API calls even when nothing changed — replace with CDC or Platform Events | Exponential backoff: when hitting rate limits, retry with increasing delays — don't hammer the API | External system API caching: cache Salesforce data in the external system to reduce read calls | Salesforce's API limit is per ORG, not per user — all integrations share the same pool

N systems: direct integration requires N×(N-1) connections; MuleSoft requires N connections to hub | MuleSoft as API-led connectivity: Experience APIs (channel-specific), Process APIs (orchestration), System APIs (backend CRUD) — three-layer architecture | MuleSoft is owned by Salesforce — native Salesforce connector with pre-built operations | For simple 2-system integration, MuleSoft adds unnecessary overhead — evaluate ROI | MuleSoft Accelerators: pre-built integration templates for common patterns (Salesforce-SAP, Salesforce-ServiceNow)

Workflow Rules being retired = Outbound Messages path is ending | 24-hour retry with exponential backoff | External system must respond 200 OK to acknowledge — idempotency in external system critical | Migration path: Outbound Message → Platform Event subscriber

Connect API pre-aggregates complex data: one call returns Chatter post with likes, comments, user details | Connect API for approvals: submit/approve/reject via REST — no custom Apex | Use REST for data operations; Connect for Salesforce feature access

Never process webhook payload synchronously — response must be immediate | HMAC signature verification authenticates the sender | External ID deduplication for idempotent retry handling | Error logging to custom Error_Log__c object

Version in endpoint URL: /services/data/v59.0/ | Retirement announced 9-12 months in advance | Test against current AND next version annually | Enterprise WSDL version-specific — regenerate on upgrade | Maintain a test suite running against both versions

Heroku justified by specific platform constraints — not as general Salesforce alternative | Heroku Connect uses Salesforce Bulk API + Streaming API internally | External Service from Flow: define OpenAPI spec, Flow invokes without code | Governor limits are the specific justification

Single POST to /services/data/vXX.0/graphql | Query Account + Contacts + Opportunities in ONE request | Not all Salesforce objects supported yet | Counts against API limits | Ideal for mobile with limited bandwidth constraints

Native S2S Connect is deprecated — use cross-org Salesforce Connect adapter | JWT Bearer token for org-to-org authentication | Define System of Record per data domain — which org owns which fields | Loop prevention: source_org__c flag same as bidirectional sync pattern

Scope 'full' grants everything — never use for integration apps | 'api' scope grants ALL REST API — prefer specific scopes | IP restriction 'Relax' is a security risk — enforce corporate IP ranges | Admin-approved users only is the enterprise standard

Per-user External Credentials: each user's own OAuth token to external system | Principal types: Named Principal (org-wide), Per-User (user-specific) | Callout syntax unchanged: callout:MyNamedCredential/endpoint works identically | Auth Provider defines OAuth flow — separate from credential storage

HTTP 429 = API limit exceeded — back off exponentially (1s, 2s, 4s, 8s) | Bulk API not counted against REST API limits — biggest architectural saving | Platform Events: zero polling API calls, events fire only when data changes | Circuit breaker: stop after N failures for M minutes

Simple Boolean flag: works for single-level recursion, fails for legitimate re-entry scenarios (e.g., different field changes) | ID Set pattern: more precise — skip only records already processed in this transaction | The fundamental fix: trigger should only run for relevant field changes (check Trigger.oldMap vs Trigger.newMap) — reduces unnecessary re-entry | Flow-trigger interaction: Flows can cause trigger re-entry too — the flag must cover both | Unit test for recursion: create a test that updates a record and verifies the trigger ran exactly once

Salesforce doesn't support distributed transactions (2-phase commit) — Saga is the architectural alternative | Compensating transactions must be idempotent — they may be called multiple times | Saga state machine: STARTED, STEP_1_COMPLETE, STEP_2_COMPLETE, FAILED, COMPENSATING, COMPENSATED | Transaction Finalizers in Queueable Apex: execute cleanup even when the Queueable fails with an unhandled exception — essential for Saga failure detection | Choreography vs Orchestration Saga: orchestration (one controller) is easier to reason about for Salesforce; choreography (event-driven) is more scalable but complex

5 concurrent batch jobs: most common org constraint for Apex automation | Flex Queue ordering: first-in-first-out by default, but FlexQueue.moveJobToFront() enables priority promotion | Scheduled Apex impacts: 100 scheduled Apex job limit per org includes Scheduled Apex not just Batch | Queueable jobs don't use the Flex Queue — they use a separate Async Job Queue | Monitor via Setup > Apex Jobs or AsyncApexJob SOQL queries | Chained Queueable jobs: each link executes asynchronously — no Flex Queue involvement

Before-save Flows are the performance-optimal choice for same-record field updates — prefer over after-save for this use case | After-save Flows for: creating child records, related object updates, Platform Event publishing, sending emails | Scheduled paths in after-save: 'When Opportunity stays in Negotiation for 7 days → send follow-up email' — powerful for time-based automation without Scheduled Apex | Before-save Flows run before validation rules in most contexts — verify behavior in your org version | Mixing before-save and after-save Flows on the same object requires careful order-of-execution planning

Without Transaction Finalizer: if a Queueable throws an unhandled exception, it fails silently — no notification, no status update, no retry | With Finalizer: guaranteed execution regardless of outcome — the Saga pattern's failure detection mechanism | FinalizerContext.getRequestId(): the Queueable job's unique ID for logging | Retry pattern: in the Finalizer, if status is ERROR, enqueue a new Queueable retry job (up to a retry limit stored in a custom field) | Finalizer itself must not throw unhandled exceptions — wrap in try-catch | Finalizer has its own governor limit context

SOQL inside a for loop = #1 bulk anti-pattern | Pre-query Map enables O(1) lookup inside loop | For volumes beyond trigger capability: delegate to Batch Apex via Platform Events | Trigger handler pattern: all logic in a separate Apex class

Savepoints cannot cross async boundaries — @future starts a new transaction | Platform Events with publishImmediately do NOT roll back when transaction rolls back — creates phantom events | Critical constraint: cannot make a callout AFTER DML in the same synchronous transaction

URL versioning in urlMapping is the API design practice | FLS enforcement: WITH SECURITY_ENFORCED or Security.stripInaccessible() required — endpoints are public attack surfaces | Return 200/201/400/404/500 appropriately | Input validation prevents injection attacks

Conflict type 1: Before Trigger sets field → Validation checks it → Flow sets same field differently → Validation runs again with new value | Conflict type 2: Workflow + Flow both send emails on same condition → duplicates sent | Principle: one automation tool per field prevents most conflicts

publishImmediately use case: audit logging of ATTEMPTED operations including failed ones | publishAfterCommit: subscriber can trust data is committed before processing | HVPEs require publishImmediately — no publishAfterCommit option | Subscriber runs in separate transaction 2-3 seconds after publish

Continuation timeout: up to 60 seconds — longer than standard synchronous Apex | Up to 3 parallel callouts in one Continuation object | UI-only pattern — not supported in Batch or Queueable | Callback method gets fresh governor limits

Custom Notifications API: 1,000 per hour per org limit | Platform Event in LWC: wire subscribes, component updates reactively in real-time | Consolidate multiple events into one notification — prevent notification fatigue | Mobile push requires Salesforce Mobile App installed

Before trigger: synchronous Observer modifying before commit | After trigger: synchronous Observer reacting post-commit | Platform Event subscriber: async Observer in separate transaction | New requirements = new Observers — existing automation untouched | Conflict risk: too many Observers on one event

Functions deprecation lesson: never build core business logic on beta/pilot features without an exit strategy | External compute via Heroku or AWS Lambda: same @future callout pattern as any external API | Salesforce has no on-platform unbounded compute alternative — governor limits remain the constraint

Platform Event: only built-in retry mechanism in Salesforce automation | Queueable Transaction Finalizer retry: enqueue new Queueable if error_count < MAX_RETRIES | Always log failures to Error_Log__c with jobType, recordId, errorMessage, retryCount | Dead letter pattern: after MAX_RETRIES, move to manual review queue

Scratch orgs are ephemeral (max 30 days) — designed to be created and destroyed, not used long-term | Source format vs metadata format: SFDX decomposes metadata into source format (one file per object field, for example) enabling meaningful Git diffs | Manifest-based deployment: package.xml specifies exactly what to deploy — more precise than Change Sets | CI/CD pipeline: Git push → automated tests → deploy to staging → approved deploy to production | SFDX doesn't eliminate sandboxes — integration testing still requires persistent sandbox environments

Unlocked packages (2GP): no namespace, no AppExchange requirement — used for enterprise org modularization | Managed 2GP: namespace required, for AppExchange ISV distribution | Package dependencies: Package A depends on Package B — version compatibility enforced at install time | Package version promotion: beta → released, can't promote without 75% test coverage | Deprecating 1GP: Salesforce has not officially deprecated 1GP but all new development best practice is 2GP

Branch strategy: feature branches → develop (CI) → release branch → main (production) | Metadata scope: use package.xml or project-based packaging to control what deploys — never deploy all metadata | Test execution: run specified tests for changed classes or run all tests — balance speed vs thoroughness | Destructive changes: deletions require a separate destructiveChanges.xml — often forgotten in CI/CD setup | Pre/post deployment scripts: data seeding, permission assignment — implement as SFDX scripts | Production deployment window: enforce change control — CI/CD doesn't mean uncontrolled production deployments

SFDX source format is a significant conflict reduction tool: custom-object.xml decomposed into individual field, validationRule, and layout files — two developers adding different fields to the same object no longer conflict | Trunk-based development: short-lived feature branches (<2 days) reduce conflict probability | Component ownership matrix: document which team owns which metadata components | Post-merge validation: after conflict resolution, always run a dry-run deploy to validate merged metadata is deployable | The worst conflicts: Profiles and Permission Sets — these are monolithic XML files that two developers frequently modify simultaneously

Feature flags (Custom Metadata): deploy new code but keep it disabled via configuration — enable only after validation, disable immediately if issues occur | Git tags on every production deployment: git tag -a v1.0.5 -m 'Production deployment Jan 5' — enables precise previous-version recovery | Quick action deployment: pre-staged rollback package ready to deploy — reduces rollback time from hours to minutes | Data rollback: if deployment changes data (DML in post-install script), a data rollback plan is required separately from metadata rollback | Partial deployment success: Salesforce deployments are all-or-nothing — if any component fails, nothing deploys | Test-only deployment (checkOnly) before actual deployment is the preventive architecture

Source tracking default in scratch orgs, opt-in for Developer sandboxes (Spring 2023+) | sf retrieve with no arguments: gets all tracked changes since last retrieve | Conflict detection when local and org diverge | Meaningful git diffs: each field is a separate file in source format — enables granular PR review

Full sandbox refresh: 24-48 hours — plan release cycles around this | Automate data masking immediately post-refresh | Hotfix process bypasses normal chain with CCB emergency approval | Document environment matrix with owners, refresh schedule, current release version

Custom Metadata feature flag: deploy code disabled, enable when validated | Dark launch: run new code on real data, compare results silently before enabling | Canary deployment: enable for 10% of users first (Rollout_Percentage__c field) | Instant disable without redeployment is the key capability

Promoted versions cannot be deleted — immutability guarantees | Package dependencies: version compatibility enforced at install time | Rollback: install previous package version | Subscriber upgrade: Salesforce migrates metadata on install | Semantic versioning: major = breaking changes, minor = new features, patch = bug fixes

75% coverage is the floor — enforce 85-90%+ | TestDataFactory: self-sufficient test data, no org data dependency | sf project deploy start --dry-run: validates deployment without executing — catches target org conflicts | Parallel test execution reduces pipeline time from hours to minutes

SeeAllData=true: passes in sandbox with data, fails in fresh scratch orgs — environment-dependent | @testSetup runs once per class — all methods share clean test data | Test.startTest()/stopTest(): new governor limits + processes async jobs | System.runAs() for sharing model and profile-based testing

Golden rule: if it's not in Git, it doesn't officially exist | Drift sources: admin changes QA directly; hotfix deployed without Git commit; sandbox refresh resets manual config | Remediation: retrieve drifted metadata, compare to Git, commit the correct version | Quarterly production audit comparing production metadata to main branch

Branch from production tag, not develop — critical to prevent deploying unreleased features | Absolute minimum change — no refactoring while in there | Rollback plan prepared BEFORE deployment | Post-mortem within 48 hours — root cause and prevention measures

SFDX source format: two teams adding different fields to same object no longer conflict in Git | Most conflict-prone: Profiles and Permission Sets — monolithic XML files | Component ownership matrix in Confluence: which team owns which metadata | Feature flags: multiple features deployed to Integration without activating prematurely

SOQL injection: PMD flags dynamic SOQL string concatenation without String.escapeSingleQuotes() | FLS: identifies Apex querying without WITH SECURITY_ENFORCED | Pipeline gate: sf scanner run --severity-threshold 2 fails CI on High severity | Custom PMD rules for org-specific naming conventions

Database.QueryLocator vs Database.Iterable: QueryLocator supports up to 50M records with cursor-based chunking; Iterable limited to 50K rows (SOQL limit) | Stateful Batch: implement Database.Stateful to maintain aggregate state across batch chunks (counts, totals) — without it each execute() is stateless | Batch Apex time limit: each execute() has 60 seconds CPU — complex logic per record must stay well within | Platform capacity: Salesforce's async infrastructure limits actual throughput — very large batches may run slower than expected | External processing: for transformations beyond Salesforce platform capability, stream data to Heroku or external compute

Cache key design: hierarchical keys prevent collision — 'Pricing.v1.Territory.NORTH' is safer than 'North' | Cache partitioning: separate cache partitions (Setup) for different functional areas — pricing, permissions, configuration | Cache miss handling: graceful degradation if cache is unavailable — fallback to SOQL | Cache invalidation: scheduled rebuild (Apex job), event-driven rebuild (Platform Event subscriber), or manual clear (admin action via custom UI) | Cache capacity monitoring: Apex.OrgCachePartition.getCapacity() — alert when >80% full to prevent evictions | Platform Cache is NOT shared between sandboxes and production

Non-selective filters: IS NULL / IS NOT NULL on large datasets, non-leading LIKE ('%value%'), OR conditions mixing indexed and non-indexed fields, formula fields in WHERE, non-indexed custom fields on objects with >1M records | Query Plan Tool (Developer Console): shows index usage before running — use in development for performance testing | The optimizer uses statistics: it estimates selectivity based on field value distribution — a WHERE Status__c = 'Active' where 90% of records are Active is non-selective even on an indexed field | Force index use: IN queries with small ID sets force index usage — can be more selective than range queries | SOQL subqueries (semi-joins): more selective than SOQL IN with Apex-collected IDs

Roll-up summary fields cause parent record locking — every child DML locks the parent | Anti-pattern: trigger on Order Line Item that updates Order total — 50 concurrent line item inserts = 50 threads trying to lock the same Order | Solution: Platform Event from each line item, single subscriber accumulates totals in batches | UNABLE_TO_LOCK_ROW in debug logs: the symptom of record contention | FOR UPDATE SOQL: explicitly locks records — use with caution, exposes lock duration to governor limits | Test for contention: load test with concurrent users, not sequential

Heap calculation: each String = 2 bytes per character; each sObject field = overhead per field + value size; 10,000 Accounts with Name, Email, Phone, Address = ~10MB — exceeds sync limit | Database.Stateful and heap: stateful Batch Apex accumulates heap across execute() calls — the stateful object itself counts against per-execute heap | Pattern: accumulate only primitive types (Map) in stateful batch, not full sObjects | Nullify: explicitly set large collections to null when done — Apex GC runs immediately | Limits.getHeapSize() / Limits.getLimitHeapSize(): monitor heap usage in code for debugging

Custom Metadata is deployable AND org-specific — ideal for environment-specific flag values | Cache the feature flag Custom Metadata in Platform Cache — avoid querying the flag on every transaction | Rollout percentage: for gradual rollouts, hash the user ID modulo 100 against the rollout percentage — deterministic, consistent per user | Profile-based flags: enable for specific profiles before org-wide rollout | Audit trail: Custom Metadata changes appear in Setup Audit Trail | Feature flag pattern also used for: A/B testing, canary releases, emergency kill switches for integrations

@AuraEnabled(cacheable=true): identical calls return from cache without server round-trip | Platform Cache: expensive SOQL runs once, serves from memory for subsequent calls | Lazy loading: related lists in tabs not visible on initial load | Browser network tab: primary diagnostic tool for page load issues

Request: Salesforce Support case with object name, field name, and query patterns | Compound indexes: two fields together — more selective than individual indexes | After creation: verify usage via SOQL Query Plan tool in Developer Console | 33% selectivity limit still applies even with index

Query Plan tool: Developer Console → Query Editor → Enable Query Plan | Cost < 1.0 = index used efficiently | NOT IN and != operators prevent index usage | IS NULL can use a null-safe index (Salesforce Support creates these) | Narrow date ranges are more selective than broad ranges

ContentDocument large files: single file can be hundreds of MB — file size policy needed | Draft ContentVersion accumulates — implement cleanup job | Files Connect: large files stored in SharePoint/S3, accessed via Salesforce UI | Salesforce emails at 90% — monitor at 80% proactively

Submission: POST to /services/data/vXX.0/async-queries with SOQL body | Monitor via GET on returned job URL | Result target: Custom Object — architect designs the result schema | Not all SOQL clauses supported | No JOIN across Big Objects and standard objects in single query

Loop with nested Get Records: 100 loop iterations = 100 SOQL queries | Flow SOQL accumulates with Apex in same transaction | Sub-flows run in same governor context as parent | Flow debug mode shows governor limit consumption — use it for performance analysis | Before-save Flows: no DML limits for triggering record (in-memory)

10 concurrent long-running request limit: entire org combined — all users share | Complex reports run simultaneously by many users is the common trigger | Apex callout timeout: slow external system holds a slot for up to 120 seconds | Lightning async report execution: complex reports show 'Processing' instead of waiting

API Limit monitoring by Connected App: Event Monitoring shows calls per Connected App — identify top consumers | Bulk API not counted against REST limits — biggest architectural reallocation | Platform Events: zero polling API consumption, events fire only on data changes | MuleSoft rate limiting: enforce partner quotas at middleware before Salesforce is hit

Summary reports: aggregate millions into group rows — 2K limit applies to grouping rows, not underlying records | CRM Analytics (CRMA): processes 100M+ row datasets | Report export to CSV: up to 200K rows | Batch pre-aggregation: no additional license, nightly job writes to Custom Object

Trigger → Domain (thin trigger calls Domain.onAfterInsert()) → Service (Domain calls Service for cross-object logic) → Selector (Service calls Selector for SOQL) | Unit testing: mock Selectors return fake data, test Domain and Service in isolation without SOQL | Application factory: Application.Selector.newInstance(Account.sObjectType) — enables mocking in tests | fflib is not a Salesforce standard — it's an open-source pattern. Architect must evaluate adoption cost vs benefit | Large orgs with many developers benefit most from fflib's enforced structure

Salesforce-to-Salesforce Connect (Salesforce Connect cross-org adapter): surface one org's data in another as External Objects — no data duplication | Connected App with JWT Bearer: org-to-org authentication | Cross-org reporting: Salesforce Reports cannot span orgs — external analytics (Tableau, Snowflake) needed | The cost of multi-org: 2× licensing, 2× administration, complex integration — often the wrong architectural choice | When to consolidate vs maintain multi-org: regulatory requirements and acquisition integration timelines are the two valid reasons to delay consolidation

Salesforce Trust (trust.salesforce.com): real-time Salesforce infrastructure status — architect must monitor this during incidents | Salesforce Backup & Restore (native): Salesforce's first-party backup solution — available as an add-on | Third-party backup: OwnBackup, Spanning, Veeam for more granular recovery options (record-level restore) | Metadata backup: Git is your metadata disaster recovery — all configuration in source control | RTO (Recovery Time Objective) and RPO (Recovery Point Objective): agree these with business before designing backup frequency | Undelete via Recycle Bin: records persist 15 days in recycle bin — first-line data recovery before backup restore

Technical debt scoring: assign debt severity (critical/high/medium/low) and remediation effort (high/medium/low) — prioritize high-severity, low-effort items first | Org scanner / Salesforce Code Analyzer: automated static analysis identifies common debt patterns | Workflow Rule migration: Salesforce has announced Workflow Rule retirement — mandatory migration to Flows | Technical debt backlog: maintain as explicit backlog items in the project management tool, not as 'known issues' | The business case for debt remediation: quantify the cost of maintaining debt (slower development, more bugs) vs remediation investment

The 'declarative first' principle scales to medium complexity — at enterprise scale, architect must set thresholds | Threshold examples: Flow with >50 elements → evaluate Apex; Flow with >3 decision branches on same field → evaluate Apex | Hybrid pattern: Flow orchestrates, Apex executes — best of both worlds | Enterprise governance: require architectural review for any Flow touching more than 2 objects | Flow naming and version management: critical at enterprise scale with 100+ Flows — implement a naming convention standard

Org merge complexity increases with the acquired company's Salesforce footprint | Namespace conflicts: both orgs may have same field API names — requires remapping | Duplicate records: deduplication before migration critical | Interim integration via REST API or Platform Events during transition | Realistic timeline: large org merge = 12-24 months

Event Log Files: 30+ event types, daily logs via REST API download | Event Monitoring license required for most event types | ApexExecution event: CPU time and DML per transaction — identifies slow code | Page Load Time event: Lightning page render times per user | Alert at thresholds: API >85%, Apex exception rate >10/hr, P95 page load >4 seconds

LWC: interactive elements must be keyboard-accessible; ARIA labels on custom elements; focus management for modal dialogs | Color contrast: minimum 4.5:1 ratio for normal text | Screen reader testing: NVDA/JAWS on Windows, VoiceOver on Mac | axe DevTools browser extension for automated checks | ADA lawsuits against enterprise software increasing — legal requirement not nice-to-have

Shield encryption limitations: cannot encrypt fields in formulas, rollup summaries, or standard report filters (unless deterministic) | Shield Field Audit Trail: 10-year history vs standard 18-month | CASB: intercepts API traffic, enforces DLP policies across all SaaS platforms | Regulated industries: Shield for Salesforce-specific compliance; CASB for enterprise-wide DLP

Agent User profile: least-privilege — Read-only where possible, no Create/Delete without explicit justification | Data quality: AI output quality = Salesforce data quality — audit before go-live | Guardrails: define explicitly what topics and actions are out of scope for the agent | Human escalation: when agent confidence < threshold, create Case for human rep | Agentforce Actions: each Apex/Flow action needs explicit permission model review