Pickup
Chasing Uncollected Prints
Rules that email, restrict, or clear out prints nobody comes for.
Some prints are never collected. Pickup lets you decide what happens about that, as rules rather than as a standing instruction to whoever is on the desk.
Rules live on Settings → Automation, alongside every other automation rule. Filter the trigger list to the pickup ones.
The three moments you can react to
| Trigger | When it runs |
|---|---|
| A print has been waiting to be collected | On a schedule you set on the rule, over everything still waiting. This is the one to use for “email at two weeks”. |
| A waiting print is seen during a bin check | Each time somebody scans a print while walking the shelves. |
| A waiting print is collected | When somebody finally takes it: scanned at a counter, marked collected from the list, or found gone at a bin check. Use this to undo what an earlier rule did. |
What you can condition on
Waiting time, how many days overdue, the current status, which bin, how long since anybody actually saw it: plus everything you already condition on elsewhere: who the print belongs to, what roles they hold, the print’s size and cost, and the time of day.
What you can do
- Send a notification to the owner.
- Add or remove a role: for instance moving somebody into a restricted group. Needs approval unless you turn that off.
- Mark the print abandoned. A label, not a lock. It can still be collected.
- Record the print as disposed of. Final, and it is somebody’s work, so it needs approval unless you turn that off.
- Give them longer to collect.
A ladder, not a first match
Pickup rules are set union: every rule whose conditions hold contributes what it says. So “email at two weeks” and “restrict at four weeks” are two rules, and at four weeks both are true. The person gets the email and the restriction.
That is on purpose. The alternative (first match wins) would silently swallow the email rule the moment the restriction rule started matching, which reads correctly in the editor and is wrong in practice.
Each rule fires once per print, ever. A rule that checks every six hours still emails once.
Each rule says how often it runs
A print has been waiting to be collected does not fire when something happens: there is no moment at which a print becomes three weeks old. It is a standing question, so the rule itself says how often to ask it: Check every ___ hours, right under the trigger.
This is per rule, on purpose. “Chase the owner every 12 hours” and “clear out the remains once a month” are both reasonable, and one shared schedule could express neither. It also means the answer to when will this rule run? is on the same screen as the rule, rather than on a settings page you would have to know existed.
Checking more often makes a rule act sooner. It never makes it act more than once.
When bin checks record collections
If When a check cannot find a print is set to Assume it was collected, Pluraprint does not penalize someone merely because the collection deadline passed while the database still says their print is on the shelf. They may have collected it on time, with the next check not yet completed. Overdue waiting rules act only after a bin check sees the print at or after its deadline. If the check finds it gone instead, the inferred collection is treated as on time unless an earlier post-deadline sighting proves otherwise.
When collections are scanned or recorded as they happen and an absent print is instead flagged as missing, the recorded state is current, so overdue rules can act as soon as the deadline passes.
Watching before it bites
Turn on Test mode on the rule, and leave it on for a week.
A rule in test mode is evaluated normally and you can see exactly what it would have done: beside each scan during a bin check, and on the rule’s own page, but nothing is emailed and nobody’s access changes. Turn test mode off when you are happy with what you are seeing.
Test mode is per rule rather than a switch covering all of pickup, so a policy you already trust keeps working while you try a new one beside it.
You can also preview a single rule from the Automation page: against today’s data, this would email 14 people and restrict 3. Nobody should find out about a mis-set threshold from the help desk.
Approval before anything serious
Anything that changes a person’s access, and anything that destroys their work, writes a pending approval rather than acting. Somebody confirms it from the Automation page. You can turn that off per rule once you trust it.
Undoing a restriction when the print is finally collected
Write a second rule on A waiting print is collected that removes the role. Whether a restriction should lift when somebody eventually turns up is a decision about your policy, not about the software: the material was already used either way, so Pluraprint gives you both and does not choose.