function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

How to deploy profiles using ANT tool ?


I have made changes in the setting of  Profiles ->Object Settings -> Object -> Record Types and Page Layout Assignments

In order to do migration using ANT which all components need to migrate ? or if i migrate only profiles will work ?
Rahul KumarRahul Kumar (Salesforce Developers) 
Hi Nils,
  • The easiest way to migrate the permissions assigned to a profile from one Sandbox to another is to use Change Sets.
  • You can create a change set (Setup - Outbound Change Sets) with the new fields and other metadata you are wanting to move the permissions of as components, then associate the profiles you want to have the same the permissions of the metadata included migrated to the other Sandbox.
  • Then when you deploy the change set in your new Sandbox, the permissions of the components migrate for the associated profiles.
Please refer the below link for reference. Hope it will be helpful.

Please mark it as best answer if the information is informative.

Rahul Kumar
NagendraNagendra (Salesforce Developers) 

What are Profiles?
Profiles define how users access objects and data and what they can do within an application. In other words, a profile is a group or collection of settings and permissions that define what a user can do in Salesforce.
A profile controls at least a dozen different types of components. These include object permissions, field permissions, user permissions, tab settings, app settings, Apex class access, Visualforce page access, page layouts, record types, login hours, and login IP ranges. A profile is a junction object between many different declarative components.

Looking further under the hood, the profile manages a lot of detailed settings on these components:

For each object in your org, there are six bits of permissions that govern the access to an object: Read, Create, Edit, Delete, View All, and Modify All.
For each field in the object, there are two bits of permissions: Visible and Read-only.

Each Visualforce page or Apex Class is a permission bit.
There are approximately 150 user and administrative permissions to manage on top of it.

All this without even considering settings like record types or layouts.

What makes Profile Migration Difficult?
Profiles are large monolithic structures that often fail to install during the deployment process. The failures happen because of two primary reasons:
components referenced in the profile definition are not found in the target org user, administrative, or org settings in the target org are different from those in the source org

The first reason listed above is the predominant cause for the profile migration problems. We will use an example to understand this better.

Scale of the Problem
Let’s consider the example of a small to a mid-sized application. Assume it has 150 custom objects, each with 30 fields, 200 Visualforce pages, and 300 Apex Classes. That translates to more than ten thousand settings for just one single profile definition. If you have 100 profiles defined in your organization, this quickly adds up to over a million settings that need to be managed for this application. That is a staggering amount of information that developers have to deal with!

These profile settings get automatically modified on the creation or update of these components.

Consider the scenario where a developer creates 5 new objects for the application in the Developer org. This will immediately result in changing all the profiles as they will have dependencies on these 5 newly created objects. Now the developer chooses to ship only 2 of these objects as they are deemed ready for release, while the other objects remain as experimental or in-progress development. The developer creates a deployment patch with these objects and deploys to another test organization. This deployment will fail because the profiles have dependencies on the 3 experimental objects that were not included for deployment.

The developer needs to manually keep track of all the changes made to the developer organization. The changes made by different components have a different footprint in the profiles. The developer needs to be an expert to keep track of these modifications happening automatically in the background to later undo in the profiles. In the example above, the developer will have to make twenty thousand changes in the profiles to make a successful deployment!

Time Intensive and Painfully Iterative Process
If the developer fails to track and undo all the changes that will result in failure, the Metadata APIs will give one error at a time rather than all the errors in one shot. In other words, the developer will have to deploy the changes several times to uncover and fix the failures one painful error at a time.

Security and Governance Impact
As stated earlier, profiles define how users access objects and data and what they can do within a Salesforce application. Manually modifying and tweaking the profiles is a governance and security hazard. A developer can easily compromise security and access by either reducing the access or, even worse, silently giving more access than needed.

In a Nutshell
Not an easy or fun job to manage, is it?
Developers have to wade through millions of these profile settings manually. There are security issues to contend with. Besides gritting their teeth and hunkering down this painful path, release after release, what is a developer to do?

It is little wonder that many a customer has chosen to do profile migration by hand in the production organization!

Help is Here with Intelligent Profile Deployment
Using Intelligent Profile Deployment, it automatically figures out the changes that need to be deployed and ignores the rest of the changes.

The Solution
Intelligent Profile Deployment removes — from the profiles and permission sets — those dependencies that are neither available in the target org nor will be deployed as part of the deployment manifest.

Let’s consider a target org that has 50 custom objects. A deployment patch with 5 new custom objects is to be deployed to this. In addition, assume that the source profile references 70 custom objects. Intelligent Profile Deployment will automatically remove the reference to the 15 custom objects which are missing from the target org or the deployment patch.

In the above example, assume that the developer wants to deploy only 2 out of the 5 new custom objects developed. Intelligent Profile Deployment will automatically recreate the profile definition at runtime such that the dependencies of those 3 objects not included in the deployment manifest are removed.

No manual editing of profiles and permission sets, no laborious, iterative runs to find and fix errors, no security compromises. Intelligent Profile Deployment makes deployment a breeze!

The solution automatically edits the permission settings for a comprehensive list of components:
Apex Classes
Apex Pages
Custom Fields
Object Permissions
Field Permissions
Record Type Visibilities
Record Types

For more information on the profiles deployment please check with below links. Hope this helps.

Please mark this as solved if it's resolved so that it gets removed from the unanswered queue which results in helping others who are emconutering a similar issue.