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.
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.
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 (see our monday.com CRM API page for what monday's GraphQL API does cover). 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.
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.
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.
If a monthly limit is throttling something that actually matters to your operation, that's worth a second look at how it's built.
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 →It depends on your plan tier, with higher tiers getting a larger monthly action allowance. Once you hit the cap, recipes stop running until the next billing cycle, so it's worth checking your usage before you build something mission-critical on top of them.
Yes, through a recipe like "create a new item every week" from the template library. It handles a fixed schedule well. The moment the recurrence actually depends on something variable, how often a client reorders, when a project phase genuinely finishes, that falls outside what a fixed recurrence recipe can do.
Subitems get a narrower set of recipe triggers and actions than top-level items. If the automation you're trying to build isn't showing up as an option for a subitem, that's usually why, not a bug in your recipe.
No. monday's GraphQL API can read and write board data, but recipe logic itself, the triggers, conditions, and actions, only gets built through the automation center's UI. There's no endpoint to script a new recipe into existence.
Notifying someone on Slack or by email when a status changes, moving an item to a different group when a date arrives, auto-assigning a person when a status flips, and creating a new item on a recurring schedule. All of them run on logic entirely inside your boards.