Salesforce Development Lifecycle and Deployment Interview Questions

I describe it as a chain, because the interview is really asking whether I own the whole lifecycle or only the deployment.

1. The change enters a single prioritised backlog with an owner and acceptance criteria, so there is one place work is ranked.
2. A developer takes a short-lived branch from the mainline and builds in an isolated environment — a scratch org or a Developer sandbox, depending on how much of the org's metadata is genuinely in source.
3. They commit, open a pull request, and automation runs static analysis and the Apex test suite against the branch. A human reviews the diff.
4. On merge, the mainline deploys automatically into an integration environment where the streams meet, and the functional and integration suites run.
5. The release branch is cut on the published cut-off date, and it goes to a production-like staging environment for user acceptance testing and a full deployment rehearsal including the manual pre- and post-deployment steps.
6. The release is validated against production ahead of the window, then quick-deployed inside it. Post-deployment steps run from the runbook.
7. After go-live there is a defined heightened-monitoring period, and any emergency fix follows the hotfix path with a mandatory back-merge.

The two things I emphasise are that the repository is the source of truth at every step, and that the runbook of manual steps is version-controlled and rehearsed rather than remembered.

I decide from constraints rather than preference, and I say so out loud, because the answer that impresses is the one that names the trade-off.

The drivers that push towards iterative delivery are requirements that will change as users see working software, a business that can give the team regular attention, and value that can be released incrementally. The drivers that push towards a formal, gated approach are externally fixed scope, a regulator or auditor who needs traceability from an approved requirement to a delivered component, fixed-price contracting, and dependencies on other programmes with immovable dates.

Most large Salesforce programmes end up hybrid: the scope is baselined and approved once, the build and test happen iteratively inside that baseline, and changes to the baseline go through change control. I would rather say that plainly than pretend a regulated insurer can run pure Scrum.

I also raise team maturity, because it is the constraint people skip. A team with no source control, no automated tests and no product owner will not succeed with two-week sprints, whatever the contract says.

Application lifecycle management is the full span of a change: how it is proposed, prioritised, designed, built, tested, released, operated and eventually retired. DevOps is a narrower set of practices and cultural expectations concerned with shortening the loop between building and running — automation, source control, continuous integration and delivery, shared ownership of production.

The distinction matters because clients ask for DevOps and mean ALM. They have a delivery problem — unclear priorities, no environment strategy, no test discipline — and they have been told the answer is a pipeline. If I install a pipeline over that, I automate an ungoverned process and make the failures faster.

So my first move on a DevOps engagement is usually an ALM maturity assessment across people, process and technology, and my recommendation is sequenced by the weakest of the three rather than by what the tool vendor's demo showed.

I assign environments by purpose and then attach a refresh calendar to each, because an environment strategy without refresh dates drifts into a set of orgs nobody trusts.

• Per-stream development — Developer or Developer Pro sandboxes, or scratch orgs where the metadata is genuinely in source, one per developer or per feature so work is isolated.
• Integration — one shared environment where both streams merge and the integration suite runs. This is the first place either stream sees the other's work.
• Staging / UAT — production-like configuration and representative data, used for user acceptance testing, performance and data-volume testing where required, and for a full deployment rehearsal including the manual steps.
• Training — refreshed to a known, stable state before each cohort, so the environment does not shift under a course mid-week.
• Hotfix — matching what is live in production right now rather than what is in test, so an urgent fix does not inherit the risk of the in-flight release.

The constraint I plan around first is the Full sandbox refresh interval, because it is the longest of the four sandbox types and it dictates what the release calendar can assume. If the cadence is shorter than the interval, staging either becomes a Partial Copy sandbox with a template, or it is kept aligned between refreshes by deploying to it exactly as I deploy to production.

I also decide the masking approach at design time. Any copy of production data into a lower environment is a data protection decision, and it has to run as part of the refresh process rather than as something someone remembers to do.

Four types, distinguished by what they copy and how often they can be refreshed.

• Developer — configuration only, small data allowance, shortest refresh interval. The default for individual development work.
• Developer Pro — configuration only, a larger data allowance than Developer, same short refresh interval. Useful when a developer or a small test needs more seeded data than Developer allows.
• Partial Copy — configuration plus a sample of production data selected by a sandbox template, with a per-object record cap, and a medium refresh interval. This is the workhorse for integration testing and limited UAT.
• Full — a complete copy of production configuration and data, with the longest refresh interval. The only option for performance and data-volume testing, and the most production-like environment for rehearsal.

