Salesforce: lead to cash on a multi-tenant CRM

I would follow the publicly described Salesforce approach: one shared database and one application, with every row carrying an org ID and every query forced through a filter on it. Custom objects and fields are not real DDL; they are metadata rows describing how generic data columns map to each org's schema, plus pivot and index tables for fast lookups. Business logic like validation, flows and Apex is also metadata, compiled and cached per org. A runtime engine reads that metadata to build queries and screens. To stop noisy neighbours, I enforce per-transaction governor limits and per-org API allocations. This gives one upgrade path for everyone, cheap onboarding, and strong isolation, at the cost of a sophisticated query optimiser and strict limits on tenant code.

A web form or API call inserts a Lead. Validation, duplicate rules, triggers and assignment rules all run in that one database transaction, so the lead either saves fully or not at all. Scoring runs outside that save path and writes a score field later. Conversion is its own transaction: Account, Contact and Opportunity are created or merged atomically. Quoting and approvals are a series of user transactions with state held on the quote record. At Closed Won, the order and contract are created in the user's transaction. Billing and ERP are told through events published after commit, so they run in separate, asynchronous transactions. Service Cloud reads the same account and asset rows. I keep each boundary small and send cross-system work through events.

Isolation has to come from the platform, not from developers remembering to add a filter. Every shared table carries an org identifier. The platform's query layer turns SOQL into SQL and always adds the org predicate, and customers cannot write raw SQL, so there is no way around it. Indexes lead with the org ID, which also keeps one tenant's scans away from other tenants' data. Caches, search indexes, file storage and async queues are keyed or namespaced by org as well. On top of that I would add per-tenant encryption keys for sensitive fields, automated tests that try cross-org access, and audit logging. Defence in depth matters because a single missing predicate in any subsystem becomes a breach.

I use several layers. Per-transaction governor limits cap SOQL queries, DML statements, CPU time and heap, so no single request can run unbounded. Rolling 24-hour API request allocations cap integration traffic for each org. A concurrency limit on long-running synchronous requests stops one org from tying up the app server threads. Async work goes into queues with per-org fairness, so a huge batch job waits its turn instead of starving others. Under all this sit capacity planning, the ability to move an org to a different instance, and per-tenant monitoring, so operators can see who is consuming resources. The point of a limit is to make sure the cost of bad code lands on the org that wrote it.

A synchronous callout puts the ERP's latency and uptime inside the sales rep's save. If ERP is slow or down, the rep cannot close the deal, and a long-held transaction ties up shared platform resources. Publishing a platform event after commit separates the two. The order is saved, the event records the fact, and subscribers process it at their own pace with retries. This also allows one-to-many delivery, so billing, ERP and provisioning can each subscribe. The costs are eventual consistency and more work to operate: idempotent consumers, replay handling, dead-letter monitoring, and an order status field that shows whether downstream systems have confirmed. For a revenue workflow, that trade is worth making.

Each event carries a stable business key, such as the order ID plus a version, and the consumer upserts on an external ID. If the event is delivered twice, the second write does nothing new. The subscriber stores the last replay ID it processed and resumes from it after a restart. That works within the event bus's retention window, which is 72 hours for high-volume platform events. If an outage lasts longer than that, I need a reconciliation job that queries orders changed since a watermark and re-syncs them. Failures that will not succeed on retry go to an error queue with alerts, and the Salesforce order shows a sync status so people can see what is stuck.

Salesforce describes the Trust Layer as a gateway between org data and models. Grounding pulls only the records the running user is allowed to see, using normal sharing and field-level security. Sensitive values such as personal identifiers can be masked before the prompt leaves, and put back into the response afterwards. External model providers operate under zero data retention, meaning prompts and outputs are not stored or used for training by them. The layer also screens for prompt injection and toxicity, and writes an audit trail of prompts, responses and feedback. As a designer, I would still limit agent actions to least privilege, because masking does not fix an over-permissioned action.

