Must satisfy
Must satisfy attaches a standing requirement to a piece of access: multi-factor authentication being on, say, or the holder still being in a particular department. Use it when the question is not who gets the access, but what has to stay true while they hold it.
What it does
The effect's own words: "Holding this access requires these conditions. Ploy acts on anyone who stops meeting them."
A Must satisfy policy never hands out access and never takes it away by itself. It conditions whatever access something else produced, whether that was a Gets policy, an approved request or a manual grant. If nobody holds the access, the condition simply never bites.
It bites at two moments:
While the access is held. Somebody who stops meeting the condition is acted on, and their access is held back.
At the moment of asking. A request for that access from somebody who does not meet the condition is refused, worded as a requirement: "Requires multi-factor authentication to be enabled".
The policy sentence reads as a standing statement, for example: Anyone's access to "Salesforce" must satisfy: multi-factor authentication is enabled.
Write one
Open Managed Access, go to the Policies tab and choose New policy.
Under Who, choose whose access the requirement covers. Leave it empty and the sentence possessor becomes "Anyone's".
Under What, pick the Must satisfy effect card.
Name the target. A condition has to bound one specific app or entitlement, so Everything is not offered here.
Fill in the Condition editor. Its own copy reads: "What has to stay true. Access is held only while it is, and asking for it without it is refused." Leave it empty and saving is blocked with "Add at least one condition to save this policy."
Check the preview column, then choose Create & activate.
What you can put in a condition
The condition list is deliberately shorter, and different, from the Who list. It holds job title, department, team, employment type, location city, location country, location region, profile, a named person, access tags, the role on the access itself, and multi-factor authentication.
Two of those, role and access tags, describe one piece of access rather than a person, so they can only be answered about access somebody already holds.
Good to know
At least one condition is required. The Save button stays disabled until you add one.
It must name a specific app or entitlement. A requirement bounds one thing, and "everything" has no condition anyone could measure against.
Conditions stack, they never compete. When two Must satisfy policies cover the same people and the same target, both apply: those people must meet both policies' conditions.
It never wins or loses an overlap. Against a Gets or a Can request policy it attaches to the outcome; against a Never gets or a Can't request policy there is no access to condition, so it is moot.
Role and access tags cannot refuse a request. They describe access that does not exist yet at the moment somebody asks, so a condition built on those two only bites on access already held.
Identity requirements are not available. The "via identities where" panel, which narrows a policy to a particular kind of account, is refused on this effect today: "Account requirements are not supported on guardrail policies yet."
Held-back access shows in the outcomes panel. On a granting policy's Details tab, somebody stopped by a condition is tallied as "Held back by a condition", so you can tell a condition apart from a denial or a missing account.
Effect matrix