Every permission check comes down to a fixed set of permission keys (View/Edit/Run a job, manage credentials, manage target servers, etc.), granted to roles -- never directly to a user -- at one of several scopes: Step, Job, Folder, Server, or Everywhere.

How a conflict gets resolved

Minion Agent resolves permissions the same way Windows NTFS file permissions do: the most specific scope that has any grant at all wins outright, and only within that winning scope does a Deny beat an Allow. This lets you carve out an exception for a handful of jobs without having to explicitly deny everything else -- e.g. an Editor role can be denied Edit access on one sensitive job, without touching anything else that role can do.

Built-in roles

RoleGets
ViewerView access across Jobs/Credentials/Target Servers/Schedules
OperatorViewer + Run Jobs
EditorOperator + Edit Jobs, Manage Credentials/Target Servers/Schedules, View Hidden Step Code
AdminEverything, including Manage Roles & Permissions
Fleet AdminBypasses the permission system entirely -- see below

Any built-in role's default grants can still be overridden per-object, same as a custom role -- e.g. an Operator can be denied edit access on one specific sensitive job without losing access to everything else.

Fleet Admin: the bypass role

A user in the Fleet Admin role skips every permission check entirely -- nothing is consulted, nothing is denied, ever. Exactly the same idea as sysadmin on SQL Server.

Settings -> My Permissions

See exactly why you do or don't have a given permission -- which role, at which scope, is actually responsible. An admin can look up anyone; everyone can always look up their own.

Hiding a step's code from other editors

A step owner can flip a step's "Hide from other editors" setting so its command text is hidden from anyone without the View Hidden Step Code permission -- without locking them out of the job or step entirely.

Applying a grant to many targets at once

The per-object Permissions dialog (opened via the lock icon on a job, step, folder, or target server row) has an "Apply To" picker -- check several siblings at once (say, 47 of 50 target servers) and add the same grant or blacklist override to all of them in one action, instead of opening the dialog 47 times.

See also: Command Blacklist, which uses the same Permissions dialog for its own overrides.

See also: Glossary for related terms.