Job Numbering and NAS Provisioning Webhook
A Pipedrive webhook that allocates the job number and builds the client's NAS folder before the salesperson finishes typing.
Every PJL job has a four-digit number and a folder on the Synology NAS built from a template. Doing that by hand meant remembering the last number, typing it into the deal title, creating the folder, copying the template contents in, finding the Drive link and pasting it onto the deal. Five manual steps with several ways to go wrong, and the historical mess proved it: 191 deals needed renumbering and a dedupe script had to untangle duplicate folders.
How it works
Pipedrive posts a webhook when a deal is created. The Worker asks a single Durable Object instance for the next number, so every allocation is strictly ordered, and each deal or project carries an idempotency key so a retried webhook returns the number it already got rather than burning a new one. The deal title is renamed and the 200 goes back to Pipedrive straight away. Folder provisioning then runs in waitUntil: list the clients directory, score existing folders against the deal name, either link to a near-match or create a fresh folder from the template, resolve a Synology Drive file id for a deep link, and write that link onto the deal.
When a project is created from a numbered deal it inherits the number and folder through the deal reference, and the Drive URL deliberately uses the deal's folder name because Pipedrive appends a suffix to project titles that the on-disk folder does not have.
Engineering notes
Defence in depth on the admin surface. A hostname gate in code returns 404 for admin paths unless the host matches an allowlist. Then Cloudflare Access with browser SSO or a service token. Then HTTP Basic with a timing-safe comparison. If the password leaks the service token still gates it, and vice versa. The workers.dev hostname stays enabled because Pipedrive posts there, and admin paths are blocked on it in code. Two service tokens with distinct blast radii separate the Worker's DSM access from the helper scripts' admin access.
Similarity built for the domain. Names are lowercased, split on punctuation, stripped of short tokens and bare numbers, and stripped of a stopword list specific to this business: garden, design, landscape, landscaping, project, client. Every folder contains those words, so they carry no signal. Scoring is intersection over the smaller set, so a short name still matches a longer one.
Graceful degradation. The Drive file-id lookup polls for up to fifteen seconds because indexing on a brand-new folder is slow. On timeout the link is still written without the fragment, and Drive Web still navigates to the path.
Rate limiting in the Durable Object. A sliding-window token bucket with self-cleaning old buckets: sixty requests a minute on the webhook, thirty on admin.
The dedupe script. It runs on the NAS over SSH, groups folders by leading number and surname-like token with union-find, and offers merge via rsync --ignore-existing so the keeper is never overwritten, or quarantine only. Nothing is ever deleted. Duplicates move to a timestamped quarantine folder and the script prints the list of renames the CRM needs afterwards.
Audit trail. A rolling activity log with fifteen typed event kinds (numbered, folder created, folder paired, folder auto-linked, drive linked, inherited, skipped orphan, error and so on) so any allocation can be worked backwards.
Docs
The repo ships an architecture document with sequence diagrams for the new-deal and project-inheritance flows and a security-layers flowchart, plus an operations runbook.
Screenshots
