Print Restrictions

A print restriction stops one person’s jobs going ahead for a set period. It carries a reason they can read, a date it ends, and a record of what happened before — so a second incident can cost more than the first without anyone having to remember that it is the second.

Restrictions are managed under Admin → Print restrictions, and issued from a person’s page under Users.

Four different questions#

Pluraprint has four things that can stop someone printing, and they answer different questions. Reaching for the wrong one is the most common mistake here.

If you want to…	Use
Stop someone printing for a while, then let them back	A print restriction
Stop someone signing in at all	Disabling their account (Users)
Decide what someone is allowed to do in Pluraprint	Roles (Roles & Permissions)
Require something of a job before it prints	A rule (Building Rules)

A restriction is about a person and a period. Disabling an account is broader — they cannot use Pluraprint at all, including to see why. A role is about permissions, which is a different thing from a temporary consequence: a role has no reason, no end date, and no memory of how many times this has happened.

What a policy decides#

You do not restrict someone “for three weeks”. You restrict them under a policy, and the policy works out the length from what has happened before.

A policy has:

• A category — the kind of incident, such as uncollected prints or safety. Repeats are counted per category, so two policies sharing one escalate together.
• An escalation ladder — how long each repeat lasts. Steps can skip numbers: a ladder with steps at the 1st and 3rd incidents means the first two cost the same.
• A window — how far back to count. Someone who mislaid one print three years ago should not be permanently one step further up the ladder than a first-timer.
• Whether staff can let a single job through — and which roles may do it.
• What the person is told — a default reason, and the notification they receive.

The editor shows what the ladder would do to someone with a clean record, so you can read the consequence before you save it.

The category cannot be changed later#

Repeats are counted by category. Changing it on an existing policy would put everybody who already has incidents under the old one back at the start of the ladder, so Pluraprint does not allow it. Retire the policy and write a new one instead.

Restricting someone#

Open the person under Users, find the Print restrictions card, and choose Restrict.

Pick a policy and Pluraprint immediately shows what it would mean for this person — “this would be occurrence 2: restricted for 42 days” — before you commit to anything.

You can write:

• A reason, which they see on every job it blocks. Leave it empty to use the policy’s own wording.
• A staff note, which they never see and which is never written to the audit log. This is for context other staff need.

What a restriction does#

While a restriction is in force:

• Their jobs will not queue, and queued jobs will not dispatch.
• The job’s checklist says why, in the words you wrote.
• A print already on a machine keeps going. A restriction stops the next job; it does not reach into a running print and abandon it halfway.

It does not disable their account, change their roles, or affect anything they have already collected.

Letting one job through#

Where a policy allows it, staff can allow a single job despite the restriction. On the job’s approval page, an Override control appears above the checklist with the reason the job is blocked.

This is deliberately its own control rather than part of approving the job:

• It covers that job only. The restriction stays in force for everything else they print, and its end date does not move.
• It requires a written reason, recorded against the job and in the audit trail with your name.
• Approving a job on its merits does not override a restriction, and neither does any general administrative override.

A policy can require specific roles to grant it, and by default someone cannot override a restriction on their own job.

Ending one early#

Choose Lift on the restriction. They can print again straight away.

If the record is genuinely wrong — the wrong occurrence, the wrong end date — that is a correction rather than a lift, and it is separately recorded with the reason for the change.

Restrictions that end by themselves#

Almost all of them do. When the end date passes, the person can print again immediately — there is nothing to run and nothing to remember. They get a notification shortly afterwards telling them so.

Restricting people automatically#

An automation rule can issue a restriction, which is the point of the whole feature: “email at two weeks, restrict at four” written once as a rule rather than as a job somebody has to remember to do.

Add the Restrict them from printing effect to a rule and choose a policy. The rule does not choose a duration — the policy’s ladder does, counted from that person’s own history.

Like the role effects, it waits for someone to confirm it unless the rule is explicitly set to apply sensitive effects automatically. It fires once per print, however often the rule runs, and undoing the automation lifts exactly the restriction it created.

See Automation Rules.

Who can see and do what#

Permission	Allows
View	See who is restricted, why, until when, and what happened before — including staff notes
Restrict	Stop someone printing under a policy
Lift	End a restriction early, or correct a recorded incident
Override	Let one job through where the policy allows it
Manage policies	Write the escalation ladders

The person who has been restricted always sees their own reason and end date on the blocked job — they need it to know what to do. They do not see staff notes, and they do not see anyone else’s restrictions.

At a station, staff can hold View and Override, so someone at a counter can say why a print will not go and let that one print through. The kiosk asks them to identify themselves first — an override is a judgement somebody has to own, and “station 7 allowed it” is not something anyone can review afterwards.

Restricting and lifting are deliberately not available at a station: those are decisions about somebody’s next several weeks, and they belong where the record names a person rather than a shared screen.

Moving from a “Banned” role#

If you currently stop people printing by adding them to a role like Banned, that keeps working exactly as it does today. Nothing is converted automatically, because only you know what your role names mean.

When you are ready to move, the difference is worth knowing:

• A restriction ends by itself. A role needs a second rule to take it away, and that revocation can fight with anything else that granted the same role.
• A restriction remembers. The second incident can cost more than the first without you tracking it.
• A restriction explains itself to the person, on the job it blocked.

A reasonable migration is to write a policy, point new automation rules at the restriction effect instead of the role effect, and leave the old role in place until nobody holds it.