Governor limits exist because tenants share CPU, memory and database capacity, so the platform caps what one transaction can consume: number of queries, DML statements, CPU time and heap. Without them one badly written trigger could slow thousands of other orgs. For lead routing, I bulkify everything: a trigger handles the full list of incoming leads, collects keys into sets, runs one query per object outside loops, and does one update at the end. I prefer declarative assignment rules or a record-triggered flow for simple cases. Anything slow, like calling an enrichment API, goes to queueable Apex or a Platform Event subscriber so the user transaction stays fast. Then I test with bulk data loads of hundreds of records, not a single form fill.

The publicly described practices combine several layers. First, API versioning: integrations and Apex classes pin a version, so behaviour changes do not silently apply to old code. Second, release previews: sandboxes are upgraded weeks before production, release notes are published, and customers regression-test their own flows and integrations. Third, critical changes that might break things are often shipped as release updates customers can enable early and test before enforcement. Internally, Salesforce runs customer-written Apex tests at scale against new releases to catch regressions, and deploys in staged waves by instance, with status on the trust site. Customers should own a release checklist: refresh sandbox, run tests, check AppExchange package compatibility, and brief users.

Define matching rules in metadata, such as fuzzy name plus exact email domain, and duplicate rules that either block or allow with an alert. The matching should use indexed or normalised keys, like a lower-cased email or a phone number in a standard format, so each check is a selective lookup and not a scan. The expensive comparisons should only run on a small candidate set. For the public form, I would usually allow the insert and flag the duplicate rather than block it, because losing a real lead costs more than merging later. A periodic batch job can do deeper cross-object fuzzy matching and merging. Bulk loads need the same rules to work on 200-record chunks without querying once per record.

Keep the routing logic declarative: one active lead assignment rule, or a Flow, that evaluates entries in order. For example, enterprise leads with high scores go to a named team queue, and other leads go by region. Assigning to queues lets reps pull work, and it avoids keeping a hard-coded rep list. For the SLA, a scheduled path fires a set number of hours after creation. If status is still New and the owner is still a queue, it reassigns the lead or alerts a manager. All logic must be bulk-safe so a 10,000-row import routes in chunks. Watch for ownership skew when one queue owns huge numbers of leads, and spread or archive old leads to avoid lock contention.

Conversion takes one lead and, in a single operation, creates or attaches to an Account, creates or matches a Contact, and optionally creates an Opportunity. Mapped custom lead fields copy across to the target objects. The lead is marked converted, which makes it read-only by default, and it stores the IDs of the resulting records. Because this runs in one transaction, a failing validation rule or trigger on any target object rolls the whole conversion back. That means you never get an orphaned account without its contact. When conversion runs programmatically in bulk, I check each result for errors and design it to be retried, matching existing accounts first so a retry does not create duplicates.

Prices come from versioned price books, and quote lines snapshot the price they used, so a later change in list price does not rewrite history. A rules layer applies bundles, volume tiers and constraints in a defined order. That way the same inputs always give the same total. Discounts above a threshold set an approval-required state. An approval process then routes the quote to the manager, then finance, based on discount depth or deal size. The quote is locked while it is pending. Every decision is written to an audit trail. Heavy pricing calculations should run without blocking the user's request where possible. The trade-off is flexibility against predictability, so I keep the rules data-driven and covered by tests.

I define escalation explicitly rather than trusting the model's judgement alone. Hard triggers include the customer asking for a person, legal or safety topics, billing disputes above a value, and actions the agent is not permitted to take. Soft triggers include low confidence, repeated failed answers, negative sentiment and loops in the conversation. On handoff, the agent passes a summary, the transcript and the case context through Omni-Channel to a skilled human, so the customer does not repeat themselves. I measure containment rate alongside customer satisfaction and wrongful-resolution samples. Optimising containment alone pushes the agent to keep customers it should release.

Apex runs in system mode by default, so custom code can see more than the user can. I declare classes with sharing so record-level sharing applies, and run queries in user mode with WITH USER_MODE, or use user-mode DML, so object and field permissions are enforced. Where I need flexibility, I use Security.stripInaccessible to remove fields the user cannot see before returning data. Any elevation of access should be a deliberate, small, reviewed piece of code without sharing. This matters more for AI actions, because an agent invoking an over-permissive method could expose data to a user, or put it into a prompt, that the user should not see.

