n-monday.com's Automation Recipes, and Where They Run Out of Room
A monday.com automation, what the platform calls a recipe, watches for a trigger (a status changes, a date arrives, an item is created) and runs an action (notify someone, change a column, move the item) entirely within your boards. They're genuinely useful for the simple, same-board case. Past a monthly action cap, a subitem that the recipe can't see, or a condition that needs information from outside monday.com, that's where our work on top of it starts.
What a recipe actually handles
Recipes come from a template library (auto-notify, auto-move, auto-assign) or a custom builder with the same trigger-condition-action structure. They run per-board by default, though you can scope some to run across a group of connected boards. There's no code involved, which is exactly why they're easy to set up and exactly why they stay limited to logic monday.com itself can already see.
Every plan caps how many automation actions you can run per month, scaling up with the tier. Hit the cap and recipes stop firing until the next billing cycle, which catches teams off guard mid-month more often than you'd expect from a feature this central to the product.
Subitems, the nested rows under a parent item, get their own, more limited set of recipe triggers than top-level items do. Several real searches land specifically on this: people building a recipe that should fire when a subitem's status changes discover the option set is narrower than it is for the parent row.
Where a recipe can't see far enough
A recipe can react to anything already sitting in a monday.com column. It can't check whether a customer's credit is actually clear, whether a part is actually in stock, or whether an approval that lives in a different system has actually happened. The recipe will happily move an item to "Approved" on schedule even if the real-world condition behind that status is false, because monday.com genuinely has no way to know otherwise.
There's also no API to build or edit a recipe's actual logic (the monday-crm-api page above covers monday's GraphQL API in depth). Recipes get built by clicking through the automation center, one board at a time. Replicating the same recipe structure across dozens of boards, or updating it after a template change, is a UI-only job unless someone automates that UI directly, which is exactly the kind of work we do through browser automation when there's no other path in.
What We Build Past the Recipe Library
A status gate that checks the real world first
Before an item can actually move to "Approved" or "Shipped," we run the external check, a credit hold, a stock count, a signed document, so the status reflects what's actually true instead of what a recipe assumed.
The same recipe, replicated across every board that needs it
When a client needs an identical automation pattern rebuilt across dozens of boards and there's no API to do it programmatically, we drive the automation center the same way a person would, just a lot faster and without the copy-paste errors.
What recipe have you hit the action cap on?
If a monthly limit is throttling something that actually matters to your operation, that's worth a second look at how it's built.
Running into monday.com's automation action limits, or a recipe that can't see far enough?
Tell us what the recipe is supposed to do and where it stops working, a monthly cap, a subitem it can't react to, a condition that lives in another system entirely. We'll scope what it takes to build past that. Automations on monday.com are one example; n-frames does this for whatever's still manual in your business.
Let's talk