Introducing warden
Salesforce user administration is not one task. Creating a user is not one screen. And in many organizations, users don’t join one at a time. Entire teams can be onboarded each with different personas made up of an amalgamation of Permission Sets, Permission Set Groups, Public Groups, Queues and more. Bouncing around the Salesforce setup UI is painful and if you miss a step or mis-click, Bob sees Alice’s deals and Alice’s direct reports can’t view that report she shared with them.
And what about that group of contractors whose contract ended last Friday? Were they all deactivated or frozen? And the other one who switched contracts to support a different app? Do they still have admin access to the last application they were supporting? HR wants to know and they want an artifact showing that it was done when you say it was done.
These are the problems warden is designed to solve. warden treats access as something that should be documented, reviewed, and verified. It should be a repeatable process.
You begin by creating personas. A persona is a named description of the access a kind of user should have: profile, role, permission sets, permission set groups, public groups, and queues. Your users can be in a csv, same as you would use with dataloader, but with an additional column for their personas because warden can provision those users with their personas.
Persona definitions can live in Git. A teammate can review them. A future administrator can understand the history. An auditor can examine them. Current admins can apply them.
And warden can compare this with what is actually happening inside the org. Its eight commands cover the user lifecycle:
provisioncreates and updates users from your definitions.difffinds the gap between intended and actual access or the gap between two users.accessanswers who can see what or how a particular user can see a given field.snapshotandrestorepreserve assignments in a portable format.freezeandunfreezecontrol whether a user can log in.stripcaptures the current state, removes access, and deactivates the user.
The access and diff commands are read-only. They can inspect production without changing it.
Every command that writes supports --dry-run, so you can see the proposed changes before approving them. Every command also supports human-readable, CSV, and JSON output. The output is whatever the moment requires: read it in a terminal, hand it to an auditor, or pass it into another system.
There is also a companion Visual Studio Code extension to save you typing out all those flags.
Both the CLI plugin and VS Code extension are 100% free and open-source (MIT).
sf plugins install @syntax-syllogism/warden