I choose by asking two questions: how much data fidelity does the activity genuinely need, and how often does this environment have to be reset? The second question is what eliminates Full sandboxes from most roles — teams reach for Full because it is the most realistic, then discover the release calendar cannot wait for the refresh interval.

I always confirm the current storage limits and refresh intervals in Salesforce Help before writing them into a design, because the numbers are refined between releases and a design document that quotes them from memory ages badly.

It changes what I can promise rather than whether I can deliver. Without a Full sandbox I lose production-scale performance testing and the most faithful rehearsal environment, so I say that explicitly and then mitigate.

The substitute is a Partial Copy sandbox with a carefully designed sandbox template plus a scripted seeding process for anything the template cannot supply. That gives representative data and repeatability after every refresh, which covers integration testing and most of UAT.

For the gaps I would do three things. First, run data-volume testing against synthetically generated data at the scale that actually matters — usually one or two hot objects rather than the whole model. Second, treat the deployment rehearsal as a rehearsal of the runbook rather than of production scale, so at least the manual steps and their ordering are proven. Third, plan a longer heightened-monitoring period after go-live and agree in advance what the recovery route is for the risks I could not test.

I would also put the cost of the residual risk in writing. If the client accepts it, that is a legitimate commercial decision; what is not legitimate is an architect who quietly drops performance testing and lets everyone assume it happened.

My default for a team on a scheduled release cadence is short-lived feature branches merged into a mainline through reviewed pull requests, a release branch cut per release so it can stabilise while development continues, and hotfix branches taken from the release tag and merged back into both the mainline and the release branch.

I would move to trunk-based development with feature flags if the team were genuinely doing continuous delivery — small changes, strong automated coverage, the ability to ship several times a week. Trunk-based development with weak test automation is just a single shared branch with a better name.

What would make me choose differently: how long features take relative to the release cadence, how much automated regression exists, how many teams touch the same metadata, and whether the org's release obligations require a stabilisation period. A team whose features take six weeks against a monthly release will suffer with any strategy until the features get smaller.

The two things I care about more than the strategy name are that branches are short-lived and that the back-merge from hotfixes is enforced. Long-lived branches guarantee a painful merge at the worst possible moment, and a hotfix that is not back-merged is a regression scheduled for the next release.

In an org-based model, the org is the unit of work: metadata is retrieved from and deployed to whole orgs, source control holds a representation of the org, and releases move sets of components. In a package-based model, the unit of work is a versioned package with declared dependencies, developed from source and installed into orgs.

I recommend org-based for the large legacy org with a decade of interdependent metadata and no clear module boundaries — which is most enterprise orgs. Putting that org under source control and deploying from the repository delivers most of the governance benefit immediately and does not require dependency boundaries that do not exist.

I recommend package-based when the boundaries are real: a greenfield build designed in modules, an ISV product, shared components that several orgs consume, or teams that genuinely need independent release cadences. Unlocked packages are the internal-modularisation option; managed packages are for commercial distribution with IP protection and a publisher-controlled upgrade path.

The honest middle path, and the one I most often recommend, is incremental: org-based under source control first, then extract genuinely self-contained areas into unlocked packages one at a time. The test for whether an area is ready is whether you can enumerate everything outside it that references it. If you cannot, it is not ready.

Scratch orgs are right when development is genuinely source-driven. The org's shape comes from a definition file, its metadata comes from the repository and its data comes from a seeding script, so it can be created and destroyed on demand. That makes them excellent for isolated feature work and for spinning up a clean environment per pull request in continuous integration.

They are the wrong choice when the org's metadata is not fully in source, because whatever is missing from the repository is simply absent from the scratch org and the developer discovers it the hard way. They are also wrong for user acceptance testing and for anything needing production-like configuration or data, because a scratch org is built rather than copied.

Two practical constraints I raise early: scratch orgs require a Dev Hub and consume its allocation, and they are ephemeral by design with a maximum lifespan, so nothing that matters can live only in one.

In practice I usually end up with a mixed strategy — scratch orgs for feature development and CI, sandboxes for integration, UAT and staging — and I would rather defend that than claim an org is more source-driven than it is.

The technical limitations are specific enough to list, which is what makes the case land: change sets are manual, so they are assembled by hand for every target org; they are additive only and cannot delete components; they cannot be version-controlled, reviewed as a diff, or automated; and they only work between orgs in the same deployment lineage, so they cannot reach a customer org or a separate production org.

I make the case with consequences rather than features. Manual assembly means the release that passed in staging is not provably the same release that went to production. No deletions means an ever-growing tail of obsolete metadata and a manual checklist. No version control means no answer to "what changed and who approved it", which is the question governance forums actually ask.

