Build a workflow that helps an IT team track a laptop fleet and see which machines are due for a hardware refresh. The goal is to ingest a scheduled device report, work out how old each device's chip is, flag machines that have crossed a refresh threshold, and present the result as a searchable dashboard. Trigger it three ways, as three independent route steps (no step-to-step links) that share one persistent volume for the inventory snapshot: A webhook ingest step — receive an inbound device report via POST from a device-management tool (I used JumpCloud's scheduled device report — or your MDM/inventory source of choice, e.g. Kandji, Intune, Jamf). Use an unguessable webhook auth so the external service can post to it. Parse the report, map each device, derive the chip and its release date from the model string, compute the device's age, and flag each machine as "Due for Refresh" (chip roughly 3+ years old), "Active", or "Unknown". Write the resulting snapshot to the shared volume. A read API step — a space-authenticated GET endpoint that reads the snapshot from the shared volume (read-only) and returns it as JSON. Give it a documented request/response contract. A dashboard step — a space-authenticated React single-page app that is the human entry point. It fetches from the read API and renders summary tiles, a search box, and a colour-coded device table. Store the snapshot in a shared named volume: the webhook step is the single exclusive read-write writer of one snapshot file; the API step mounts it read-only. Make sure draft branches read/write isolated draft data. Keep the refresh threshold and chip release-date mapping in one place so they're easy to edit. The only side effect is overwriting the snapshot file — nothing is pushed back to the external system. Tools used: JumpCloud (scheduled device report webhook), 3B React dashboard, 3B named volume storage