0

We have a tricky situation at our company and can't figure out a solution, maybe someone could help.

For support and investigation purposes, we need to give certain developers the permission to:

  • execute Apex scripts in dev console
  • run queries in dev console
  • view record data in Salesforce Inspector
  • to a diff check in Visual Studio Code from a sandbox against PROD

In order to allow them to run scripts in dev console, we have to give them the 'Author Apex' permission (which comes together with the 'Modify Metadata Through Metadata API Functions' one). However, if we do that, they are able to deploy to PROD directly, which, obviously, we don't want to do.

Is there a way to give someone all the above permissions, but stop them from deploying directly to PROD ?

We also looked into activating the following setting in Visual Studio Code: Detect Conflicts At Sync, which shows a confirmation popup whenever someone tries to deploy something new. However, this is not ideal because it runs for all environments. Maybe someone knows if it's possible to enable it only for PROD?

All advice is welcomed. Thank you!

Improve this question
2
  • You could try blocking the "Salesforce CLI" connected app on production, so they can't use the CLI to perform deployments etc. You'll find this in Setup under "Connected Apps OAuth Usage". Likely to kill the diff check, of course.
    – Phil W
    Commented Aug 13 at 16:20
  • Unfortunately, this also stops everyone from being able to diff check/retrieve and wouldn't work for our case :(
    – cornDog
    Commented Aug 14 at 7:43

2 Answers 2

Reset to default
0

There are two potential approaches here:

Perform diff checks against version control (recommended)

Do not connect VS Code to production. Have the developers perform diffs against the production code branch in your version control system. If you aren't at least backing up production metadata to version control I would resolve that first.

Giving devs the ability to connect VSCode to prod will eventually end in tears. Someone will forget which environment they are connected to and cause a major issue with anonymous apex or similar.

Assign dev console permissions via session-based permission set

If your company absolutely must follow this workflow the "author apex" and other permissions required for dev console but not VS code diffing could be assigned via a session-based permission set so they will need to explicitly activate the session in order to have those permissions.

Improve this answer
2
  • thanks for you advice, unfortunately none of these would work for our requirements :( sometimes small changes are made directly in prod (don't even ask...) and we need to to allow certain users to diff check and retrieve against PROD this is why the ideal solution would be to just stop people from deploying using SF CLI to prod; to be honest, I'm surprised there isn't such a setting in VSC
    – cornDog
    Commented Aug 14 at 7:46
  • The 2nd option should work for you then. You could even automate the assignment of the "author apex" permission set when they login through the web UI.
    – Greg Grinberg
    Commented Aug 14 at 19:48
0

The preferred development model today is to use Unlocked Packages. Rather than running a diff against production, they should be able to diff against a branch, and have that represent the changes that would occur if the developer were to install an updated package version. This would limit their profile in production to having View All Data and Install Packages, along with the various Dev Hub permissions for utilizing Scratch Orgs and Unlocked Packages.

Improve this answer

You must log in to answer this question.

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