When something happens to a printer, act on it.
An alert, a printer that drops off the network, a new printer that shows up unannounced: PrinterVision notices it, and does what you decided beforehand - mail the right people, restart the printer, apply a profile.
- Trigger Alert raised: ribbon low
- Condition Tag is Dock
- Cooldown Once per hour per printer
- Action Notify users: role Dock team
- Last run Completed
Illustration of an automation in PrinterVision.
A printer alert nobody sees is a line that stops.
Printers tell you a lot - ribbon low, head open, offline - but only to whoever is standing next to them or happens to look at a screen.
For the site manager
What it costs your operation- A printer runs out of labels on the night shift and nobody notices until pallets leave unlabelled.
- The same alert reaches everyone or no one; the team that can fix it is not the team that hears about it.
- Routine fixes - a restart, a profile re-applied - wait for someone with time to do them.
For IT
What keeps coming back- New printers appear on the network and start printing before anyone has checked or set them up.
- A printer that quietly stopped reporting is only missed when someone needs it.
- Scripts that react to printers grow in a corner, without versions, tests or a log.
Draw it, test it, publish it.
An automation is a small flow on a canvas: one trigger, then the conditions and actions you need. Start from a template or from an empty canvas.
Pick what starts it
An alert, offline or online, a restart, a new or discovered printer, a schedule, a printer not seen for a while, a compliance change.
Decide what happens
Add conditions, cooldowns and waits, then the actions: e-mail, a note in the log, or an action on the printer itself.
Test, then publish
Run the draft against past or sample events, then publish it as a new version. Every run is kept in its history.
Two examples.
06:52 - Printer PACK-04 goes offline.
The automation waits ten minutes, then checks with a still true after step: the printer is still offline.
It notifies everyone with the role Packing leads and writes a note on the printer in the operation log. A short network blip would have been ignored.
The first sign is an operator walking over to ask why nothing prints, well into the shift.
10:15 - A scheduled discovery finds printer RECV-09, which nobody added.
New printers need approval, so it stays New: no profiles, files or settings reach it yet. An automation mails IT.
IT approves it. At its next power-up the site's profile is applied, and it prints like every other receiving printer.
The printer runs on factory settings, prints slightly different labels, and is only found when a scan fails.
Everything those examples run on.
Start on anything a printer does.
Every printer event passes through the operation log, and any of them can start an automation.
- Alert raised or cleared, offline, online, restarted, added
- Operation failed or completed, firmware changed
- A schedule: a time and weekdays, optionally for each printer
- New printer discovered, not seen for hours or days, lifecycle or compliance changed
- Event Not seen for
- For 24 hours
- Once per absence
Illustration.
Tell someone, or act on the printer.
Mail the people who can fix it, or let PrinterVision fix it - with a plan for when an action fails.
- E-mail an address, or notify chosen users or everyone with a role
- Restart, send a resource or poll now, on any make
- Apply a profile (Zebra, Honeywell) or set common settings (Zebra, Honeywell, SATO)
- Add or remove a tag; approve, quarantine or retire the printer
- On failure: stop, carry on or retry, with a failure branch of its own
- Step Restart the printer
- On failure Retry 2 times, wait 5 min
- Fails branch Email an address
Illustration.
Every printer has a state, and a say in what it gets.
New, Approved, Active, Quarantined, Retired. A quarantined or retired printer gets no provisioning, and printer actions on it stop.
- New printers need approval before profiles and settings reach them
- Quarantine with a reason, release when it is sorted
- Retire a printer, and remove it from PrinterVision if you like
- Discovered Thursday 10:15
- Approved -
- Provisioning Waiting for approval
Illustration.
Automations that cannot run away.
Drafts and versions, test runs and a history of every run, and guards against loops and repeated failures.
- Edited as a draft, published as a version
- Test runs against past or sample events
- An automation never runs on an event it caused; chains stop after three
- Five failed runs in a row pause it, shown in a banner
- DOCK-07 Completed
- DOCK-02 Failure handled
- DOCK-07 Skipped: cooldown
Illustration.
Common questions about printer automations.
What can start a PrinterVision automation?
An alert raised or cleared, a printer going offline, coming back online, restarting or being added, an operation that failed or completed, a firmware change, a schedule, a new printer discovered on the network, a printer not seen for a number of hours or days, a lifecycle change, or a printer going out of or back into compliance.
Can an automation do something on the printer itself?
Yes, where the make supports it. Besides e-mailing an address or users and writing a note in the operation log, an automation can restart the printer, send a resource, poll it, add or remove a tag, and approve, quarantine or retire it on any make. Applying a profile works on Zebra and Honeywell printers, setting common settings on Zebra, Honeywell and SATO; on other printers those steps are skipped.
How do I know an automation does what I expect before it goes live?
Automations are edited as a draft and published as versions. A test run plays the draft against past or sample events, and the run history is drawn on the graph so you can see which path each run took.
Can automations trigger each other in an endless loop?
No. An automation never runs on an event it caused itself, and a chain of automations reacting to each other stops after three. An automation that fails five runs in a row is paused and shown in a banner.