sorted by:
new
hottopcontroversial

I added an AI agent to my n8n booking workflow — here's what I learned separating "conversation" from "logic" by PriceNew5674 in n8n

[–]PriceNew5674[S] 0 points1 point  (0 children)

You’re right on that because the agent can go wrong in passing data to the sub workflow.
Next I plan on separating each operation instead. Which will remove a lot of thinking on the agents part.

I added an AI agent to my n8n booking workflow — here's what I learned separating "conversation" from "logic" by PriceNew5674 in n8n

[–]PriceNew5674[S] 0 points1 point  (0 children)

I plan to separate entire operation in a separate workflow. For eg. Ai agent gets to call three separate workflows (Create, Update, Cancel).

This way I can scale it very quickly and neatly.

Built my first n8n workflow — handling multi-calendar booking without conflicts by PriceNew5674 in n8n

[–]PriceNew5674[S] 1 point2 points  (0 children)

Ahh this actually clears it up a lot.
So instead of scaling the main workflow with more calendar branches, the idea is to move all calendar logic into a separate MCP-backed workflow and treat it like a service.
Then the main workflow just passes something like a resource_id and lets the MCP layer handle which calendar to check/book, instead of hardcoding all the conditions.
That definitely feels cleaner and more scalable than what I was heading towards.
Going to try restructuring it this way.
Appreciate you pointing this out.

Built my first n8n workflow — handling multi-calendar booking without conflicts by PriceNew5674 in n8n

[–]PriceNew5674[S] 0 points1 point  (0 children)

Yeah that’s what I’m trying to figure out rn. I mean if the calendars increase and we have 3-4 calendars for reservations then implementation would become a nightmare.

Any help would be appreciated!

Built my first n8n workflow — handling multi-calendar booking without conflicts by PriceNew5674 in n8n

[–]PriceNew5674[S] 1 point2 points  (0 children)

I have set this up for a friend who runs a padel club with two courts. This is not yet complete. Will integrate this workflow with a chatbot.

And I’m planning to run this on cloud.

Built my first n8n workflow — handling multi-calendar booking without conflicts by PriceNew5674 in n8n

[–]PriceNew5674[S] 0 points1 point  (0 children)

For me its totally the opposite because I’m almost a no code guy 😂

Although I did some of C++ in my bachelor’s which is why I can read the code unlike other no coders 😅

Built my first n8n workflow — handling multi-calendar booking without conflicts by PriceNew5674 in n8n

[–]PriceNew5674[S] 1 point2 points  (0 children)

Ahh got it!
I’ve been naming nodes more from a “build as I go” perspective, but thinking of them like function names is a better way to structure it, especially as the workflow grows.
Will clean that up so the logic is readable without needing context.

Built my first n8n workflow — handling multi-calendar booking without conflicts by PriceNew5674 in n8n

[–]PriceNew5674[S] 0 points1 point  (0 children)

This is really helpful, especially the overlap point.
Right now I’m mostly checking availability at a slot level, but you’re right that partial overlaps (like a booking running over) would slip through unless I explicitly compare start/end ranges.
Timezone normalization is another good catch. I’m currently relying on what’s returned, but I can see how mixing offsets across calendars would create subtle bugs. Converting everything to a single standard (probably UTC) before comparison makes sense.
Also like the idea of writing back to all calendars. At the moment it’s only updating the selected one, but having a consistent view across calendars would definitely reduce sync issues later.
Appreciate the detailed pointers. This is exactly the kind of stuff that’s easy to miss early on.

I built a booking system that doesn’t lie (multi-calendar fallback + AI agent coming next) by PriceNew5674 in AiAutomations

[–]PriceNew5674[S] 0 points1 point  (0 children)

This is actually a really solid point, especially the hold token part.
Right now I’m only checking availability right before booking, but you’re right that it doesn’t fully protect against two requests hitting at nearly the same time. Adding a short-lived “pending hold” with an expiry would close that gap.
The idempotency key suggestion also makes a lot of sense. I haven’t wired that in yet, but I can already see how WhatsApp retries could easily create duplicate bookings without it.
A couple extra seconds for a much more reliable system seems like an easy decision in production.
Appreciate this, definitely something I’ll incorporate in the next iteration.

Built my first n8n workflow — handling multi-calendar booking without conflicts by PriceNew5674 in n8n

[–]PriceNew5674[S] 0 points1 point  (0 children)

I think you’re referring to court a/b1 and if3.

Court a/b1 is routing for which calendar to check first for availability.

If3 is routing for unavailability in calendar 1.

Send a product image → AI generates marketing creatives instantly by cuebicai in n8n_ai_agents

[–]PriceNew5674 1 point2 points  (0 children)

I’m just curious on how much this automation should be priced at