Ownership skew means one user or queue owns a very large number of records. Salesforce guidance flags trouble beyond roughly 10,000. Changes to that owner, or to roles and sharing, force expensive sharing recalculations. Parent skew is similar: an account with more than about 10,000 children causes lock contention. Updating a child locks its parent, so parallel loads collide and fail with UNABLE_TO_LOCK_ROW. For lead routing, a single catch-all queue that owns millions of old leads makes sharing changes slow and increases contention. Fixes include spreading ownership across several queues or integration users, archiving or deleting stale leads, placing the owner outside the role hierarchy, and sorting bulk loads by parent ID.

On save, the platform runs, in order: before-save flows, before triggers, validation, duplicate rules, the save itself, after triggers, assignment rules, after-save flows, then commit, then post-commit work like emails and events published after commit. If a before trigger sets territory but an assignment rule later overwrites the owner, the two fight each other and the result looks random. Updates in after-save logic can also re-fire triggers and cause recursion. I keep one automation owner per object where possible, use before-save logic for field updates on the same record, guard against recursion, and document the order so admins and developers do not undo each other's work.

I would use Bulk API 2.0, which splits jobs into chunks and processes them asynchronously. Before loading, I decide which automation should run. Usually I bypass non-essential triggers and flows using a custom permission or setting checked in code, then run scoring and assignment afterwards in a batch. I load parent records first, sort children by parent ID to reduce lock contention, and use external IDs so retries upsert rather than duplicate. I validate a sample in a full sandbox first. I then monitor failed-row results and reprocess them. Finally, I re-enable the automation and run reconciliation counts against the source.

Inside a single transaction it is strongly consistent: lead insert with its validation and assignment, conversion creating account, contact and opportunity, and the order created at Closed Won. Everything after an event is eventually consistent: billing and ERP sync, provisioning, some search index updates, refreshed lead scores, analytics and rollups computed by async jobs. The design rule is that the user-facing source of truth is updated strongly, while derived or external views catch up. I expose that lag honestly, with a sync status on the order or a timestamp on the score. Reconciliation jobs then catch anything that never caught up.

A distributed transaction across Salesforce and billing is not practical, so I treat it as a saga. The order stays in Salesforce with a status of Pending Billing. The billing consumer publishes a result event back, success or a rejection with a reason. On rejection, the order moves to Billing Failed, a task or case goes to finance operations, and dependent steps like provisioning do not start. Problems that can be fixed, such as a missing tax ID, are corrected and the order is resubmitted idempotently. If the deal is truly invalid, a compensating step cancels the order or reopens the opportunity. Dashboards track orders stuck in intermediate states beyond a time threshold.

The model trains on that org's past leads, labelled by whether they converted, and uses lead fields and activity as features. It produces a score plus the top contributing factors, so reps can see why a lead ranks high. Because training data stays within the org, one customer's patterns never influence another customer's model. When an org lacks enough conversion history, Salesforce documents falling back to a global model built from anonymised data, until the org has enough of its own. Practically, I would refresh the score asynchronously, store it as a field so routing and list views can sort on it, and watch for drift, for example after a new product launch changes who converts.

The lead's campaign membership is the source of truth. When the lead converts, the new contact inherits the campaign member history, and the opportunity can carry a primary campaign source. Multi-touch attribution uses campaign influence, which links an opportunity to several campaigns its contacts touched. Mistakes that break attribution include deleting leads instead of converting them, creating contacts directly and skipping conversion, and merging duplicates carelessly. So I enforce conversion as the only path and keep campaign member status consistent. Reports should read from the opportunity's influence records, not from copied text fields.

Publish After Commit sends the event only if the surrounding transaction commits. If the transaction rolls back, no event goes out, so subscribers never see an order that does not exist. That is the correct choice for business facts like Closed Won. Publish Immediately sends the event right away, whether or not the transaction later fails. That is useful for logging or error events you want even when the transaction rolls back, for example recording that a save failed. The risk with Publish Immediately on business events is phantom messages that downstream systems act on. Publish After Commit can be delivered twice and arrives slightly later, so consumers still need to be idempotent.

