Deploying a Permission set for a Managed Package from Sandbox

WE have rolled out FinancialForce HCM, fka Vana HCM. In an rather conventional move, we did our development in a sandbox, and deployed our changes to production.

Most of the deployment was regular run-of-the-mill workflows, a few custom fields, and maybe a validation rule or two. Nothing worth writing about, until I tried deploying the permission sets.

FFHCM manages all permissions in a permission set. We had 3 permission sets to deploy, all of which were custom permission sets, but they referenced manage fields in managed objects.

I had no idea what I was in for. The FF folks came up w/ an interesting solution for deploying field and object permissions. These can be deployed in a data job, as these exist as data and metadata at the same time. I’m not sure how an update would work, but for the create it was quite straightforward. See the 3rd post on this success thread for details

That left me to migrate tab permissions, which cannot be done via dataloader/workbench. I tried using the metadata api to retrieve and deploy the permission set, and dug through this great post by Adam Torman, and finally figured it out.

Here is how.

  1. Create a package.xml file that looks like this, replacing VanaHCM_Worker_c with the object you are interested in.

As this references managed objects, you cannot use wildcards to pull all objects. You must include the API name, including the namespace prefix. I have left the actual object name in here, which is VanaHCM_Worker_c. You would need to include each object whose permissions and tabs you want to migrate separately.

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<types>
    <members>VanaHCM__Worker__c</members>
    <name>CustomObject</name>
</types>
<types>
    <members>VanaHCM__Worker__c</members>
    <name>CustomTab</name>
</types>
    <types>
        <members>Permission_set_1_api_name</members>
    <members>Permission_set_2_api_name</members>
        <name>PermissionSet</name>
    </types>
    <version>30.0</version>
</Package>

Use workbench to retrieve the metadata from the source instance by logging in and going to migration - retrieve, and clicking “choose file” for unpackaged manifest. Upload your package.xml file, and click next, then click “retrieve.” This will kick off a job which, when complete, will give you the option to “Download Zip File.” This file will have one main folder named “unpackaged”, within which you will find 3 folders and one file

retrieve_09S400000001Un5EAE.zip _002.png

You only need to deploy the permission sets, so you can delete the objects and tabs folder (as long as the environments are in sync. If you actually need to deploy fields, then leaving the objects folder should deploy & update fields, but I have not tested this scenario).

Then, go back to workbench, and login to the target organization. Go to migration - deploy. Click “choose file” and select the zip file you just retrieved (after deleting the objects and tabs folder from it).

Check the “allow missing files” checkbox (IMPORTANT), and click next, and voila, you will kick off a job to deploy the package to the target instance, with field, object, and tab permissions

 
42
Kudos
 
42
Kudos

Now read this

Preventing duplicate junction object records

Native dupe management only allows you to reference a single lookup field. So it cannot prevent duplicate junction object records. By using a (new in spring 20) before save flow to concatenate the two IDs into a single text field, you... Continue →