1

Need: I have a profile configured for the 'Salesforce Platform' license type, and need a version of it that works for the 'Salesforce' license (you can't clone a profile across license types using the UI)

Proposed Solution: I'd like to pull the (complete) XML for the Platform profile, change the <userLicense> tag from 'Salesforce Platform' to 'Salesforce', then deploy it to production as a new profile.

Attempted Process:

  1. To get the full set of permissions for a profile, and to deploy the new profile with all those permissions, I need to pull/deploy all metadata that relates to profile permissions: apex classes, VF pages, objects, field level security, etc.

  2. I used https://packagebuilder.herokuapp.com/ to build a package.xml of my Production org, including managed package metadata.

  3. I used SFDX CLI command sfdx force:mdapi:retrieve -r ./ -u Production -k ./package.xml to pull the metadata from my Production org, and hit the error The metadata retrieve operation failed: LIMIT_EXCEEDED: Too many files in retrieve call, limit is: 10000.

Question: The package.xml file for my full org has close to 30k metadata items in it, far beyond the 10k limit. How can I pull a profile with full info for the many classes/objects/fields/vf pages in my org, if it will exceed that limit?

  • 1
    Try cloning the profile from standard UI. Then retrieve the cloned profile (not all components, in package xml only mention profile name) then change the license and deploy. You might receive errors on features for which you need to update profile xml and deploy. – Kiran Machhewar Jun 25 '18 at 18:21
  • 1
    Unfortunately, attempting to change only the userlicense type returns the deployment error: Cannot update: userLicense. So it looks like I've got to stick with the original plan of making a new profile with the correct license type, and copying over the XML from the old profile. – smohyee Jun 25 '18 at 19:08
3

Disclaimer: I work for Gearset

You could try Gearset's free trial for this - we automatically batch requests behind the scenes when retrieving metadata, as as long as no individual type has more than 10k items then you should be okay. If you include profiles for retrieval, we'll make sure each batch includes profiles, and then we'll stitch all the different results together behind the scenes so you get each complete profile.

If you want to try it out, just head to https://gearset.com and sign up for a free 30-day trial (takes two clicks, and doesn't require any card details, don't need to install anything in your org, etc.). You can grab the metadata either by configuring a backup job and downloading the resulting package.zip, or just running a comparison from org -> empty (but initialized) git repo. If you want to grab absolutely everything, make sure to switch on all metadata types - by default we pick a subset of about 70, but you can turn on the rest with another click or two!

1

Honestly, this is one of the reasons why we're told to prefer the use of Permission Sets. By making your permissions modular, you'd have a much easier time exporting and migrating permissions like this. There's two basic ways I can think of to get all the data, neither of which are particularly pleasant.

Build Manual XML

You could conceptually write some Apex Code to query all the data and save the file somewhere. Thinks like FieldPermissions, ObjectPermissions, SetupEntityAccess, and PermissionSetLicense can all be queried in Apex, which you could then manually reconstruct the XML. I'm not going to write a script for this, as it's more of a theoretical concept than anything. I expect this to take 100-150 lines of code or so.

Use DX

This is what I'd do. Build a bunch of package.xml files, and force:mdapi:retrieve them into separate directories. Then, force:mdapi:convert into DX code; you can combine all the profile permissions into a single folder with a ton of files in it. Aftewards, delete everything that's not in the profile folder. Finally, force:source:convert back to a normal metadata profile, and you're done. Again, this is more theoretical, and you would need to do a bit of manual work, but this is what I'd do if I had your problem.


Either way, you're going to need to spend a few hours breaking this down and getting it done. If you want help with the first method, consider looking at user-access-visualization. It visualizes all the permissions a user has, so it's a good starting point for understanding the relationships.

If you want help with the second method, you'll basically need to learn DX, which you can do so over on the appropriate trailhead. Either way, you'll need to just take it slow, understand what you're doing, and you should be fine. In the future, consider using permission sets over profiles to manage access to core resources. They're a lot easier to work with.

It sounds like you'll need at least three packages if you use the DX method, so try to use the tool to build manageable chucks of at least 5,000 items. It sounds like a daunting task, but as long as you do it in pieces, it should turn out okay.

  • So I'm using DX, and I"m thinking that, along the lines of your propose, I just do multiple retrievals of <10k metadata items each, pulling the desired profiles each time, and copying the XML from the old profile to the new each time before redeploying. EG - first, retrieve all apex classes/VF pages, plus the old profile and the new profile; copy XML of apex/VF permissions from old profile to new; deploy it all back. Sound feasible to you? – smohyee Jun 25 '18 at 19:12
  • 1
    Yes, sounds like we're on the same page. Go ahead and give it a try, and let me know how it goes. I might have a use for this technique in the near future. – sfdcfox Jun 25 '18 at 19:15
  • its working so far, bit of a hassle but a lot better than checking boxes in UI. One question maybe you have an answer to: is there a way to deploy the profile with Apex Class metadata without running tests? I want to update the profile's apex class access, but deploying with ALL our apex classes means a huge deploy time and even a couple failed tests =/ – smohyee Jun 25 '18 at 21:14
  • I'm also finding that retrieving <members>*</members> for CustomObjects does not include CRUD for managed package objects, tho I need to include these in my new profile.. any way to pull managed package objects/fields into profile metadata? – smohyee Jun 25 '18 at 21:24
  • 1
    @smohyee Try adding: <types><members>*</members><name>InstalledPackage</name></types> to your package manifest. – sfdcfox Jun 25 '18 at 22:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.