Roles, policies, and conditions

These records are related but not interchangeable:

Concept	Job
App Role	Names an app-specific access relationship and can have parent and descendant App Roles.
Role membership	Assigns an App Role or Site Role to a user. A parent App Role membership includes descendant App Roles.
Role Policy	Synchronized when an App Role is created. Its initial resource wildcard and action wildcard grant broad access; review and narrow it before assigning a membership. It can be missing if synchronization fails.
Resource policy	Governs actions on one resource and names the App Roles or derived roles that may perform them.
Principal-specific policy	Targets one caller rather than a reusable membership.
Derived-role policy	Produces a reusable role when its condition matches; a resource policy must import and use it.
Site Role	Bundles App Roles from one or more apps for site-level assignment; it does not change the App Role hierarchy.

Creating an App Role does not grant a user access until a membership is assigned. Before that assignment, confirm the synchronized Role Policy exists and narrow its wildcard permissions to the intended least privilege. Then assign the membership and verify both allowed and denied decisions. A separate resource policy is optional and is used only when the resource needs its own role or condition rules.

Conditions compare caller and resource facts for a particular decision. Roles name the relationship; conditions express the narrower facts that must hold. Keep them separate so policy review can explain why a decision is allowed or denied.

Continue with Manage app roles or Assign user access.