A hand-made target list starts rotting the day you save it. An Inventory collection does not: it is a live question — which PCs have old Chrome right now — and deploying to it means the right machines get the fix today, next month, and after the next hardware refresh, without anyone editing a list.
The Inventory guide in this series introduced the loop in one line — scan, group, deploy, rescan to prove it. This page walks that loop as a deployment workflow: how a collection becomes a target, why the same collection doubles as your proof afterwards, and where the loop honestly breaks if scan data goes stale.
A static list says which PCs needed Chrome last Tuesday. A dynamic collection in PDQ Inventory re-evaluates its filters against the latest scan data continuously: PCs enter when they fall behind and leave when they are fixed. Target a deployment at the collection and the job is aimed by current facts. This matters most for the recurring work — patching staples — where the set of needy machines changes every single week.
Deployment history tells you what PDQ did; the rescan tells you what is true. If the Outdated collection drops from 41 to 3, those 3 remaining machines are a precise, honest work list — perhaps offline, perhaps failing with an error to decode — instead of a vague feeling that patching is mostly done. Reports and audits built on post-deployment collections survive questions that deployment logs alone cannot answer.
Point a recurring schedule — or an Auto Deployment — at the collection and the loop becomes a system: new machines that fall behind join the collection automatically and receive the package on the next run or heartbeat. This is the closest the PDQ pair comes to set-and-forget patching, and it is why the two products are so often bought together even though each works alone.
The loop's one weakness is inherited: a PC that has not scanned recently is judged by old data. It may sit in the Outdated collection after a manual fix, or worse, sit outside it while actually unpatched. The defences are boring and effective — healthy scan schedules, attention to never-scanned machines (the unknown bucket problem the Inventory batch covers), and treating very old scan data as unknown rather than as good news.
Watch the Deploy video for the console mechanics, then run one full loop by hand — scan, group, deploy, rescan — before automating anything.
▶️ Watch Full VideoNo — collections live in PDQ Inventory, so the pair must both be installed and linked. Without Inventory, Deploy still targets computers directly, through Active Directory, or from imported lists; you simply maintain those lists yourself.
Dynamic collections are the right default for recurring work because membership follows scan data. Static collections — a fixed, hand-picked set — suit one-off projects like a department rollout, where the membership is a decision, not a measurement.
Usually the rescan has not happened yet — the collection still reflects pre-deployment data. If a fresh scan still shows them, work the short list: read that target's deployment result and error, and verify the version on the machine itself. The loop turns a fleet problem into a named handful of PCs.