Deploy Salesforce Permission Set Group With Muting Permission Set

Executive Summary

Moving a permission set group from a sandbox to production is a two-part problem that looks like one. The group is a deployable component, but the muting permission set that subtracts permissions inside that group is a separate metadata type with separate transport support. Salesforce Help article 005232948, published December 24, 2025, states the cause plainly: "Currently, muting permission sets are not supported in change sets." ^[1] The article's symptom text adds that the associated muting permission set is not included in the deployment, so the target org ends up with a group but without the restriction approved in the source org. ^[1]

The Salesforce Metadata Coverage Report is consistent with that guidance and shows why the issue is tool-specific rather than absolute. The rendered table lists MutingPermissionSet as supported for Metadata API, source tracking and unlocked packaging, with no check in the ChangeSets column, while PermissionSetGroup and PermissionSet do carry a ChangeSets check. ^[2] The Metadata API documentation separately defines MutingPermissionSet as its own type, stored in a mutingpermissionsets directory. ^[3] The reference release for this report is Winter '27, which ships API version 68.0. ^[4] The coverage page rendering did not label a release, so readers should confirm the row in their own release.

The practical consequence is that "deployment succeeded" is not evidence that "the restriction arrived". A group can deploy cleanly and still grant more than intended. This report therefore proposes a source-to-target evidence matrix and a negative permission test: a deliberately restricted user who must be denied one action, and a control user who must still be allowed another. Salesforce's own summaries account for muting when they list enabled permissions, ^[5] but only a tested user proves the outcome. Salesforce's Trailhead lesson explains why a failed negative test is not automatically a deployment defect: a mute applies only to the group that holds it, and a profile, another permission set or another group can still grant the same permission. ^{[5] [6]}

Three operating rules follow. First, treat each component (PermissionSet, PermissionSetGroup, MutingPermissionSet, user assignments) as a separate line in the release manifest and look up its transport support for the tool actually in use. Second, wait for the group's calculation status to return to Updated before testing, because Salesforce allows user assignment only to groups in that state. ^[7] Third, approve the smallest correction, read back the target metadata, and repeat both tests before assigning the group broadly. No sandbox experiment was run for this report; the procedure below is a documented method to execute in the reader's own org, and every example figure is labeled hypothetical.

Introduction and Background

Permission set groups bundle permission sets so that a persona receives one assignment instead of many. Salesforce Architects recommend a model with one group corresponding to one persona. ^[8] Muting is the narrow subtractive exception inside that additive model, and Salesforce Ben describes its purpose as letting admins reuse permission sets with broader access and limit them within one group. ^[9] The Salesforce Well-Architected guidance describes it as subtracting specific permissions inside a permission set group, so that access can be assembled from reusable groups and then trimmed for a given population. ^[10] Salesforce Architects also caution that, in sandboxes, permission sets are often used for elevated administrator access, so environments can differ legitimately. ^[8] They also caution that muting adds a layer of complexity that can make access controls harder to maintain and audit. ^[8]

That complexity surfaces at deployment time. A typical consulting scenario is a build in a developer sandbox: an admin creates a "Sales Operations" group from four permission sets, mutes the Account Delete permission in a muting permission set, tests it, and then needs the same configuration in production. The group is visible in the change set component list, which makes it easy to assume the restriction travels with it. Trailhead notes that the muting affects only users assigned to the permission set group, ^[5] so the restriction exists in a target org only if the muting is recreated there. Salesforce's own Help article exists because that assumption does not hold for change sets.

The audience for this report is Salesforce administrators and consulting partners who must decide three things before assigning a group broadly in the target org:

• Components carried: which components their deployment path moves.
• Manual steps: which configuration steps remain in the target org.
• Effective access: whether a representative target user actually has the intended access.

This report focuses on deployment troubleshooting, so it does not re-teach profiles versus permission sets.

Scope, evidence standard and limits

The report anchors platform behavior to Winter '27. Salesforce's release notes landing page for that release is titled "Salesforce Winter '27 Release Notes" and the API release notes state API version 68.0. The Permissions and Sharing notes list items such as "Keep Manual Shares When Transferring Records" but, on that page, contain no permission set group or muting entry. The Deployment notes page is a stub that points to the DevOps section of Platform. Those are negative findings from individual pages, not a search of every Winter '27 note, so they should be read as "not found" rather than "does not exist".

