The short answer: no, not compulsory — but for most changes, you should.
The longer answer depends on what you’re changing.
What you CAN change directly in production
Most declarative configuration:
- Custom fields and objects
- Page layouts, record types, compact layouts
- Validation rules
- Workflow rules, processes, flows
- Permission sets and profiles
- Email templates
- Reports, dashboards, list views
- Custom settings, custom metadata records
- Picklist values
- Page assignments, app definitions
An admin with the right permissions can build all of this directly in production. The platform doesn’t stop you.
What you CANNOT change directly in production
Apex code is restricted:
- You can’t write Apex classes or triggers in a production org through the UI’s Developer Console. The Setup page for Apex classes is read-only in production for non-test deployments.
- You can deploy Apex from a sandbox or via the CLI, with the 75% code coverage and all tests pass rules enforced.
This is by design. Apex changes can break the platform in real-time for real users; Salesforce wants tests to run before any Apex hits production.
You also can’t:
- Develop Lightning Web Components in production through the UI (the source isn’t editable directly; you deploy them).
- Develop Aura components (same as LWC).
- Edit existing managed package code (it’s locked).
Why “best practice” says sandbox-first anyway
Even for changes you could make in production, doing them in production is asking for trouble:
- No rollback. If a validation rule blocks live record saves, every user is affected immediately. There’s no Ctrl-Z.
- No testing in isolation. Sandbox lets you verify behaviour before real users see it.
- No code review. A peer can’t review a change you make in production.
- No version control. Production has no Git history.
- No coordination with code. Field changes that need Apex test updates can’t be batched if the field already lives in prod.
- Audit / compliance. Regulated industries usually require change-control evidence, which sandbox-first provides naturally.
When direct production changes are reasonable
- Emergency fixes — a typo in an email template, a wrong picklist value, an active validation rule that’s blocking saves. Sometimes you fix it in prod and back-port to sandbox.
- Tiny admin tweaks — adding a value to a picklist, fixing a label, adjusting a list view filter. The risk is low and the deployment overhead would dwarf the change.
- One-off admin chores — sharing rule adjustments, ownership transfers, user maintenance.
- Reports and dashboards — these are personal-productivity tools; let admins iterate live.
The judgement is risk vs ceremony. A 30-second list-view tweak doesn’t need a full sandbox-to-prod pipeline. A new flow that orchestrates the lead-handling process does.
The hybrid pattern most teams adopt
| Change | Path |
|---|---|
| Apex / LWC / Aura | Sandbox → deploy |
| New flow / process | Sandbox → deploy |
| New custom object | Sandbox → deploy |
| Permission set changes touching multiple users | Sandbox → deploy |
| New picklist value | Production (with PR if Git-tracked) |
| Email template tweak | Production |
| Validation rule fix during incident | Production, back-port immediately |
| Report / dashboard | Production |
What an interviewer wants
A nuanced answer: “It’s not compulsory for declarative changes — admins can configure production directly. But Apex code can’t be written directly in production; you have to deploy with at least 75% test coverage. As a best practice we build and test everything in a sandbox before production deploy, because production has no easy rollback. Small one-off admin changes are the practical exception.”
Verified against: Salesforce Help — Sandbox and Deployment Best Practices, Apex Developer Guide — Deploying Apex, Metadata API Developer Guide, Salesforce DX Developer Guide. Last reviewed 2026-05-17 for Spring ‘26 release.