Sales and service share the same Account, Contact, Asset, Order and Entitlement objects in the same org. When an order is fulfilled, assets or entitlements are created against the account. Support agents see those exact records, with no copy in a separate service database that could drift out of sync. A case links to the account and asset, so entitlement checks and SLAs follow from what the customer bought. The benefits are no sync jobs and one security model. The risks are that sales-side automation or a schema change can affect service users. So I coordinate changes across teams through shared release management and test both journeys in a sandbox.

Omni-Channel pushes work to available agents instead of having them pick from queues. With skills-based routing, a case needs certain skills, such as a language, a product or a level, and is offered to an agent who has them. Each agent has a capacity, and each work item consumes some of it, so a chat might weigh less than a complex case. Routing respects priority and how long items have been waiting. Failure modes include work sitting unrouted when no agent has the required skill mix, so I need fallback rules that relax skills after a timeout. Another is agents leaving their status as available while away. I monitor queue age and ensure skill rules are derived from reliable case fields.

The query optimiser uses statistics for each org and only uses an index when a filter is selective, meaning it matches a small enough share of rows. So I filter on indexed fields: IDs, external IDs, audit dates, or custom fields with requested indexes. I also avoid patterns that defeat indexes, such as leading wildcards, negative filters or comparisons to null on large objects. For very wide objects, skinny tables can serve frequent reports. I would add archiving so hot tables stay small, and check queries with the query plan tool. The multi-tenant twist is that data size and spread differ per org, so a query that is fast in one org can be slow in another.

During the preview window, Salesforce upgrades preview sandboxes several weeks before production. I keep a sandbox on the preview instance, refresh it before the window, and run the full regression: Apex tests, end-to-end tests for lead capture, conversion, quoting and order events, and integration smoke tests against ERP stubs. I read the release notes for features that switch on automatically and for retirements. I also check the trust site's maintenance calendar for my instance's dates. Managed package vendors test too. Anything that breaks gets a fix or a support case before production upgrades, so the release becomes a planned event rather than a surprise.

Partner code runs inside customer orgs, so a vulnerable package exposes every customer who installs it. Security review checks for issues such as injection, cross-site scripting, insecure storage of secrets, missing permission checks and unsafe external endpoints before a listing is approved. Namespaces give each managed package a unique prefix for its objects, fields and classes. That prevents naming collisions with customer customisations and other packages. It also lets the platform track ownership, apply package-level limits and protect the vendor's code. Review is not a one-time guarantee, so vendors also have to keep secure development practices across versions.

I state assumptions rather than quote real figures. Say 20,000 leads a day and a 10 percent conversion rate. That gives about 2,000 opportunities a day, and at a 25 percent win rate, about 500 orders a day. If each order triggers three subscribers (billing, ERP, provisioning) and each consumer makes two API calls back for status updates, that is about 3,000 calls a day. Orders are small, but lead capture and enrichment dominate. If enrichment calls an API per lead, that alone is 20,000 calls. I would check these numbers against the org's 24-hour API allocation and event delivery allocation, plan for a five times peak at campaign launches, and batch where possible.

Every request needs the org's object definitions, fields, validation rules and compiled automation. Reading those from the database every time would be far too slow. So I cache metadata per org, keyed by org ID and a metadata version. When an admin deploys a change, the version increments and the stale entries are invalidated. A multi-level cache works well: in-process for the hottest orgs, plus a shared distributed cache. Compiled code and parsed rules are cached the same way. The hard parts are invalidating every node consistently, and limiting how much cache any one huge org can consume, so it cannot push smaller tenants out.

The platform stops runaway code with governor limits. CPU time, DML statements and queries are capped per transaction, and the transaction rolls back when a limit is hit, so damage stays inside that org and that request. As the developer, I prevent it from happening in the first place. I use one trigger per object with a handler, add recursion guards, only act when the relevant fields have actually changed, and avoid flows and triggers updating each other back and forth. I also make sure tests cover bulk inserts of 200 or more records. In production, I watch Apex exception emails, flow error notifications and event logs, so a near-limit transaction is fixed before data growth pushes it over.

Customers are spread across instances, so status has to be reported per instance and per service, not only as one global green light. A public trust site shows live status, incident history and scheduled maintenance. Customers find their instance and can subscribe to updates. During an incident, I post early, update on a regular rhythm, and separate what is known from what is being investigated. Afterwards, I publish a root-cause summary. Internally, the same per-instance telemetry drives paging, so engineers and customers look at the same picture. Being open costs little and reduces the flood of support cases during an outage.

