Enterprise browser extension for a vendor portal

A monthly business process required sending a contract email for every active program in a partner's legacy contract portal: a frame-based ColdFusion app whose detail views open as popups and whose program list renders in a virtualized AG-Grid. Doing it by hand means clicking through every program one at a time, and the emails are irreversible once sent.

The tool is an Edge/Chrome Manifest V3 extension that drives the whole run from inside the operator's already-authenticated browser session: scan every program, dry-run the recipient resolution, then send in supervised batches with a per-program run report.

Why an extension

Earlier iterations automated this with browser-driving tooling. The extension rebuild was a deliberate security and operations call:

• No credential handling anywhere The user logs into the portal themselves; all network I/O runs in the portal's own tab via chrome.scripting, so every request is first-party and carries the live session cookies. No passwords stored, relayed, or proxied.
• No backend to run Nothing hosted, nothing to patch, no server-side secret surface.
• Deploys like software, not like a script Distributed through browser policy via Intune to exactly the people who run the process.

Reverse engineering

The portal's working content lives in a named frame and its detail views open as popup windows that browser-automation panes can't surface, so the extension drives the grid's API and direct URLs instead of clicking. The program list is virtualized (~50 of N rows in the DOM at any time); the full list is read through the AG-Grid component API. Per program, the extension fetches the detail page, scrapes the server-generated email link (the IDs can't be constructed), parses the compose form, and posts it, verifying success from the response. The whole flow is documented as a maintained mechanism reference.

Guardrails for irreversible actions

• Dry run first Resolves and displays where every email will go; nothing sends until confirmed.
• Explicit recipient selection The operator chooses the recipient mode; nothing is inferred silently.
• Supervised batches Each batch is a human click (which also sidesteps MV3 service-worker recycling on long runs).
• Run report Per-program sent/failed status, downloadable as CSV.

Self-hosted release pipeline

No public store: the whole release is one git tag. A GitHub Action derives the version from the tag and stamps it into the manifest, packs and signs the .crx with a CI-held key (which defines the stable extension ID across releases), generates the auto-update manifest, and publishes both to Cloudflare R2 behind a CDN domain. Installed browsers update silently. Intune force-installs the extension on both Edge (Settings catalog) and Chrome (ADMX ingestion), locked down with ExtensionSettings (allowed hosts scoped to the vendor's domain) and assigned to a dedicated runner group rather than the whole org.

What it demonstrates

• Security-first architecture selection Choosing session-reuse over any form of credential storage or relay, and eliminating the backend entirely.
• Reverse engineering legacy vendor software Frameset apps, virtualized grid internals, and undocumented form flows, reconstructed and written down so the next maintainer isn't starting over.
• Safe automation of irreversible actions The same dry-run / explicit-confirm / supervised-batch philosophy as my AI ops platform, applied to a browser tool.
• Enterprise distribution engineering CI-signed self-hosted releases with stable-ID key management, an auto-update channel, and policy deployment across two browsers.