Run a recipe on a schedule, without being there

The situation

You have a job that works when you sit down and ask for it. Yesterday's email into the CRM. The Monday pipeline pass. A monthly sweep for accounts that have gone quiet. You want it to happen without you, and every other CRM you have used had a screen for that.

Start with the honest answer

Indraft will not run your job on a timer. There is no screen where you set a time and no plan on which one appears. It holds records, it enforces who may change them, and it keeps the account of who said what. Doing the work is somebody else's job, and that is the point.

There is one thing it will do on a clock, and it is deliberately small. You can leave a standing question: how many records match this filter, asked every so many hours, and say something when the count goes above a number you set. It reads and it reports. It writes no record, it has no branches, and it takes no action on what it finds, so it is closer to a smoke alarm than an automation. The cadence is a number of hours rather than a calendar, so "every Monday at eight" is not something it can express.

Use that to be told six accounts have gone quiet. Use the rest of this recipe to do something about them.

The schedule lives with whatever calls Indraft. That is a real answer rather than a missing feature, and it is the same reasoning as the dividing line between an agent and an automation: the tools that run things on time are already good at it, and the ones you already have are probably better at it than a screen we would build.

So the question is which of them you point at it, and that depends on the job.

If your agent is Claude

Claude can run a task on a recurring schedule on every paid plan, and the cadence choices are hourly, daily, weekdays, weekly, or on demand. Two things make it usable for CRM work.

• It runs remotely. The task fires on its cadence with your laptop shut, which is what separates a schedule from a reminder to yourself.
• Your connected tools come with it. A scheduled run has the same connectors a normal conversation has, so if Indraft is connected when you talk to it, Indraft is connected when the schedule fires.

The exception worth knowing before you rely on it: a task that needs something on your own machine runs locally instead, and a local task does not fire while the machine is asleep. Reading a mailbox through a connector is remote. Reading a folder on your laptop is not.

If your agent is ChatGPT

ChatGPT also runs scheduled tasks, and connected apps work inside one, so a task can reach Indraft the same way you do. The differences that matter in practice are the bounds.

• Once an hour is the floor. Nothing runs more often than that, which is fine for every job in this cookbook and worth knowing before you design around minutes.
• You get a handful of active tasks, and how many depends on your plan. This is the one that bites: people wire up six jobs and find the seventh will not save.
• Tasks pause themselves if you ignore them. A daily digest you never open will eventually stop arriving, which looks exactly like a broken integration.

A Custom GPT is not available inside a scheduled task. If you have put your CRM instructions in one, the schedule will not have them, and you want that prompt written into the task itself.

What neither of them will do

Both are schedulers in the plainest sense, and it is worth being precise about what that leaves out, because the gap is where people get hurt.

• They fire on time, never on an event. Neither can run because a deal moved. If you want that, you want a webhook, and it is a different mechanism with different failure modes.
• A failed run is a quiet run. If the model is busy, the connector is down, or the answer comes back wrong, nothing retries and nothing tells you. Tuesday simply did not happen, and you find out when you go looking.

The question that decides where the schedule lives

Ask what a missed run costs you. It sorts every job in this cookbook into two piles, and the piles want different tools.

• A missed run costs you a message. The Monday pipeline summary, the quarterly prep, the monthly nudge about quiet accounts. You notice the absence, you ask for it by hand, nothing is lost. Put these on your agent's own scheduler and stop reading here.
• A missed run costs you data. Capturing yesterday's email is the clearest case. Miss Tuesday and Tuesday's conversations are not in the account, and no later run goes back for them unless you make it. These want a tool that retries and tells you when it gave up.

That second pile is small. Most of what you want on a timer is a reading job, and a reading job is exactly what an agent scheduler is for.

Wiring the second kind, without writing code

Any automation tool that can call a URL on a schedule will do, and you probably already run one. Make and n8n are the two people reach for, and the four pieces below are the same in both. There is no Indraft app in either library, so do not go looking for one: the Indraft side is a plain HTTP call, which both tools have a module for.

1. The schedule itself. A scenario's scheduling settings in Make, a Schedule Trigger in n8n. This is the screen Indraft does not have, and you already own it.
2. The call into Indraft. Two choices, and the right one depends on whether the step needs judgement.
3. Retry on failure. Both tools can retry a step that failed, and in both it is something you turn on rather than something you get. Turn it on for the step that writes.
4. Somewhere the failure goes. An error handler in Make, an error workflow in n8n, pointed at a channel somebody reads. This is the piece the agent schedulers cannot give you and the whole reason this pile of jobs lives here instead.

When the job has no judgement in it

Use the HTTP module: HTTP, make a request in Make, the HTTP Request node in n8n. Bearer authentication, your API token, done. "List every company with no interaction in sixty days" is the same question every time and has one right answer, so there is nothing for a model to decide and no reason to pay one.

Give that token only the scopes the job needs. A reading job holds a reading token, so a workflow somebody edits later cannot start writing.

When the job needs an agent to decide something

Some automation tools can hold an agent themselves, and then the scheduled run gets to decide things rather than following a fixed list. n8n does this with its MCP Client node, which connects to an external MCP server with bearer authentication. Point it at the Indraft endpoint, which speaks streamable HTTP:

Now the workflow has the same tools your agent has, on a timer you control, with retries around it. That is the combination neither piece gives you alone: the scheduler that reports failure, holding the tools that can read a message and decide who it was from.

If your tool has no way to speak that protocol, you are not missing anything you cannot have. Every one of those tools is a route on the API, so the same work is available over plain HTTP; what you give up is an agent choosing which one to call, and for a job you already understand well enough to schedule, you were usually going to choose anyway.

Why running twice is safe

Schedules overlap. A retry fires while the first attempt is still going, a backfill covers a day you already have, somebody clicks the button by hand. In most CRMs that is how you get two of everything, and it is the reason people are frightened of automating writes.

Indraft is built to be re-run. An interaction carrying the provider and the message id it came from is the same interaction on the second pass, not a second copy of it, and every write accepts an idempotency key so a retried call lands once. You can point a nightly job at a week and let it overlap for six days on purpose.

The second pass over a message says so, and points at the record it already made rather than making another:

That overlap is the cheapest insurance available against the quiet failure. If Tuesday did not run, Wednesday covers it, and you did not have to notice.

Verify it

• Ask what changed while you were away. The history is the answer to "did the job run", and it does not need a monitoring stack. Ask your agent for the changes since yesterday and look at who made them.
• Break it on purpose. Put a wrong token in the workflow and let the schedule fire. If nothing reaches you, your error workflow is decorative and you will learn that during a quarter close instead.
• Shut your laptop. The whole point is that it runs without you. A task that quietly needs your machine awake is a task that stops on the first day of your holiday.

Run it again

Once a quarter, look at what is still scheduled. Agent schedulers pause tasks nobody opens, automation tools keep running workflows nobody reads, and both failures look like a quiet week. The jobs worth having are the ones you would notice missing, and the rest are worth turning off.