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?

Improve this question
2
  • 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, 2018 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, 2018 at 19:08

3 Answers 3

Reset to default
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!

Improve this answer
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.

Improve this answer
9
  • 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, 2018 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, 2018 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, 2018 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, 2018 at 21:24
  • 1
    @smohyee Try adding: <types><members>*</members><name>InstalledPackage</name></types> to your package manifest.
    – sfdcfox
    Jun 25, 2018 at 22:26
0

we recommend this tool that we have developed to avoid XML size problems https://github.com/OscarIuliano/ProfiliSFDC.git

Improve this answer
1
  • While this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference.
    – identigral
    Dec 5, 2020 at 15:40

You must log in to answer this question.

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