I would not propose ripping them out on day one. I would make the pipeline the default path, keep change sets available for genuine emergencies, and impose one rule: anything deployed by change set is reconciled back into the repository within a defined window. That keeps the source of truth true while the habit changes.

The Metadata API is the mechanism for retrieving and deploying configuration between orgs in bulk, driven by a package manifest. Change sets and essentially every deployment tool rest on it. It supports the great majority of declarative and programmatic metadata, and it supports destructive changes, which is what lets removals travel with a release.

The constraints that matter architecturally are that coverage is broad but not complete and changes every release; that some org-level feature enablement has to be done in Setup or requested from Salesforce; and that record data is never metadata, so anything held as records needs a separate mechanism.

I plan around this with a deployment runbook that lives in version control next to the code and is reviewed as part of the release. It has an explicit manual pre-deployment and post-deployment section, and I check it against the current Metadata API coverage documentation for each release rather than trusting last quarter's list.

I also distinguish it from the Tooling API in interviews, because they get conflated: you deploy with the Metadata API, and you develop against the Tooling API, which gives fine-grained interactive access to individual components for editors, debugging and test execution.

I split it deliberately into two categories and treat them differently.

Configuration that is part of the release — a lookup table the new code depends on, a rules matrix, a set of type codes — I model as custom metadata type records wherever the model allows, because those deploy with the metadata. That makes them versioned, reviewable in a pull request and consistent across environments, and it removes an entire class of release-day data loads.

Values that legitimately differ per environment — integration endpoints, feature switches that are off until go-live, credentials-adjacent settings — must be excluded from the deployment payload and set per environment through a documented, repeatable step. Hierarchy custom settings and per-environment custom metadata records are the usual homes. Named credentials handle the endpoint-and-authentication case properly.

The failure I am guarding against is a deployment overwriting a production endpoint with a sandbox one, which is a genuinely bad afternoon. The other is an inventory problem: I keep a version-controlled list of which environment-specific values exist and where they have to be set, without putting the secret values themselves in the repository.

Anything genuinely transactional stays data and is migrated with a data tool, with a plan for external IDs and record relationships.

I structure it by who is testing what, where, and against which exit criteria.

• Unit tests — Apex tests with meaningful assertions, covering the happy path, negative cases, bulk behaviour and different user permissions with System.runAs. Callouts mocked, data created in the test rather than queried.
• Static analysis and code review — run automatically on every pull request, so the mechanical problems never reach a human reviewer.
• Functional and integration testing — in the shared integration environment, covering declarative automation and the interfaces, which Apex tests do not reach.
• Automated regression — critical business journeys, run on every build and before every release. This is the investment that makes a frequent cadence possible.
• UAT — business users in a production-like environment, with agreed entry criteria, a defined scenario set, a severity model and acceptance criteria settled before the cycle starts.
• Performance and data-volume testing — where the requirement warrants it, in the most production-like environment available.
• Platform release regression — three times a year, in a sandbox on a preview instance during the preview window.

Underneath all of it sits a single test data strategy, including masking wherever data leaves production, because otherwise every environment ends up with a different definition of realistic.

Carefully, because the number is not wrong — it is being asked to mean something it cannot.

Coverage measures which lines executed while tests ran. It does not measure whether anything was verified. A test that invokes a method and asserts nothing raises coverage exactly as much as one that checks every output. So a high figure is consistent with both a well-tested codebase and a codebase full of assertion-free tests written to clear a deployment gate.

The second problem is scope. Most of a Salesforce release is not Apex. Flows, validation rules, sharing configuration, integrations and the user experience carry substantial risk that Apex coverage does not touch at all.

What I offer instead is a three-part assurance picture: assertion quality in the test suite, automated regression coverage of the critical business journeys, and the defect trend from the last few releases. I keep the coverage number in the pack — it is a platform requirement and a useful floor — but I stop it being the headline.

Three activities, all of them before the production upgrade rather than after it.

First, know the dates for your own instance, not a generic release date, and confirm which sandbox instances are designated preview instances for that release. Salesforce publishes both. Make sure a suitable sandbox is on a preview instance inside the preview window so there is somewhere to test on the new release while production is still on the old one.

Second, run risk-targeted regression there: the critical-path suite for broad breakage, plus focused testing wherever the release notes intersect the org's own customisations — changed behaviour on an object the code depends on, an altered default, a feature being retired.

Third, read the retirements and known issues. That is the part teams skip and the part that produces surprises, because a retirement is a deadline rather than a defect.

