Automate PDQ Connect with workflows

When your account has PDQ Connect connected, workflows can react to what PDQ knows about your Windows computers and act on them through PDQ: deploy a package, restart a computer after school, write a PDQ custom field, or open a ticket. Build them on Admin › Account › Workflows like any other workflow, with Asset as the record. Nothing on this page appears until PDQ Connect is connected.

Every PDQ step goes through PDQ Connect's own checks, the same ones as the buttons on a device's MDM section: what your PDQ API key may do, how many devices one action may reach, and school hours for a restart. Each deployment and restart is on the device's timeline, in the integration log, and, when it's for a ticket, on the ticket.

Triggers#

Choose Asset, On a change, then one of these moments:

| Moment | Runs when | Runs again | | --- | --- | --- | | shows up in PDQ | PDQ Connect syncs a computer for the first time. Computers that were in PDQ before you connected don't count. | Never for the same computer. | | goes missing from PDQ | A full sync no longer finds a computer it synced before (deleted in PDQ). Only while its PDQ connection is still connected. | After it comes back and goes missing again. | | hasn't been seen by PDQ for a while | The computer is offline and its days since PDQ last saw it reach your filter. | After PDQ sees it again. | | has needed a restart for a while | It has needed a restart for the number of days in your filter. | After it restarts. | | is low on disk space | Its free disk drops below the percent in your filter. | After space is freed above it. | | has a new critical or exploited vulnerability | PDQ finds a critical vulnerability on it, or one PDQ marks exploitable or weaponized, that wasn't there at PDQ's last read. | Never for the same computer and CVE. | | has an app that's behind | The app you name is behind its latest version by your filter's versions or days. | After the app is updated. | | finishes a PDQ deployment | A deployment started from schoolOS to it succeeds. | Each deployment. | | fails a PDQ deployment | One fails, partly fails, is canceled or runs too long. | Each deployment. |

The state moments (not seen, restart, disk, app behind) need their threshold as a filter under Match ALL of these, because that's what "runs again" waits on: PDQ: days since last seen, PDQ: days a restart has been needed, PDQ: free disk %, or PDQ: app versions behind / PDQ: app days behind with PDQ: app name. The builder won't save one without it. Two rules on the same moment keep their own thresholds: a warning at 20% free and a ticket at 10% each run once, when each is reached.

PDQ: app versions behind counts at the first part of the version number that differs, so Chrome 128 against 131 is 3, and 1.2.3 against 1.4.0 is 2. An app whose version isn't a number is never called behind. PDQ: app days behind counts from the first sync that found it behind.

When they run#

PDQ triggers are checked when PDQ Connect syncs, not continuously:

• Computers sync on your connection's schedule: every night, every week, or only when someone selects Sync now. "Hasn't been seen for 14 days" and "has needed a restart for 7 days" are checked at each sync, so on a weekly schedule a rule can run up to a week after the day is reached.
• Vulnerabilities are read per computer, each about once every 24 hours, and a sync reads a few hundred computers at most. So has a new critical or exploited vulnerability runs daily at best, and on a large fleet a computer's new vulnerability may take more than a day to show up.
• Goes missing is found by the workflow sweep, which runs every few minutes after a full sync.
• Deployments are followed until they finish, so the deployment moments run a few minutes after PDQ finishes.

There's no trigger for pending Windows updates: PDQ reports the updates a computer has installed, not the ones it's waiting for.

Filters#

Any asset workflow can filter on what PDQ knows about the computer, from its latest sync. On a computer PDQ doesn't manage they're empty, so a threshold never matches it:

