🔬 Watch vendor sub-processor pages for changes with Groq, Discord and data tables

⚡ 5 views · 🔬 Document Extraction & Analysis

Description

Quick overview

This workflow monitors vendors’ public sub-processor list pages on a schedule or on demand, compares the current page contents against a stored baseline in n8n Data Tables, uses Groq to annotate newly added lines, and posts change alerts or quiet summaries to Discord.

How it works

  1. Runs on demand or every Monday at 08:00 to check all enabled vendors stored in n8n Data Tables.
  2. Loads each vendor’s sub-processor list URL and the existing register of previously seen entry lines.
  3. Fetches each vendor page over HTTP, strips HTML to a capped list of unique text lines, and tags lines that mention configured country keywords.
  4. Compares the current lines to the stored register to detect added and removed lines, flags unreachable pages and suspiciously shrunken pages, and raises critical findings when a newly added line mentions a non-approved country.
  5. Sends only the newly added lines to Groq to extract the company name and country strictly from the text, then merges the annotations back into the findings.
  6. Records the run summary, all findings, and the updated per-vendor register in n8n Data Tables.
  7. Posts a Discord webhook message when the verdict is not UNCHANGED, otherwise posts a short “quiet” summary.

Setup

  1. Add Groq API credentials for the Groq chat model node.
  2. Create a Discord webhook and add the Discord Webhook credential used by both Discord message nodes.
  3. Run the “Set Up Tables (run once)” path to create the sub_vendors, sub_register, sub_findings, and sub_runs n8n Data Tables.
  4. Use the “Add a vendor to watch” form to add vendors, their public sub-processor list URLs, and approved countries, then enable/fix any vendors saved as disabled due to invalid URLs.
  5. Review and adjust the watch policy values (country keywords, entry cap, and shrink ratio) to match your compliance requirements.

Requirements

Customization

Additional info

Your vendors pass your data to their own suppliers, and under Article 28 you are supposed to know who those sub-processors are and be told when the list changes. Vendors publish the list on a public page and are supposed to notify you. In practice nobody checks, and the page changes quietly.

This checks the pages. A form takes the vendor, its public list page and the countries you have approved for it. Check Now or the Monday schedule fetches each page, strips the markup and reduces it to a set of entry lines. The comparison is a line by line set difference against what was there last time: what appeared, what disappeared. Nothing else is parsed, which is deliberate, because a vendor reformatting their table breaks a parser but not a set difference.

Two failures are treated as failures rather than as good news, and this is the part worth reading twice. A page that cannot be read is UNREACHABLE: the register is left untouched and the run is INCOMPLETE, because an outage must never come out as no changes. A page that fetches but returns far fewer entries than the register holds is SUSPECT and its removals are held back, because a login wall or a redesign must not quietly empty your register. When this was tested against a real vendor page holding 204 entries, capping the read at 100 produced exactly that: suspect, removals withheld, all 204 rows still in place.

Only then does a model get involved, and only to describe. It reads the lines that appeared and names the company and the country from the line itself. A country that is not written in the line is discarded, so it cannot invent a data transfer. It never creates, removes or re-grades a finding, and if it fails to answer the verdict from the rules stands.

Runs go to sub_runs, every change to sub_findings, and every entry to sub_register with first and last seen. A new line naming a country you have not approved is the one thing that raises ALERT. Anything not quiet goes to Discord; a quiet run posts a short summary instead, so silence is never ambiguous.

Known limits, stated plainly. The first check on a new vendor records a baseline and reports no changes, which is correct but easy to misread as a clean bill of health. Country detection matches words in the same line, so a page that puts the country in a separate column will rarely trigger it. Some vendors block automated requests entirely. And a vendor reformatting their page will produce a noisy run before the register settles. This is a change detector for public pages, not a compliance sign-off.

🔗 Nodes Used

HTTP Request, Discord, Schedule Trigger, Basic LLM Chain, Structured Output Parser, n8n Form Trigger

📥 Import

Download workflow.json and import into n8n: Workflow menu → Import from File

📖 Importing guide · 🔑 Credential setup