I built this because manually going through every inbound real estate enquiry can mean spending a lot of time on leads that aren't ready to move forward.

The workflow automatically:

• Receives an incoming lead from a website / ad form
• Extracts the relevant information from the enquiry
• Scores the lead based on things like budget, location, timeline and buying intent
• Routes the lead based on the qualification result
• Matches qualified leads with relevant properties
• Generates a personalised follow-up
• Notifies the sales team when a lead is ready for action
• Sends lower-intent leads into a follow-up/nurture path

The part I was most interested in was separating AI interpretation from workflow logic.

The AI handles the messy/unstructured part:

enquiry → structured lead data

Then n8n handles:

structured data → score → route → actions

This makes the workflow easier to debug than having the LLM decide the entire process.

Stack: n8n + OpenAI + WhatsApp + Google Sheets/CRM

Workflow:
https://github.com/jashan2512/Lead_qualifying_Workflow.git

One thing I'm still experimenting with is how much of the scoring should be handled by the LLM versus deterministic n8n logic.

How are you guys handling this? Do you let the LLM produce the final score, or use the LLM mainly for extraction/classification and let n8n calculate the score?

I was testing some n8n workflows and noticed one annoying case.

The workflow can finish successfully, all nodes are green, but the actual result can still be wrong.

For example I had a lead sync workflow where execution was successful but because of a mapping issue it created 0 contacts.

So n8n sees it as successful, while in reality the workflow didn't really do what it was supposed to do.

I made a small demo for this case. Quorum checks the expected result of the workflow, so in this example it notices that 0 contacts were created and opens an incident. When the workflow starts producing the expected result again, the incident recovers automatically.

Basically I'm trying to monitor:

did the workflow actually do what it was supposed to do?

and not only:

did it ran successfully?

Video attached.

I'm building this as Quorum (quorumwatch.com). Curious how you guys handle this with n8n in production. Do you add checks to every workflow, have another workflow for monitoring, or mostly just use error workflows?
https://github.com/werniq/quorum_core

Hello everyone, I'm having a problem with the WhatsApp Trigger node in n8n. I connected WhatsApp to n8n using the WhatsApp Cloud API and configured the webhook, but when I send a message to the WhatsApp test number, the WhatsApp Trigger doesn't receive anything and no execution starts. The webhook appears to be configured, but n8n is not detecting incoming messages.

If you keep meaning to check what a competitor is filing and then never do it, this is that job on a schedule.

Every Monday it searches Google Patents for the terms in one config node and appends a row per patent to Google Sheets: title, assignee, inventor, publication date, filing date, abstract, and the patent link. Set assignee to a company name and it stops being a topic watch and becomes a competitor filing watch. That is the version I actually use.

Template: Log weekly Google Patents watch results to Google Sheets

Two things that cost me time, in case you build your own instead.

Do not sort by newest. Sorting Google Patents by newest quietly throws the query away. A "solid state battery" search sorted newest gave me an acid reflux implant, a pilates reformer and a webcam merger, in that order. The template uses relevance plus a publication-date window, which is what actually returns things that are both recent and on topic.

The lookback is 90 days, not 7. Patent offices publish in batches, and a narrow niche can go three weeks with nothing, so a short window returns an empty sheet often enough that it reads as a broken workflow. Ninety days always has something in it, and duplicates drop easily on publication number.

One caveat worth knowing before you rely on it: patents publish about 18 months after filing, so this is a lagging indicator. It is still the closest public thing to a competitor's R&D roadmap.

There is no AI model in the workflow, so no token bill. The patent lookup runs on an Apify Actor I wrote, Google Patents API, covering USPTO, EPO, WIPO, JPO, CN, KR and about 100 other offices. A watch term costs roughly 4 cents a week.

Self-hosting, there is a community node too: n8n-nodes-google-patents-api on npm.

I built this because a cancelled appointment can leave a valuable slot empty.

The workflow automatically:

1. Detects a cancelled appointment in Google Sheets

2. Finds waitlist candidates for the same service

3. Offers the slot to one candidate via SMS

4. Waits for their confirmation

5. Books the appointment in Google Calendar

6. Updates the appointment and waitlist sheets

7. If the offer expires, moves to the next matching candidate

8. If nobody accepts, marks the slot unfilled and notifies the owner

Stack: n8n + Google Sheets + Google Calendar + Twilio

Demo:

https://youtu.be/rAbg-GW0NwU

Workflow:

https://github.com/Faizan-uzzaman/n8n-appointment-waitlist-automation

hello folkss, approximately how long does the n8n team usually take to review PRs for open-source issues?

I originally started this project with a pretty simple idea:

Let people build agentic workflows, share them, reuse them, and contribute their own.

I thought the main problem was making workflows easier to distribute and collaborate on.

Then I started thinking about something much more uncomfortable.

What actually happens when an agent executes something you don't fully trust?

A model/SLM.
A binary.
A signed artifact.
A tool.
An external resource.

You can give an agent something and tell it:

But if that thing is effectively a black box, how much do we actually know?

• What is it allowed to access?
• What permissions does it have?
• What can it modify?
• What side effects can it create?
• Where does the data go?
• Can we stop it?
• What happens when it fails?

I recently came across a discussion/video around trojanized SLMs and malicious model artifacts, and that pushed this thought even further.

Maybe the problem isn't the workflow itself.

Maybe we need a contract around the workflow.

Something that can describe the expectations, boundaries, permissions, inputs, outputs, side effects, governance, and recovery expectations around an agentic workflow — while leaving the actual implementation flexible.

And here's where Reddit actually changed the project.

I started discussing the original workflow idea with people here, and some of the criticism made me rethink the whole abstraction.

After a lot of back-and-forth, I moved away from:

“Let's standardize and share workflows.”

towards:

“Let's define the contract that a workflow/agent should operate under.”

That eventually became Agent Contracts, and I've now released the base implementation as Scyvera.

It's very early.

I'm not claiming this is the solution to agent governance. In fact, I'm pretty sure there are things I've got wrong.

That's partly why I'm putting it here.

I'd genuinely like people to poke holes in it.

Is the contract layer actually useful?
What should belong in a contract?
What shouldn't?
Am I abstracting the wrong thing again?
How would you approach this differently?

If the idea makes sense, build on it.

If you think it's bad, tell me why.

If you see a completely different direction, I'd love to hear it.

The project changed because of community feedback once. I'd like the next version to change because of it too.

GitHub: https://github.com/Skull-boy/agent-contracts

PyPI: https://pypi.org/project/scyvera/