Manually pushing every Chrome update is a job that never ends. Schedules move PDQ Deploy from “deploy when I remember” to “deploy when it should happen” — and Auto Deployment removes even the remembering. Here is how the two features divide the work, and how to adopt them without handing the fleet to a robot unsupervised.
A schedule stores a deployment — packages plus targets — and runs it at a time, on a recurring pattern, or when a trigger fires. Auto Deployment is a special kind of schedule that watches the Package Library: when PDQ publishes a new version of a package, the new version is downloaded and deployed by itself. Together they are the difference between a deployment tool and a patching system.
A schedule holds three things: the packages to deploy, the targets (computers, groups, or Inventory collections — collections keep the list alive as PCs change), and the trigger — a date and time, optionally repeating daily, weekly or monthly. Schedules are a paid-edition feature; free mode offers Deploy Once only. Attach the schedule to a collection rather than a fixed computer list and the same job stays correct as machines join and leave the office.
Auto Deployment (Enterprise edition) links a library package to a schedule with a twist: the package is set to auto-download new versions as PDQ publishes them, and the schedule deploys the new version when it lands. You can add pre and post steps around it, like any edited package. The fleet effect is large: browsers, PDF readers and runtimes stop depending on anyone's memory, and patch levels across the office converge within days of each vendor release instead of drifting for months.
Paid editions can email the results when a schedule completes. Turn that on from day one — automation without reporting is just unattended risk. The working rhythm most admins settle into: schedules run in the evening, the email lands overnight, and the morning check is two minutes of scanning for red targets. The failures you find are handled with the error decoder in this series, while the other 98 percent of the fleet quietly stayed patched.
Even with Auto Deployment, review the deployment history weekly. Look for targets that fail repeatedly (a sick PC hiding in a green fleet), packages whose versions stopped advancing, and schedules nobody remembers creating. Automation's job is to remove repetition, not attention — the console still needs an owner who glances at it on a rhythm.
The video's scheduling chapter shows the setup in the console — after watching, build your first recurring schedule for one harmless staple application.
▶️ Watch Full VideoNot by itself — an offline target simply misses that run. PDQ answers this two ways: the Retry Queue (Enterprise) automatically retries deployments to targets that were offline, and Heartbeat schedules deploy the moment a target comes back online. For laptop fleets, heartbeat is the pattern that actually works.
No. Auto Deployment follows Package Library packages, whose new versions PDQ itself publishes. Your custom packages are yours to version — when the vendor ships an update, you refresh the package's installer and the schedule deploys the package as usual.
When the PCs are on but the users are not working — early evening is the common office pattern, with a window long enough for the slowest machine. Avoid the morning logon rush, and prefer targets that stay powered (or Wake-on-LAN where your setup supports it) so the schedule meets machines that are awake.