I would track business signals and technical signals together. On the business side: lead capture rate against form submissions, time from lead creation to first touch, how many leads breach the SLA, conversion rate, quotes waiting for approval, orders stuck in pending sync, and case backlog by queue. On the technical side: transactions that come close to governor limits, flow and Apex error rates, API usage against the daily allocation, event publish and delivery failures, and lag between the replay position and the newest event. Event Monitoring and audit trails help investigate who changed what. Alerts should fire on trends, such as a growing sync backlog, not only on hard failures.

1. AIt exceeded a per-transaction governor limit on queries or DMLCorrect answer
2. BWeb-to-Lead is disabled
3. CThe sharing model is set to Private
4. DThe org has run out of data storage

Why: Queries or DML inside a loop multiply with record count, so a bulk load quickly hits per-transaction governor limits; bulkifying the code fixes it.

1. A150
2. B200
3. C50
4. D100Correct answer

Why: Synchronous Apex allows 100 SOQL queries per transaction. Asynchronous Apex allows 200.

1. APublish On Rollback
2. BPublish Deferred
3. CPublish Immediately
4. DPublish After CommitCorrect answer

Why: Publish After Commit sends the event only after a successful commit, so a rolled-back order never produces an event.

1. AAudit logs are disabled
2. BMasked fields are deleted from the org
3. COrg data is never stored in Salesforce
4. DExternal model providers do not store prompts or outputs or use them for trainingCorrect answer

Why: Zero data retention is an agreement that third-party model providers will not keep or train on the prompt and response data.

1. ATwelve
2. BOne
3. CTwo
4. DThreeCorrect answer

Why: Salesforce publicly ships three seasonal releases a year: Spring, Summer and Winter, each preceded by a sandbox preview.

1. AA separate physical database per customer
2. BNew columns added to a shared table via DDL
3. CMetadata that maps to generic shared data storage, scoped by org IDCorrect answer
4. DSpreadsheets synced nightly

Why: Custom schema is stored as metadata and interpreted at runtime over shared, org-scoped storage, which avoids per-tenant DDL and allows one upgrade path for all tenants.

1. A200Correct answer
2. B2,000
3. C50
4. D100

Why: Triggers process records in chunks of up to 200, so a large load fires the trigger once per chunk.

1. A100
2. B150Correct answer
3. C200
4. D10,000

Why: The limit is 150 DML statements per transaction. Separately, the transaction can process up to 10,000 rows through DML.

1. ABy polling the trust site
2. BBy resending the original request
3. CBy re-querying all orders
4. DBy using the event's replay IDCorrect answer

Why: Each event has a replay ID. A subscriber can resume from the last ID it processed, as long as that event is still within the retention window.

1. Ainherited sharing
2. Bwith sharingCorrect answer
3. Cglobal
4. Dwithout sharing

Why: Declaring a class with sharing enforces sharing rules. Apex otherwise runs in system context.

1. AFOR VIEW
2. BWITH SYSTEM_MODE
3. CWITH SECURITY_ENFORCED_ALL
4. DWITH USER_MODECorrect answer

Why: WITH USER_MODE runs the query with the user's object, field and sharing permissions applied.

1. AINVALID_SESSION_ID
2. BREQUEST_LIMIT_EXCEEDED
3. CMIXED_DML_OPERATION
4. DUNABLE_TO_LOCK_ROWCorrect answer

Why: Updating a child record locks its parent, so concurrent updates under the same parent account collide and fail with lock errors.

1. AData maskingCorrect answer
2. BField history tracking
3. CSharing recalculation
4. DSkinny tables

Why: Data masking substitutes placeholders for identified sensitive data and restores the real values in the response.

1. AREST API single-record calls
2. BSOAP API create calls
3. CBulk API 2.0Correct answer
4. DStreaming API

Why: Bulk API 2.0 processes large datasets as asynchronous jobs and handles chunking automatically.

1. ASynchronous trigger
2. BVisualforce controller
3. CFuture method
4. DBatch ApexCorrect answer

