n8n workflows

How it runs

1. Ingestion: a PDF arrives on a webhook, is split into overlapping chunks, embedded with a local model, and upserted into pgvector.
2. Query: a question arrives on a second webhook. The retriever pulls the closest chunks and a local chat model writes the answer from them only.
3. Every question, answer and source chunk is written to Postgres before the reply goes out.

What keeps it safe

• The prompt tells the model to answer from the retrieved context only, and to say it does not know when the context does not contain the answer.
• The audit write happens before the response, so a logged answer always exists for anything a user saw.

How it runs

1. A new lead lands on a webhook and is logged in a Google Sheet.
2. The lead gets a WhatsApp message asking for the KYC details. Their reply resumes the run.
3. If the details are complete, a Razorpay payment link is created over HTTP and sent back on WhatsApp.
4. A second webhook receives the Razorpay payment event, marks the row paid and alerts the team on Slack.

What keeps it safe

• An incomplete KYC reply gets a message naming exactly what is still missing, instead of a generic retry.
• The Razorpay webhook signature is verified before any row is changed.
• Payment and status updates key on the Razorpay order id, so a repeated webhook does not double-update.

How it runs

1. An MQTT trigger subscribes to the sensor topic and receives every reading.
2. A code step keeps a rolling window per device and computes a z-score against that device's own history.
3. Only readings past the threshold continue. A local model turns the reading and its recent history into a short incident summary.
4. A switch routes by severity. Critical anomalies create a high-priority Jira issue and ping Slack; the rest create a normal issue.

What keeps it safe

• Baselines are per device and stored in workflow static data, so one noisy unit cannot skew another.
• If the language model is unreachable, the ticket is still created with the raw numbers and a note that the summary failed.
• An error trigger reports any failed execution to Slack. Set the workflow as its own error workflow in its settings to activate it.

How it runs

1. A schedule trigger fires every Monday at 07:30.
2. One Postgres query returns this week and last week per KPI.
3. A code step computes the deltas, so the model never does arithmetic.
4. Claude turns the table into a fixed-structure brief: headline, what moved, what to watch.
5. The brief is filed as a Notion page and a link is posted to Slack.

What keeps it safe

• All arithmetic happens in code and the prompt forbids new numbers, so the narrative cannot contradict the table.
• If a KPI is missing for the week, the brief says the data is missing instead of filling the gap.

How it runs

1. A Gmail trigger picks up each new inbound email.
2. A classifier labels it by route, urgency and compliance flag, and returns a confidence score.
3. Low confidence, or any compliance flag, skips drafting and goes straight to a person with a label.
4. Otherwise a model drafts a reply into Gmail, and Slack asks a reviewer to approve or reject it.
5. Only an approval sends the email.

What keeps it safe

• Nothing is sent without an explicit approval, including when the classifier is confident.
• The low-confidence path exists so an uncertain classification is routed to a person instead of being guessed.
• Approval requests expire after four hours, so a draft cannot sit waiting indefinitely.

How it runs

1. Razorpay posts a payment event to a webhook, and the signature is verified first.
2. The order is upserted in Postgres and the supporter's history is read back.
3. A switch segments them: first-time, returning, or a larger gift.
4. Each segment gets its own WhatsApp message, with an email as the fallback when no WhatsApp number is on file.
5. On the WhatsApp path, a wait node resumes three days later and sends a short follow-up.

What keeps it safe

• The signature check runs before anything is written, so a forged request changes nothing.
• Supporters are upserted by email, so a repeated webhook does not create a duplicate supporter.
• The email fallback means a supporter without WhatsApp is still acknowledged.

How it runs

1. A schedule runs every morning.
2. One branch pulls yesterday's spend per campaign from the Meta Marketing API over HTTP; the other pulls conversions per campaign from GA4.
3. A merge joins them on the campaign name.
4. A code step computes cost per conversion and flags campaigns above their target.
5. Rows are upserted into Postgres, and any flagged campaign is posted to Slack.

What keeps it safe

• The join is on the exact campaign name, so a renamed campaign drops out of the join visibly instead of merging into a different one.
• Cost per conversion is computed in code from the two sources, so the Slack flag and the stored row always agree.

How it runs

1. A schedule runs hourly.
2. Three Postgres queries measure freshness (minutes since the last row), null rate on key columns, and duplicate keys.
3. A merge collects them and a code step compares each against its threshold.
4. If any check fails, Claude writes a short plain-language summary of what broke and what depends on it.
5. The summary goes to Slack and opens a Jira issue. Every run, pass or fail, is logged to Postgres.

What keeps it safe

• Every run is logged, so a monitor that stopped running is itself detectable by a missing row.
• The model only summarises failed checks. Pass or fail is decided in code with fixed thresholds.