Around it I keep the release calendar clear: I do not schedule a major customer release into the same window as the platform upgrade, because when two things change at once, diagnosis time doubles. And I record the results by release name, since the same exercise runs three times a year and the previous pass tells me which areas are historically fragile.

A release train. A fixed, published cadence with a defined code-freeze, regression and go-live calendar; work that is ready by the cut-off joins the release and work that is not waits for the next departure; and a separate hotfix path so urgent production fixes never have to bypass the process.

The reason it works with multiple teams is that it decouples team progress from release scheduling. Nobody negotiates a date; the dates already exist. Because the cadence is frequent, missing one is a short wait rather than a crisis, which is what keeps teams honest about readiness.

Its credibility rests entirely on the cut-off being enforced. The first time an exception is made for a late feature, the cut-off stops being a date and becomes a negotiation, and within two releases you are back to per-feature scheduling.

Alongside it I want a release owner with authority, exit criteria agreed before the pressure arrives, a rehearsed recovery plan, and a merge calendar so the teams know when they are integrating rather than discovering it.

Managed — built in an org with a registered namespace, source protected, upgradeable by the publisher, and subject to restrictions on what can be changed or removed once released. Scenario: an ISV distributing through AppExchange that needs IP protection and a supported upgrade path to installed customers.

Unlocked — versioned and upgradeable, developed from source control, but the metadata remains visible and editable in the installed org. Scenario: an enterprise modularising its own org so teams own separate functional areas with independent version history, or sharing a common integration framework across several of its own production orgs.

Unmanaged — a one-time copy; components land as ordinary editable metadata with no namespace isolation and no upgrade path. Scenario: a consultancy handing a client a starter template the client will own outright and the consultancy will not maintain.

The mistake I watch for is choosing managed for an internal modularisation exercise. It locks the customer out of its own configuration and imposes ISV-shaped constraints for benefits — IP protection, publisher-controlled upgrades — that an internal team does not need.

Around one principle: an urgent fix must not have to inherit the risk of whatever is currently in test.

• A hotfix environment that matches what is live in production right now, not what is being regression-tested.
• A branch taken from the release tag that production is running, so the fix carries no unreleased work.
• A proportionate but real test pass — the fix itself plus the critical-path regression around it. "Urgent" is not a reason to deploy untested code, and it is usually the second incident of the day that comes from the fix.
• A named authoriser who can approve outside the normal calendar, agreed in advance so nobody is looking for them at 2am.
• A mandatory back-merge into the mainline and into the in-flight release branch, with a defined window and a visible list of outstanding retrofits.

The back-merge is where hotfix processes actually fail. Everything up to the production deployment happens under pressure and gets done; the merge happens after the pressure lifts and gets forgotten, and the next release quietly reverts the fix. I make it an exit criterion of the hotfix rather than a follow-up task.

I separate the technical remediation from the process conversation, and I do the technical part first.

Find them — Setup Audit Trail for the event record of what changed and by whom within its retention window, and a metadata comparison between production and the repository for the current-state difference, which catches anything the audit trail no longer holds.

Retrofit them — commit the changes into version control and apply them to the lower environments, so the source of truth and the environments match production again. Until that is done, the next release will silently overwrite whatever the business has come to depend on.

Then the process conversation, and I try to start it without blame. If the pipeline could not deliver an urgent change in an acceptable time, the administrator behaved rationally and the pipeline needs a governed emergency path. If the pipeline was fine and the process was simply bypassed, that is a different conversation — but I want to know which one I am having before I open it.

Longer term I want ongoing detection rather than discovery by accident: the audit trail reviewed on a cadence, and an automated production-versus-repository comparison that reports differences to the release owner with a defined action — every difference is either retrofitted or reverted, with the decision recorded.

A sandbox refresh is a development artefact. Its timing is governed by the sandbox refresh interval rather than by any recovery objective, and there is no supported way to selectively restore records from it into production with their relationships intact. It is a copy, not a restore capability.

A real strategy starts from two numbers the business owns, not the architect: the recovery point objective — how much data loss is tolerable — and the recovery time objective — how quickly the business must be operational again. Everything else follows from those.

Then the mechanism that meets them: Salesforce's own backup offering, the scheduled data export service, or a partner backup product, chosen on frequency, granularity of restore, and how it handles relationships and attachments. Metadata needs its own answer, which for most orgs is the version control repository, provided it is actually current.

And then the part that gets cut: a tested restore, on a realistic subset, with the elapsed time measured against the recovery time objective. Nobody has a backup until they have completed a restore. I would rather present a modest strategy that has been rehearsed than a comprehensive one that has not.