Why: Batch Apex splits a large query into scoped chunks, each with its own governor limits.

1. AIt speeds up report rendering
2. BIt bypasses governor limits
3. CIt makes duplicate event deliveries idempotentCorrect answer
4. DIt encrypts the payload

Why: Upserting on a stable business key means a redelivered or retried event updates the same record instead of creating a duplicate.

1. AUnlimited
2. B100
3. C500Correct answer
4. D5,000

Why: Web-to-Lead captures up to 500 leads in 24 hours by default. Submissions beyond that are not created as leads and are reported to the default creator by email instead.

1. AOne per queue
2. BFive
3. CUnlimited
4. DOneCorrect answer

Why: Only one lead assignment rule can be active at a time, though it can contain many ordered rule entries.

1. A30 days
2. B24 hours
3. C72 hoursCorrect answer
4. D7 days

Why: High-volume platform events are kept for 72 hours. An outage longer than that needs a separate reconciliation process.

1. AIt is marked converted and becomes read-only by defaultCorrect answer
2. BIt becomes the Opportunity record
3. CIt stays fully editable and keeps being routed
4. DIt is deleted

Why: A converted lead is flagged as converted, stores links to the records it produced, and is read-only for normal users.

1. AMore than 10,000Correct answer
2. BMore than 1,000,000
3. CMore than 100 million
4. DMore than 1,000

Why: Ownership by a single user or queue beyond about 10,000 records makes sharing recalculations expensive and slows operations.

1. ADeveloper Pro
2. BPartial Copy
3. CFullCorrect answer
4. DDeveloper

Why: A Full sandbox copies all data and metadata, which makes it suitable for performance tests and full regression testing.

1. ATerritory management
2. BCase escalation rules
3. CRound-robin assignment
4. DSkills-based routingCorrect answer

Why: Skills-based routing matches the skills a work item needs with the skills assigned to available agents, within each agent's capacity.

1. A60,000 ms
2. B1,000 ms
3. C5,000 ms
4. D10,000 msCorrect answer

Why: Synchronous transactions get 10 seconds of CPU time. Asynchronous transactions get 60 seconds.

1. AAfter the commit
2. BOnly during lead conversion
3. CBefore any before-save flow
4. DAfter before triggers and validation rules, before the record is savedCorrect answer

Why: Duplicate rules run after before triggers and validation rules but before the record is written to the database.

1. ABulk API
2. BPub/Sub APICorrect answer
3. CMetadata API
4. DTooling API

Why: The Pub/Sub API uses gRPC to publish and subscribe to platform events and change data capture streams.

1. ACalling an external API after DML
2. BInserting more than 200 records
3. CChanging setup objects such as User and non-setup objects such as Account in the same transactionCorrect answer
4. DQuerying inside a loop

Why: Setup and non-setup objects cannot be changed together in one transaction because their sharing consequences would conflict.

1. AShield Platform EncryptionCorrect answer
2. BField history tracking
3. CLogin IP ranges
4. DSharing sets

Why: Shield Platform Encryption encrypts selected fields and files at rest, with key management options controlled by the tenant.

1. AScratch preview
2. BDeveloperCorrect answer
3. CPartial Copy
4. DFull

Why: Developer sandboxes copy configuration only and have small storage limits, so they suit isolated development and unit testing.

1. A12 MB
2. B64 MB
3. C1 MB
4. D6 MBCorrect answer

Why: The synchronous heap limit is 6 MB. The asynchronous limit is 12 MB.

1. A200
2. B500
3. C2,000Correct answer
4. D10,000

Why: The default batch scope is 200 records, and it can be set as high as 2,000.

1. ASeparate databases per package
2. BA unique namespace prefixCorrect answer
3. CRunning in a separate org
4. DEncrypting their metadata

Why: A namespace prefix makes each package's objects, fields and classes unique within any org that installs it.

1. AAn AppExchange review tier
2. BA lead scoring model
3. CSalesforce's infrastructure re-architected to run on public cloud providersCorrect answer
4. DA CPQ pricing engine

Why: Hyperforce moves Salesforce services onto public cloud infrastructure, which supports regional deployment and data residency needs.