0

I want to block edit and delete rights for certain custom objects in my managed package for all users in subscriber orgs. I would be okay if admins bypassed this (i.e. I can live with admins having Modify All). What's important to me is achieving this in a seamless manner (i.e. as invisible to the installer as possible).

I think I have a few ways, each having their own short-coming:

Permission Sets

I will need a post-install script to assign to all users. But what about users that are created afterwards? I think that still requires manual assignments.

Profiles

For the scenario described above using profiles is not recommended by Salesforce. But let's say I went with profiles; first, admins will be able to overwrite them and second, how would I manage cloned profiles?

Overridden View/Edit action buttons

This will only work through the UI. The back-end still leaves my objects unprotected.

Triggers

This isn't the most user-friendly option, but works otherwise.

I believe the combination of triggers and page overrides pretty much does what I need (except for not removing Edit/Del links on related lists which is within tolerance), however I feel as though this is the job of Permission Sets and Profiles. What is the proper way to do this?

Btw in case you are wondering about data cleanup; I have Apex taking care of that through a VF page.

  • 1
    Is the data to much for a custom metadata type that you could make NOT subscriber updatable – Eric Mar 27 '17 at 23:28
  • @Eric That would've been an interesting alternative if my custom objects didn't need to be related to other custom objects (children in Master-Detail relationships, in fact). – Mossi Mar 27 '17 at 23:40
  • 1
    then I believe your only option is a trigger. All Security settings related to sharing, access, OWD, etc can be modified by the subscriber. You cannot control it. The only thing you can do is block access via trigger AFIAK – Eric Mar 27 '17 at 23:41
1

Your only choice would be triggers. There's no way you can force any particular maximum access level to your objects, because administrators ultimately have final say on how the objects can be used, permission sets can't reduce object access levels nor can they be prevented from being removed by an administrator, profiles can't be locked down from an admin that wants to modify it, and button overrides, as you've observed, will not prevent API access.

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.