Centralised standards with federated delivery. Concretely, a Center of Excellence that owns platform-wide standards, reusable assets and the shared roadmap; an architecture review board that reviews significant designs against those standards; and local delivery teams that keep day-to-day autonomy inside them.

The critical design decision is what triggers review. Governance that reviews every change becomes a bottleneck, review quality falls because volume is high, and teams start splitting work to stay under the threshold. Governance that reviews nothing produces the divergence it was created to prevent. So I define risk tiers with a lightweight path for low-risk change and a real review for anything that crosses a boundary, touches shared components, introduces an integration or affects the security model.

I also want the framework to have something to give, not only something to withhold — reference architectures, a shared component library, a naming standard, an environment template. A body that only says no gets routed around.

And I want membership to include the business, not only IT. Prioritisation conflicts between business units are business decisions, and an architecture board cannot settle them on technical grounds.

Batch size falls, so several things that were survivable at two releases a year stop being survivable.

Testing is the binding constraint. A three-week manual regression pack consumes a monthly cycle. Automated regression across the critical business journeys is not optional at this cadence, and it is the largest single investment.

Environments have to support a shorter cycle: staging refreshed or aligned often enough to be trustworthy, which usually means confronting the Full sandbox refresh interval and either changing the environment type or keeping staging aligned by deploying to it exactly as to production.

Deployment has to be repeatable. Hand-assembled change sets do not survive twelve releases a year; the release has to be built from the repository so the artefact that passed staging is provably the artefact that ships.

Governance has to be right-sized. A review board that meets monthly and reviews everything becomes the release schedule. Risk tiering and pre-approved patterns are what let governance keep up.

The compensation I point out is that smaller releases are lower risk individually and much easier to diagnose. The cost is front-loaded — automation and environments — and the benefit accrues afterwards, which is exactly the shape of investment that needs a sponsor.

One source, many consumers, independent schedules. I extract the shared components — integration frameworks, audit logging, common utilities — into versioned packages built from a single shared repository, and each org installs and upgrades on its own release calendar.

That solves the problem the alternative creates. Copying from a nominated master org is manual and unversioned, so within two changes nobody can say which org has which version, and the four copies diverge into four different products with the same name.

Two governance additions make it stick. A named owner for the shared packages, with a defined intake route for change requests from the consuming orgs. And a supported version skew policy — how far behind an org may fall before it must upgrade — because without it you end up maintaining every historical version simultaneously, which is the divergence you started with.

I would also be honest about what this does not solve. Shared packages do not resolve genuine requirement conflicts between orgs; they surface them earlier, which is better but not free.

The case for a single org: one view of the customer, cross-business reporting without integration, reuse of configuration and process, one release calendar and one governance body, and lower licence and administration overhead per unit of function.

The case for multiple orgs: genuine process independence, regulatory or data residency separation, independent release cadences and autonomy, insulation from another unit's customisation risk, and relief from org-level limits and platform ceilings that a very large consolidated org can approach.

What decides it is usually the customer overlap. If the business units share customers and need to see them together, that is the strongest single argument for consolidation, and it is hard to replicate with integration. If they share no customers and operate under different regulators, most of the consolidation benefit disappears while all of the migration cost and governance conflict remains.

The trap I look out for is the mitigation that sounds cheap: "we will consolidate the data but keep the interfaces separate". That is achievable, but it converts an org strategy decision into a permanent sharing, profile and layout complexity that somebody maintains forever. I would rather price it honestly than let it be assumed away.

I work the incident before I work the cause.

1. Establish the blast radius — which users, which processes, is data being written incorrectly. Data corruption changes the decision, because it makes waiting expensive.
2. Stabilise — if there is a safe way to reduce exposure immediately, such as switching off a feature flag or deactivating a flow, take it while the decision is being made.
3. Take the recovery decision against the plan we prepared, not on the spot: forward fix or redeploy the previous version, per component, with the elapsed time of each route known in advance. Two hours in, with records already created against the new configuration, a forward fix is often faster and safer than a revert, because reverting metadata does not un-create data.
4. Communicate — the named authoriser makes the call, and the business is told what is happening and what to do in the meantime.

Afterwards, the review. Why did staging not catch it — a data fidelity gap, a missing manual step, an untested integration? And whichever it was, the fix goes into the process, not into a person's memory.

The point I would make to any panel is that all of this depends on the recovery plan having been written and rehearsed before go-live. Improvising a rollback at 4pm on release day is how a bad release becomes a bad week.