• PDQ: operating system, PDQ: group (the PDQ groups the last sync read), PDQ: online, PDQ: last seen, PDQ: days since last seen
• PDQ: needs a restart, PDQ: days a restart has been needed, PDQ: free disk %
• PDQ: worst vulnerability (Critical to None), PDQ: has an exploited vulnerability, PDQ: critical vulnerabilities
• PDQ: app installed (contains an app's name)

The moment a rule runs on adds what it's about: PDQ vulnerability: CVE, PDQ vulnerability: severity and PDQ vulnerability: exploited on a new vulnerability; PDQ: app name, PDQ: app version, PDQ: app versions behind and PDQ: app days behind on an app that's behind; PDQ deployment: package on a finished deployment.

Actions#

| Action | Records | What it does | | --- | --- | --- | | Deploy a PDQ package | Assets, tickets | Installs a package on This device, The ticket's devices, The requester's computers (as PDQ Connect matches them to the person) or A PDQ group. The package is A package you pick, The vulnerability's recommended package, or The update for the app that's behind (the one PDQ package that clearly updates it; none, and the step is skipped). | | Restart with PDQ | Assets, tickets | Restarts the same devices (not a group). Now if it's outside school hours, else after hours, or Right away (skipped during school hours). | | Set a PDQ custom field | Assets, tickets | Writes a value to a PDQ custom field, by its id, on each device. | | Wait for the deployment result | Assets, tickets | After Deploy a PDQ package: when the deployment finishes, solve the ticket or add a note on success, and notify someone or add a note on failure. | | Open a ticket per vulnerability | Assets | On has a new critical or exploited vulnerability: one ticket per CVE. The first computer opens it; every computer found with the same CVE later is linked to it. | | Open a ticket about the device | Assets | Opens a ticket with the computer linked, its subject yours followed by the computer's name and asset tag. One open ticket per rule and computer. |

A deployment's steps read "queued", never "succeeded": PDQ has accepted it, not installed it. When PDQ is at its request limit, schoolOS sends it as soon as PDQ allows, and the step says so. PDQ Connect reaches at most 50 devices with one deployment and 25 with one restart, so a rule's devices are sent in as many requests as that takes; a PDQ group counts as one. For a whole fleet, target a PDQ group. Computers that aren't schoolOS assets (a requester's laptop PDQ matched) can't wait in the queue when PDQ is at its limit, so that step fails with the reason: target the ticket's devices or this device where you can.

Wait for the deployment result#

Put it after Deploy a PDQ package in the same rule. It waits for every deployment that step started:

• When it succeeds: Solve the ticket (the rule's ticket, or the vulnerability's ticket from Open a ticket per vulnerability), and an optional internal note. With a ticket per vulnerability, the ticket is solved only once every computer's deployment has succeeded; until then it stays open.
• When it fails: Notify someone (the ticket's assignee, a team or a person) by email or in the app, and an optional internal note. A deployment that hasn't finished by Count it as failed after (24 hours to start) counts as failed.

The results are added to the run's history, after the steps that started them.

School hours#

PDQ Connect never restarts a computer for a workflow during school hours: 7:30 AM to 3:30 PM, Monday to Friday, in your account's time zone, the same hours the restart button on a device warns about. A person can still restart one computer then; a workflow can't. Now if it's outside school hours, else after hours restarts right away before or after school and on weekends; during school it holds the restart and sends it 30 minutes after school ends. Right away is skipped during school hours, so the next sync's run tries again. Tell people first with Notify a person or team to The Assigned to.

Templates#

On Admin › Account › Workflows, select From a template to start from one. It opens in the editor unsaved: check its filters and who it notifies, then save.

| Template | What it does | | --- | --- | | Critical exploited vulnerability: ticket, fix and follow-up | On a new critical, exploited vulnerability: one ticket per CVE with each affected computer linked, deploys PDQ's recommended fix, solves the ticket when every computer's deployment succeeds, and emails the ticket's assignee when one fails. | | Needs a restart for 7 days: restart after hours | Restarts a computer that has needed a restart for 7 days, after school hours, and emails the person it's assigned to. | | Low disk space: ticket to IT | Opens a ticket to IT when a computer's free disk drops below 10%, once until space is freed. | | New device in PDQ: onboarding ticket | Opens a ticket to set up each computer the first time PDQ syncs it. |

Which should I choose?#

• A district that patches on a schedule in PDQ gets the most from the vulnerability template on exploited CVEs only: PDQ's own schedule handles the rest, and the ticket is there when an attack is in the wild.
• Labs and carts that never get restarted suit the restart template. Without it, updates that need a restart wait until someone restarts by hand.
• Low disk suits a fleet with small drives; a ticket per computer can be a lot on a big one, so filter on a PDQ group first.
• New devices suits a district that enrolls computers in PDQ before they're set up in schoolOS.