6

I've been going back and forth most of the day today with both Salesforce's CPQ Team AND our implementation partner with regard to whether or not we should install Salesforce CPQ for All Users, or whether we should install for Admin Only and use the included Salesforce CPQ User and Salesforce CPQ Admin permission sets to control access/visibility into specific objects in the app.

Both the Salesforce team AND the implementation partner are suggesting that I install for All Users. One Salesforce Engineer even went so far as to tell me that I should install for All Users and then use the Permission Sets to assign appropriate access to people based on their needs.

However, when I ran a test in our Full Copy Sandbox of running the Install for All Users, the end-result was that our Sales team members with a Custom Profile had a much higher level of access to Salesforce CPQ Objects and features than I want them to have. I understand that Full Copy Sandboxes ignore Managed Package license assignments/restrictions, but sandboxes do still honor CRED/FLS/Sharing.

After the install, Sales users were able to create Product Rules, Discount Schedules, and other components that I thought should be considered "Admin". Far above and beyond the expectation I have for them of creating opportunities, quotes, quote line items, quote documents, etc.

I uninstalled the app, and re-installed it for Admin Only, and then the Sales user had no access to anything. I then assigned the Sales User to the Salesforce CPQ User permission set and they had access to do CPQ Quoting as expected, and nothing else.

I then went back to all parties and asked them to clarify the point of the Permission Sets if we use the All Users option which seems to grant elevated access by default, and I even referred them to this help article https://help.salesforce.com/articleView?id=distribution_perm_sets_profile_settings.htm&type=5 which clearly states that Permission Sets can be updated at any time during managed package updates versus profile permissions which states that Only permissions related to new components created as part of the install or upgrade are applied., but everyone is still sticking to their message that we should install for All Users.

Ultimately, my question is: Am I right in my assumption that installing for All Users will give CRED/FLS access to the profiles that we might not necessarily want to grant, and that in order to solve for that problem I would have to go back to each of our 25+ custom profiles and start removing CRED access to these extra objects? I'm certified in Sharing and Visibility design, so I am no stranger to how the security model works, but everyone is telling me that I should still install for All Users. Why?

2
  • 4
    I think you did a very thorough job in testing the differences and verifying your theory. I don't think there is anything else to be added. You know what your answer is. In my experience there is not very much Salesforce CPQ knowledge out there even amongst the CPQ support team. We often have to run our own tests much as you did.
    – gNerb
    Jun 3, 2020 at 20:26
  • 2
    Another note, installing for all users is kind of like the tech support way of saying "If you install for all users, everyone has access to everything and you're not going to come bother me for help with permissions". GoDaddy support once told me to install my CMS with chmod -777 perms which is roughly equivilent. I did not do that and it did take more work to get it set up and the permissions right, but they were right and not loose/open for anyone to mess with.
    – gNerb
    Jun 3, 2020 at 20:30

1 Answer 1

2

To answer your questions, yes you are right but see specifics below. and No they are wrong in most situations, only insecure orgs would approach like this. Admin Only is the best way to approach it. You can always copy the extra permissions over and redeploy them.

The approach to assign All users and then use the license (that permissionSet) to constrain is all well and good, but it does not allow for granularity. and definitely will not allow you to "use the Permission Sets to assign appropriate access" I think your Salesforce engineer is wrong. It actually concerns me this level of advice, it is mis-informed. Keep asking them the hard questions until they give you the reason for their answers, they must back it up. the fact that you wrote this question just goes to show you are convinced and you are right in your thinking. Do the extra work to get it right. Sometimes consulting advice can be tainted with a desire to "Just get it done" (Sales) , and this is usually outweighed by "Do it right first time" (Service).

2 Things...

  • I think it is important to call out the specific permissions that can be given as part of an installed app. But I believe you should not provide any profile access to other users, only admin profile.

  • You should build up each permissionSet with the specific access. 2 ways to achieve this of course, start with All users and remove access or what I would do Only Admins and add access accordingly. often the installed package is only for a specific segment of the organisation (Large)

Here is the reference that helps answers the specifics: https://help.salesforce.com/s/articleView?id=sf.distribution_installing_packages.htm&type=5

Specifically these are the assigned permissions (specific to the app of course)

Install for Admins Only

Specifies the following settings on the installing administrator’s profile and any profile with the "Customize Application" permission:

  • Object permissions—Read, Create, Edit, Delete, View All, and Modify All - enabled
  • Field-level security—set to visible and editable for all fields Apex classes—enabled
  • Visualforce pages—enabled
  • App settings—enabled
  • Tab settings—determined by the package developer
  • Page layout settings—determined by the package developer
  • Record Type settings—determined by the package developer After installation, if you have Enterprise, Performance, Unlimited, or Developer Edition, set the appropriate user and object permissions on custom profiles as needed.

Install for All Users

Specifies the following settings on all internal custom profiles:

  • Object permissions— Read, Create, Edit, and Delete-enabled
  • Field-level security—set to visible and editable for all fields
  • Apex classes—enabled
  • Visualforce pages—enabled
  • App settings—enabled
  • Tab settings—determined by the package developer
  • Page layout settings—determined by the package developer
  • Record Type settings—copied from admin profile

Install for Specific Profiles...

Lets you determine package access for all custom profiles in your org. You can set each profile to have full access or no access for the new package and all its components.

  • Full Access—Specifies the following settings for each profile:
    • Object permissionsRead, Create, Edit, and Delete enabled
    • Field-level security—set to visible and editable for all fields
    • Apex classes—enabled
    • Visualforce pages—enabled
    • App settings—enabled
    • Tab settings—enabled
    • Page layout settings—determined by the package developer
    • Record Type settings—determined by the package developer
  • No Access—Page layout and Record Type settings are determined by the package developer. All other settings are hidden or disabled.

You must log in to answer this question.

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