Deploy Salesforce Objects Without Their Profile Permissions — Schema Now, Access Later
You've got a batch of new objects to move from sandbox to production, but you're not ready to give users access to them yet. The natural plan: deploy the objects now, deploy the permissions later. The natural worry: if you include profiles, do you grant access too early — or worse, overwrite production's profiles wholesale?
You can absolutely split it: deploy the objects with no profile in the package, and Salesforce's own default keeps every user's access at none until you deploy a profile later. The trick is doing it without the two traps that make people nervous.
Deploy the objects, leave the profile out
The simplest answer is the right one: deploy the objects without any profile. A Salesforce deployment only changes a profile if a profile is in the deployment. Ship just the objects (and their fields) and not a single profile setting moves on the target — the schema lands, and every user's access stays exactly as it was, which for brand-new objects means none. That's precisely the "deploy now, grant access later" state you wanted.
With mtdt.io that's just a selection: pick the objects, don't add a profile, deploy. Nothing grants access because nothing about access is in the package.
The real risk — and why leaving the profile out sidesteps it
Getting permissions wrong has a genuine failure mode, and it's the opposite of over-granting: a profile deploy can wipe the target. The Metadata API reads a profile as one all-or-nothing document, so pushing a profile that omits settings can clear them on the target — the mass-lockout story behind "never deploy the Admin profile." Change sets soften this by only deploying the portion of a profile tied to the components in the set, but then granting access later means reassembling components and profile fragments together and being careful not to overwrite production changes on the second pass.
Leaving the profile out of phase one sidesteps all of it: no profile is in the package, so nothing on any profile changes. And Salesforce defaults in your favor — deploy a new object or field with no field-level security and the platform falls back to the Minimum Access baseline, so the new metadata lands closed, not open. "No access yet" is the platform's own default, not something you have to engineer.
Grant access later — scoped, without overwriting the rest
When you're ready to turn access on, deploy the profile scoped to just those objects. mtdt.io builds the profile it deploys from the components in the same deployment — so it carries the object and field permissions for the objects you're granting and nothing else. Salesforce upserts each entry, so the permissions for everything you didn't include stay exactly as they are on the target profile. No wholesale overwrite, and no re-shipping your whole object set to do it.
One platform detail makes this work cleanly: a field's field-level security only applies when the field is in the same deployment. The objects and fields are already in production from phase one, so you simply re-include them alongside the profile in the grant-access deploy — they're a no-op for the schema, but they let the new permissions land. Everything stays scoped to what you picked. (The same scoping behind a safe profile deploy is covered in The Best Way to Deploy Profiles in Salesforce.)
Or grant access permission by permission
If you want even finer control over the grant-access step, mtdt.io can open the profile as a per-permission panel — every object permission, field permission, and tab visibility as its own row, the source value beside a target toggle. Turn on exactly the objects you're releasing and leave the rest untouched:
So a phased rollout becomes two deliberate deploys: the objects on their own when you build, then exactly the permissions you choose when you're ready to go live — neither one disturbing anything else on the target.
FAQ
Does deploying a new Salesforce object give users access to it automatically? No. A deployment only changes profile permissions if a profile is included in that deployment. Ship just the objects and fields with no profile, and Salesforce falls back to its Minimum Access baseline — new metadata lands closed, not open, so no user gets access until you deploy a profile that grants it.
Why is deploying a whole profile risky? The Metadata API treats a profile as one all-or-nothing document, so pushing a profile that omits certain settings can clear those settings on the target — the failure mode behind the advice to never deploy the Admin profile wholesale. Change sets soften this by only carrying the profile portion tied to components in the set, but reassembling components and profile fragments later still risks overwriting production changes.
How does mtdt.io grant access later without overwriting the rest of the target profile? mtdt.io builds the profile it deploys from the components already in that deployment, so it carries only the object and field permissions for the objects you're granting access to. Salesforce upserts each entry, so permissions for everything else on the target profile stay exactly as they were — no wholesale overwrite.
Do I need to re-deploy the objects themselves when granting access later? Yes, but only as a no-op: field-level security only applies when the field is included in the same deployment as the profile, so you re-include the objects and fields alongside the profile. They're already on the target from phase one, so this step doesn't change the schema — it just lets the new permissions land.
Can mtdt.io grant access at a finer level than "the whole object"? Yes. mtdt.io can open the profile as a per-permission panel, showing every object permission, field permission, and tab visibility as its own row with the source value beside a target toggle, so you can turn on exactly the permissions you want and leave the rest untouched.
Ship the schema now, grant access on your schedule
Let mtdt.io deploy your objects with no permissions attached, then grant access later with a profile scoped to just those objects — no whole-profile overwrite, no change-set reassembly, and nothing else on the target touched.
Log in to mtdt.io and deploy your objects.
Was this page helpful?
Let us know how we did