# Manage local access and publication controls

Restrict central grants and apply the site’s optional additional release checks.

Source: https://help.smartfact.ai/manuals/labels/people-and-release-controls

Review edition: 25 October 2026

Roles: owner, reviewer

Owner manages **Team & stations** for this LabelRules site. SmartFACT Accounts remains responsible for identities, organisation membership and central product roles. Local site choices can restrict those grants; they cannot create a central role the person does not hold. Reviewer reads this guide to understand additional publication checks, not to obtain team-management authority.

## Review the intended person and site

Confirm the organisation and site before editing. Use the central Accounts link when an invitation or product grant is missing. A person removed from this site can still hold an Accounts product grant; central access and local admission must be reviewed separately.

Under **People at this site**, select the person's permitted local roles and choose **Save site roles**. Review the resulting assignment. Do not infer role authority from a job title or give everyone every role simply to clear a task refusal.

Use the person's remove control only after arranging any operational handover. Following a closure and reopening, inspect **Waiting to come back** and deliberately choose **Let back to this site** for the intended people. Reopening does not automatically restore those local assignments.

The Stations section describes current station operation. Printer/workstation enrolment and qualification belong to the selected printing workflow and [PrintStation setup](/manuals/printstation/owner); do not mistake the team list for evidence that hardware is ready.

## Choose additional release controls

Read **Release controls** and the plan/readiness message. The two optional controls are off until enabled. When plans are enforced, enabling them requires the stated included allowance. An unavailable plan answer is not permission to bypass the check.

**Require a second reviewer's approval before publication** adds an approval of the exact verified candidate. That approver cannot be its editor/freezer, and the person who publishes cannot be the person who approved it. Check that the organisation has enough eligible people for the intended review before enabling it.

**Ask reviewers to confirm it's you for each publication** adds a separate Accounts confirmation for every publication. Ordinary publication already needs recent second-factor verification; with this control, one confirmation does not cover two publications.

Choose **Save release controls** and inspect the saved result and recorded change. These controls apply to subsequent publications. A rollback to an earlier published release follows its separate rollback review, not a claim that the original candidate's approval has just been repeated.

## Resolve an access or approval refusal

Check central grant, local assignment, exact candidate contributors, current plan and required authentication. Correct the actual missing condition with the responsible administrator or another eligible Reviewer. Do not change identities or disable review checks merely to make a blocked candidate pass.

Keep the affected person, site, candidate and current refusal message in the private handover. Role changes do not resolve printing uncertainty or make an unpublished candidate live. Use [who can do what](/manuals/labels/roles-and-actions) and [release verification](/manuals/labels/examples-and-releases) for the working procedure.