Several developer reference pages cited here come from the 264.0 documentation set. That number matches the release identifier (264) in the Winter '27 release notes URLs, but the reference pages themselves state no release name, so this report describes them as the 264.0 documentation build rather than asserting a release label. Where Salesforce does not document a behavior, such as a ready-made deploy order for muting sets, the report says so instead of inferring one.

Trailhead's permission set group lesson is the main grant and mute reference used throughout. ^[5] Community and vendor sources appear only for tool-specific capability statements about the vendor's own product, and they are labeled as such. No customer names, usage statistics, time-saving figures or pricing are used.

Key Findings: What Each Deployment Path Carries

Five findings structure this section. Each is developed in a subsection below.

• Change sets: the group and its member permission sets are addable, but the muting component is not carried.
• Metadata API and CLI: muting is a separate type that needs its own manifest line and a read-back.
• Packaging and DevOps tools: coverage differs by packaging column and by vendor, so it must be checked per tool.
• Recalculation: status must return to Updated before any user test is trusted.
• Effective access: a mute is local to its group, so alternative grants decide the test outcome.

Change sets: the group travels, the mute does not

A change set is Salesforce's tool for sending customizations from one org to another, for example from sandbox to production. It works only between orgs that are affiliated with a production org and connected by a deployment connection. The "Components Available in Change Sets" page states that the available components vary by experience and edition, and lists Permission Set and Permission Set Group as addable types. The page does not list muting permission sets as an addable component. Types missing from the list can still ship only when they are added as dependencies of a selected component, and that page's dependency section does not name muting permission sets.

Help article 005232948 describes the resulting state: the muting permission set will not be deployed to the target organization, sandbox or production. Its resolution is manual. System administrators must configure the muting permission sets by hand in the target organization. ^[1] The article lists four steps, beginning with logging in to the target org and ending with creating or configuring the muting permission set manually to match the configuration in the source environment. ^[1] The article also links to an Idea Exchange post titled "Deploying Muting Permissions Sets", which describes the gap as only the Permission Set Group being deployable and its child muting permission set not. ^[11] The Idea's current status was not captured, so this report makes no claim about whether Salesforce has acted on it.

Two further change-set behaviors matter for permission work. Permission set deployments may replace, rather than merge with, the target org's permission set metadata depending on API version, so verify in the target that an omitted permission was not turned off. And change set deployments enable dependencies by default. Neither page mentions permission set groups or muting, which is why the Help article's manual step is the controlling guidance.

Metadata API and CLI: separate types, separate manifest lines

The Metadata API treats the two components as different types. MutingPermissionSet "has the same fields as PermissionSet, plus a single field, label", ^[3] is available from API version 46.0, and supports the wildcard in a package.xml manifest. PermissionSetGroup files live in a permissionsetgroups directory, and the group's mutingPermissionSets field names the permission set holding the permissions to disable.

The PermissionSetGroup documentation adds a retrieval rule that applies to any migration: when retrieving a group, also retrieve the related components, with PermissionSet listed alongside PermissionSetGroup in its example. ^[12] The practical reading is that a manifest naming only the group is incomplete. A manifest that also names the muting component, and a reviewer who confirms that line exists, is what the Metadata API path requires. The documentation reviewed does not state a required deployment order between the group and its muting set, and this report does not invent one.

The Salesforce CLI sf project deploy start command accepts a manifest through its --manifest flag, described as the full file path for the manifest (package.xml) of components to deploy. ^[13] Its --dry-run flag validates a deployment and runs Apex tests without saving to the org. ^[13] Retrieval uses the same manifest concept. The CLI pages show generic Type:Name syntax but no MutingPermissionSet example, so a successful CLI deployment of a muting set should be proven by read-back in the target org, not assumed from the command's exit status.

Do not expect source tracking to report what changed against a production org; confirm current behavior in the Salesforce CLI reference. For production, the sf project deploy validate command is the one Salesforce says is intended for production orgs, and a later quick deploy reuses that validation and skips Apex tests. The validation job ID and the --use-most-recent option have time limits, so confirm the current values in the Salesforce CLI reference before relying on a validation.

Packaging and DevOps tooling: coverage is tool-specific

The coverage report separates packaging columns. The MutingPermissionSet row shows unlocked packaging support and blanks for second-generation and first-generation packaging, while PermissionSetGroup is supported in all three. ^[2] Salesforce's packaging guide states that permission set groups can be included in first and second-generation managed packages, and Help adds that in a subscriber org a muting permission set can disable permissions in a group installed from a managed package. Trailhead makes the same subscriber-side point: you can mute permissions in permission set groups for features you are not ready to adopt. ^[5] A vendor package therefore does not need to ship the subscriber's muting set, and the subscriber's muting set is local configuration that must be moved by a path that supports it.

Third-party DevOps documentation is uneven, so each vendor claim should be read as a statement about that vendor's product only. Gearset's blog states that permission sets and permission set groups can be deployed as part of its click-driven flow, ^[14] and flags a group deployment that omits new permission sets, ^[14] and its documentation recommends a two-step approach for new permission sets. ^[15] None of those pages mentions muting. Copado Essentials release notes record Muting Permission Set among the metadata types it added, ^[16] and a later release fixed storing Muting Permission Set metadata in DX format. ^[17] These are product-specific capability statements that the reader must confirm in the exact tool and plan in use; they are not a general rule that every DevOps product carries the component.

Recalculation status after deployment

A group has a calculation status, defined in the Metadata API documentation as the permission set group recalculation status with the values Updated, Outdated, Updating and Failed. ^[12] The same field is queryable as Status on the PermissionSetGroup object. The Help status table says that while a group is Outdated, user assignments cannot be modified. ^[18] The Updating state is brief; Salesforce notes the process is quick and the status is rarely seen. During recalculation, assigned users keep the permissions from the last completed calculation.

Recalculation is triggered by edits. Adding, deleting or editing a custom permission set in a group starts one. A deployment can start one too: Salesforce notes that an update to a permission set group during the deployment phase triggers a recalculation. ^[19] If a group lands in Failed, Help offers a manual recalculation for a group that has a status of Failed after deployments or package updates. ^[18]

This produces a specific testing rule. Assignment is allowed only for groups with a status of Updated. A negative test run against a user who still holds the last completed calculation may reflect old permissions, in either direction. The acceptance step must therefore record the status and wait for Updated before any allowed or denied action is judged.

Effective access: a mute is local to its group

Muting changes only the group that holds it, as a Nebula Consulting explainer also puts it. ^[20] Trailhead states that the muting affects only users assigned to the permission set group, ^[5] and users assigned directly to a member permission set outside the group are not affected. ^[5] A group can still be bypassed by another grant: the user keeps a permission when a profile, another permission set or another group provides it. ^[5] Help restates the scope: the muting permission set applies only to its related group. Non-Salesforce explanations agree, including a 2026 community tutorial ^[21] and a Certinia documentation page stating that muting permission sets cannot be used outside permission set groups. ^[22]

Muting also cascades. Help states that if you mute Read on an object, Create, Edit, Delete, View All Records and Modify All Records are muted as well. ^[23] But muting the Modify All Data or View All Data user permissions does not mute the included object permissions, which must be muted explicitly. ^[23] A restriction test designed around one object permission therefore needs the reviewer to know which other grants exist for that user, not only what the group contains.

Implementation Considerations and Process Changes

The seven steps below follow the order a reviewer would work in. They use native Salesforce interfaces first. They do not prescribe click paths or deployment order that the reviewed documentation does not state.

Step 1: Build the sandbox fixture and define the assertions

Create a small fixture in a sandbox with no real customer records: one group containing the member permission sets, a muting permission set that mutes Account Delete, and two test users. Define in advance one denied action (delete a test Account) and one allowed action (read or edit that Account). Salesforce's Well-Architected guidance advises testing against releases in sandbox environments before production deployment. ^[24] Note that Delete is controlled by the PermissionsDelete field on ObjectPermissions, documented as allowing the parent permission set to delete records for the object.

• Denied assertion: the restricted user cannot delete a test Account.
• Allowed assertion: the same user can still perform a read or edit that the group intends to preserve.
• Control user: a second user with the group but without the muting-relevant alternative grants, to separate "mute missing" from "another grant present".
• Evidence: a screenshot or export for each assertion, the user ID, the group name and its status.

Step 2: Separate the components in a manifest checklist

List four rows for every group:

• PermissionSet members: every member permission set by API name.
• PermissionSetGroup: the group definition and its status.
• MutingPermissionSet: the muting component and the permissions it disables.
• User assignments: direct and group assignments, tracked as data.

For each row, look up the transport column in the coverage report for the tool in use. The same report distinguishes the Metadata API, source tracking, unlocked packaging, second-generation and first-generation packaging, and ChangeSets columns. ^[2] User assignments are not covered by the PermissionSetGroup metadata line; they live in PermissionSetAssignment, which holds both permission set and group assignments through a PermissionSetGroupId field. Assignments may carry an expiration date.

Step 3: Compare source and target evidence

Build the source-to-target matrix (Table 2 below) from native views and queries. Missing evidence is recorded as unknown, not as a match. The PermissionSetGroupComponent object is the junction that relates groups and permission sets and is documented for querying group members. ^[25] The MutingPermissionSet object is documented to disable specified permissions within a permission set group, and a ready-made example filters ObjectPermissions by Parent.PermissionSetGroup.DeveloperName to list a group's object permissions.

Salesforce's Admin blog notes that every permission set group or profile has an associated permission set, which is how access found in ObjectPermissions can be traced back to a group. ^[26] The PermissionSet object exposes the owning group through PermissionSetGroupId. Compare these fields and watch three pitfalls:

• Fields to compare: group API name, member permission sets, muted permissions, dependency effects, status, assignments and baseline profile.
• Child objects: only user permissions live on PermissionSet itself; object, field and setup-entity permissions are managed in child API objects.
• No row means no access: a query cannot return permission sets that have no access on an object, because no record exists.
• Modify All Data: it enables all object permissions without physically storing any object permission rows, so an ObjectPermissions comparison can miss an alternative grant. ^[27]

PermissionSetGroup is also a Tooling API object, and sf data query supports the Tooling API flag. This report could not confirm a Tooling API page for MutingPermissionSet, so the reader should test that query in the org instead of assuming it works.

Step 4: Apply the path-specific correction

Choose the correction by path:

• Change-set path: follow the manual target configuration in Help article 005232948: log in to the target, open the group, and configure the muting permission set to match the source.
• Metadata API path: a reviewer verifies that the manifest lists the exact MutingPermissionSet component, that the retrieved source contains it, and that the target read-back shows it.
• Packaged or DevOps-tool path: confirm the tool's own documentation lists the muting type before relying on it.

Do not promise deployment order; none is documented in the Salesforce pages cited here. Salesforce's Well-Architected guidance on operational excellence points out that environment definitions in version control make differences visible as diffs rather than silent divergence. ^[24]

Editing a group requires the Manage Profiles and Permission Sets permission, as the Metadata API documentation for PermissionSetGroup states. Help's permission table lists the same permission for muting a permission in a group. Viewing a group summary needs a different permission, View Setup and Configuration. A read-only reviewer can therefore inspect but not correct.

Step 5: Wait for recalculation, then test two users

Check the status before testing. Record Updated, Outdated, Updating or Failed in the matrix. Wait for Updated, then run the denied and allowed assertions with the restricted user and the control user. A community tutorial lists "assigning before the status is Updated" as a common mistake and advises to wait for the calculation to finish. ^[21]

Salesforce provides in-app summaries that account for muting, and the Salesforce Admin blog describes summary views for users, permission sets and groups. ^[26] Trailhead says the User Access Summary and the Permission Set Group Summary both take muting permission sets into consideration when determining what permissions are enabled. ^[5] The Help note on the Combined Permissions section of a group page states that it does not reflect muted permissions, so the group's summary view is the one to use for the effective list. ^[28] The User Access Summary can show which profile, permission set or group is granting a specific permission through an "Access Granted By" row action. ^[29]

If the denied assertion fails, find every grant before calling it a deployment defect. Check each of these sources:

• Profile: the user's baseline profile.
• Direct assignments: permission sets assigned outside the group.
• Other groups: any second group assigned to the same user.
• Broad user permissions: Modify All Data and View All Data.

Step 6: Approve the smallest correction and read back

Make the smallest change that closes the gap, such as recreating the missing muting permission set in the target group, rather than editing member permission sets. Because a mute affects only the group, deleting it restores the muted access, which makes it easy to reverse. ^[20] If the failure came from an alternative grant, such as a redundant direct assignment, fix the assignment instead of the mute. Muting changes only the group, not the permission sets themselves, which is why it is the least invasive correction. ^[20] Read back the target metadata, re-run both tests, and attach the evidence. Use the normal release tool and change process.

Licensing can block assignment. Help says that if group permissions need a permission set license, assign the license to users before assigning the group, and that otherwise the user receives an assignment error. Apex tests that assign permissions can behave differently when permission set groups change in the same deployment, so confirm the current Salesforce guidance for your release before relying on them.

Step 7: Close with an acceptance record

Complete the one-page acceptance template (provided at the end of the Conclusion) and attach it to the change record before a wider assignment is made. The record should hold:

• Test evidence: denied and allowed results for the restricted and control users.
• Metadata read-back: the target group and muting component after correction.
• Approval: the named approver and timestamp.

Assignments matter because an unassigned group changes nothing for any user, while a broad assignment applies every permission the group contains, including permissions the missing mute should have removed.

Data Analysis and Evidence

Table 1 below consolidates the transport findings by component and path. It records what each source states, with the evidence class, so that a reviewer can see where the claim comes from. It is a documentation matrix, not a test result.

The table shows a split that is easy to miss when reading only the group row. The group and its member permission sets have change-set support, but the muting component does not, while the Metadata API route supports all three. The interpretation is deliberately narrow: the coverage report is a per-tool statement, not a claim that Salesforce cannot deploy muting. The Help article is dated December 24, 2025; the coverage page did not state a release label, so confirm the row in the release you are deploying with.

Table 2 below is the source-to-target evidence matrix that this report recommends. Each row is an observation to record, with the native place to look and the rule for unknown values.

Table 2 is designed so that every cell has an observable source. The final row matters most because a clean metadata comparison still does not prove effective access. Group status, alternative grants and licensing all sit outside the muting component, and the Help guidance for the Combined Permissions section already warns that one native view omits muted permissions.

A reusable parity CSV

The following header supports one row per tested assertion. It is a template, not a dataset.

source_org,target_org,group_or_component_api_name,source_grant,intended_mute,target_state,recalculation_state,alternative_grant_source,expected_operation,actual_result,approver,timestamp

Compute the two summary figures from the tested sample only:

• Missing components: the count of rows where the intended mute exists in the source but target_state shows no matching muting component.
• Failed assertions: the count of rows where actual_result differs from expected_operation.

Neither number describes untested users, untested actions or untested objects, and a parity CSV with zero missing components still falls short of a proof of equivalent effective access.

What an AI client can and cannot do in this workflow

An authorized AI assistant can inventory accessible metadata, normalize the source and target inventories, flag a missing muting record and draft a test list. It cannot infer facts the org does not expose, approve its own change, or bypass permissions. Missing API visibility is not a clean result; it is an "unknown" row that a human must resolve. Salesforce's own MCP documentation states the principle for its hosted servers: tool calls run with the same permissions as the user who authorized the connection. ^[30]

Table 3 below summarizes documented facts about access paths an AI client could use for the read-only inventory step. The rows rely on Salesforce documentation and the Salesforce DX MCP Server repository.

The table is not a ranking. The point it supports is procedural: whichever client does the inventory, the person reviewing must own the dependency judgment and the effective-grant test, and the approval and change process stay in force.

Case Studies and Real-World Examples

Hypothetical Example: the Account Delete mute

(Hypothetical Example) A partner builds a "Sales Operations" group in a developer sandbox from four permission sets and mutes Account Delete in the group's muting permission set. They deploy the group to production by change set. Following Help article 005232948, they open the target group and configure the muting permission set manually to match the source. Production shows the group status as Updated.

Assume (Hypothetical Example) a test sample of five assertions: the denied delete and the allowed edit for a restricted user, and the same two for a control user, plus one check on the Account Read path. The restricted user's delete attempt succeeds. Rather than recreating the mute, the reviewer opens the User Access Summary and uses Access Granted By on the delete permission. It shows a second, directly assigned permission set that grants Delete. The mute was correct; another grant was present, which is the scenario Trailhead describes. ^[5] In this invented sample, failed assertions are 1 of 5 and missing components are 0 of 1. Both figures describe only those five tests, and none of the numbers are measured data.

The correction is to the assignment, not the muting component, and it goes through the normal change process. The restricted user's access came from a direct assignment outside the group, so the mute did not apply to it; removing that redundant grant through the change process closes the gap. ^[5]

Implications and Future Directions

Because environment differences should surface as visible diffs rather than silent divergence, keep the source-to-target comparison as a repeatable step in every release, not a one-off check. ^[24]

• Tool coverage is a moving target. The coverage report is a live reference, and the Help article is dated. The ChangeSets column may change in a later release, and a reader should re-check the row rather than relying on this report or on the article date. No Winter '27 note on muting deployment was found on the pages read, but that is not proof of absence.

• Governance simplifies when groups stay small. Salesforce Architects note that sandboxes and other non-production environments may use permission sets for elevated administrator and developer access, ^[8] which means a sandbox can legitimately differ from production for reasons unrelated to muting. Designs with many mutes are harder to review. ^[8]

• AI assistance is an inventory aid, not an authority. The Salesforce Admin blog observes that summary views make answering user access questions easier. ^[26] An assistant can join the summaries to the inventories, but the review of dependencies and effective grants remains human work, and the approval gate stays with the admin.

• What to measure next. A team that adopts the matrix could track tested rows, failed assertions and manual corrections per release, using the definitions above. No public benchmark for those figures was found, and no time saving is claimed.

Frequently Asked Questions (FAQs)

Can a muting permission set be deployed with a change set?

Salesforce says no. Help article 005232948 states that muting permission sets are not currently supported in change sets. The coverage report shows no ChangeSets check for MutingPermissionSet. Use the manual target steps in the article or another supported path.

How is a permission set group deployed with its muting permission set through the Metadata API or sfdx?

List both PermissionSetGroup and MutingPermissionSet in the manifest, plus the member permission sets. The Metadata API defines MutingPermissionSet as its own type, and retrieval of a group should include its related components. The CLI accepts a manifest. Validate with --dry-run, then read back the target. No documented deploy order was found.

Why is a permission set group not deploying the muting permissions?

On the change-set path, the muting component is not included. On other paths, check that the manifest names the muting component and that the deployment tool supports the type; a vendor tool may carry it, as in Copado Essentials' release notes, ^[16] but verify it in your tool.

Why is the group status Outdated after deployment?

Outdated means the group requires recalculation; user assignments cannot be modified meanwhile. Deployment can trigger recalculation, and a Failed group can be recalculated manually. Wait for Updated before testing.

What is the difference between a muting permission set and a permission set group?

A group bundles permission sets and a muting permission set removes selected permissions inside that one group. ^[9] A group can have up to one muting permission set. ^[5] A vendor documentation page makes the same point. ^[22] The mute does not alter the member permission sets or users who hold them directly. ^[5]

How can user access be compared between sandbox and production?

Use the matrix in Table 2: group membership through PermissionSetGroupComponent, ^[21] the group summary view, the User Access Summary, and a tested restricted user and control user. Metadata parity alone is not effective-access equivalence.

What are the best practices for deploying permission set groups?

Treat components separately, test in a sandbox, ^[24] wait for Updated, find every grant before diagnosing a failed negative test, and keep a signed acceptance record. Managed-package groups can be muted by subscribers, ^[32] so check the local configuration too.

Conclusion

Group deployment success and restriction equivalence are different facts. Salesforce's Help article states that change sets do not carry the muting permission set, and the Metadata Coverage Report shows the MutingPermissionSet row without a ChangeSets check while the PermissionSetGroup row has one. The behavior is tool-specific: the Metadata API treats muting as its own type, and some DevOps products list it as supported.

The decision a reader faces is whether the target assignment can proceed. The evidence needed is concrete: the component lines in the manifest, the group's calculation status, the muted permissions in source and target, every alternative grant for the tested user, and the results of one denied and one allowed action. Anything not observed is unknown, and unknown is not acceptance. Validating in the reader's own release and org, with a restricted user and a control user, is what turns a documented expectation into evidence, and the acceptance record attached to the change is what lets the wider assignment go ahead.

One-page acceptance template. Record each of these on one page:

• Release: Salesforce release and API version, edition and test date.
• Orgs and tool: source org, target org and the release tool used.
• Components: component list and the manifest reviewer.
• Group: group name and member count.
• Muting component: present, absent or unknown.
• Calculation status: Updated, Outdated, Updating or Failed.
• Alternative grants: sources found for the tested user.
• Denied assertion: expected and actual result.
• Allowed assertion: expected and actual result.
• Correction: what was applied and the read-back confirmation.
• Sign-off: approver and timestamp.