I would like to deploy a bunch of objects from a sandbox to Production. However, I am not yet ready to give permission to the users to use these new objects. Therefore, I do not want to deploy profiles with the objects.

Is it possible for me to deploy the objects now, and then deploy the profiles at a later date ? Would that properly update the Production profiles, giving the users the necessary permission to the previously deployed objects ?

Every time I've deployed profiles it has been with components, so the Production profiles were updated with the setting for those components included. So, I didn't know if this type of approach would work as well. My guess is that it would work, but I just wanted to make sure.

4 Answers 4


No, you can not deploy profile settings separately (there are some exceptions for non-component oriented profile settings). You have deploy them along with the components whose permissions you're updating.

However, you can deploy components separately from the profile settings. Make sure you use change sets, since deploying with Eclipse defaults all permissions to open. Then later you can come back and deploy the profiles and components together. Since the second deployment will also include all the components, you'll want to take special care that you don't overwrite any changes you made to those components in production after the initial deployment.

  • Thanks Ralph. This really sucks. The reason I wanted to deploy the components before I was ready to grant access to the users was because I have a HUGE amount of components to deploy. Because of that I have to deploy them in phases or I will get errors since some objects are reliant upon others. So, I don't want the users to use them in the meantime. Including profiles in the deploy package also seems to slow down the deployment. So, I thought it would be great to deploy the components and then come back in the end and do the profiles. But it sounds like that won't work :-/
    – Zoom_v
    Commented Oct 31, 2013 at 22:03
  • ....because I didn't want to have to deploy the components for a second time with the profiles because I think that will take an enormous amount of time. I would have liked to just deploy the profiles and let them take care of all of the settings like that.
    – Zoom_v
    Commented Oct 31, 2013 at 22:06

Yes, you can deploy profiles separately. If you're deploying through Eclipse or Ant, you should be fine. If you're using Change Sets, you will run into problems because Change Sets only deploy the relevant portions of the Profile. What that means is that when you add a profile to a Change Set it only deploys the part of the profile that has to do with the other components.


  • Change Set has components for Custom_Object__c and Profile1
  • Profile1 will only have data for the permissions for Custom_Object__c and nothing else
  • You should be more assertive in your answer. You can, of course, deploy permissions with custom objects. Change sets work the same way-- either way, you have to include all deployed components and their profiles in order to deploy their permissions.
    – sfdcfox
    Commented Oct 31, 2013 at 19:05
  • Answer updated to take your advice.
    – Mike Chale
    Commented Oct 31, 2013 at 19:12
  • Yha, I know I can do it that way. I was hoping to also be able to do it in a way in which I could just essentially replace all of the profiles in the destination with profiles in a separate deployment after all the components had already been deployed. But that's not gonna work I guess. Gotta include both components and profiles together in order to get the corresponding settings right.
    – Zoom_v
    Commented Oct 31, 2013 at 22:14

The Metadata API and change sets both work in the exact same manner (one simply uses the UI, the other does not). By deploying custom fields, objects, tabs, and so on along with profiles, you will also copy the permissions for those objects for those profiles. If you deploy only objects, you will get no changes to security (and they will hidden by default without profiles). If you deploy only profiles, you will only affect permissions on the profile that do not relate to any other object (e.g. API Enabled or Export Reports).

By way of example, if you have 30 fields on an object, and you update 10 of those fields' security for 5 different profiles, you can select those ten fields for those 5 profiles, and you will copy the 50 appropriate security settings (Hidden, Read-Only, or Edit). The other 20 fields on the object, as well as any other profiles in the system other than the five named, will not be affected.

  • 3
    I'm not sure this is exactly true. With the Metadata API everything defaults to open perms, where as change sets default to closed perms. You're correct in that both are the same if including profile settings in the deployment. Commented Oct 31, 2013 at 21:27
  • 2
    I didn't know that that was the case. Thanks for heads up on that. For the record, it only occurs on creation, not when updating the field...
    – sfdcfox
    Commented Oct 31, 2013 at 21:41
  • Thanks for your input sfdcfox. It sounds like I'm gonna have to inevitably do a deployment with both the components and profiles. Some object are reliant upon others and so I have to do the deployment in phases. I would have liked to have just done a bunch of deployments for about 5 objects at a time, and then after all of them were done to come back and deploy all of the profiles by themselves. But I guess that's not gonna fly. That's too bad, would be a cool thing to be able to do.
    – Zoom_v
    Commented Oct 31, 2013 at 22:11

You should take a look at Copado Deployer appexchange app


it has a specific feature called "Full profiles" that allows you to deploy just the profiles but including all the permissions.

And of course you can use this app to deploy just your objects, and letter, just the profiles.

Kind regards.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .