Triggers and schedules

A network is only as useful as the moment it runs

The blocks inside a network handle what the workflow does. Triggers handle when. And the right trigger turns a useful network into a habit-forming one.

A Monday-morning briefing that runs every Monday morning at 7 a.m. doesn’t ask anyone to remember it. A customer-intake network that runs the moment a new account is created doesn’t sit in someone’s inbox waiting for them to click. A compliance review that fires whenever a contract is uploaded doesn’t depend on a person noticing.

This page is the tour of the trigger types.

The four trigger types

Manual run

The simplest trigger and the right default while you’re still finding the shape of a workflow.

You open the network, fill in the inputs, click Run. The network executes. You watch the result.

When manual is the right call

• The inputs vary every time. A network that takes “the customer name” or “the URL to research” needs someone to type it in.
• You’re still iterating. Until the network produces consistent results, scheduling it doesn’t help — you’re not going to trust the output yet.
• The output requires a human to decide what to do next.

What manual runs look like in practice

The most common pattern: a small, useful network that lives in someone’s toolkit. They run it three times a week, paste the result into Slack or a doc, and move on. The lightest possible automation — just enough to save the manual work each time.

Scheduled run

When a network runs on a regular cadence, give it a schedule and stop thinking about it.

You pick the frequency:

• Every hour. Useful for fast-moving things — monitoring, alerting, status checks.
• Every morning. The classic morning briefing pattern.
• Every Monday. Weekly reports, weekly retros, weekly stand-ups.
• The first of every month. Monthly reviews, monthly invoices, monthly compliance checks.
• A custom cadence. Whatever pattern fits your team’s rhythm.

You also pick where the result goes — email, a Slack channel, a shared doc, a folder in Data — so the output lands where someone will see it.

When scheduled is the right call

• The output is useful at predictable moments.
• The inputs are stable (or they pull themselves from a connected source).
• The workflow has proven itself enough that you trust it without human supervision.

A short scenario

The “Monday CS digest” network runs every Monday at 6 a.m. It pulls from the customer-success team’s Confluence space, the past week’s Salesforce updates, and the past week’s support tickets. It produces a digest and posts it to the team’s #cs channel. By the time the team is online, the digest is waiting.

Webhook trigger

A webhook trigger lets another tool start a VDF AI Network. The other tool POSTs a small message to a URL VDF AI Networks provides; VDF AI Networks reads the message and starts the network.

In practice this means:

• A help-desk tool can fire a network whenever a new ticket arrives.
• A form builder can fire a network when a new submission lands.
• A CI/CD system can fire a network when a build fails.
• A CRM can fire a network when a deal moves to a new stage.

You give the other tool a URL. You decide which inputs it passes through. The network starts the moment the message arrives.

When webhook is the right call

• An action somewhere else should kick off work here.
• The reaction needs to be fast — minutes, not hours.
• The triggering tool already exists and you don’t want to add a “go run the network” step to someone’s mental checklist.

A short scenario

A vendor-intake network is webhook-triggered. When a new vendor record is created in the procurement tool, the procurement tool fires a webhook. The network runs an intake review — security questionnaire summary, financial check, fit assessment — and posts the result back to the procurement tool. The vendor’s intake doc is half-written by the time anyone opens it.

Event trigger

An event trigger is like a webhook but for things that happen inside VDF AI itself.

The most common events:

• A new file lands in a connected folder. Useful for “every time a contract is uploaded, run the contract-review network.”
• A record in a connected database changes. Useful for “every time a customer’s status moves to At Risk, run the retention-briefing network.”
• A previous network finishes. Useful for chaining workflows.

The difference from webhooks: event triggers don’t need an external tool to know about VDF AI. The signal comes from inside.

When event is the right call

• The signal you want to react to is something VDF AI Data already sees.
• You’d otherwise build a polling loop (“check every hour, if something is new, run”) — an event trigger removes the loop and runs the moment the change happens.

A short scenario

A “contract obligations” network is event-triggered on the legal team’s connected contracts folder. The moment a new contract PDF lands in the folder, the network extracts the obligations, formats them as a checklist, and adds them to the legal team’s tracking system. The legal team never has to remember to start it.

Which trigger fits

A short table to help you choose.

Your situation	Best trigger
I’m building this for the first time, not sure if it’ll work	Manual
It runs at a predictable time	Scheduled
Something happens in another tool that should kick this off	Webhook
Something happens inside VDF AI that should kick this off	Event
It’s part of a multi-network pipeline	Event (chained)

A common progression: manual → scheduled → webhook. Most networks start as a manual run someone clicks. Once it proves useful and the inputs stabilize, it moves to a schedule. Once it earns its place in another team’s tool, it picks up a webhook.

Switching a trigger without rebuilding the network

A network’s trigger is a setting, not part of its structure. You can change a network from manual to scheduled — or add a webhook to a network that’s also scheduled — without rebuilding anything inside it.

That means it’s safe to start with the simplest trigger. You can always upgrade.

A few patterns that work

Schedule the boring, manual the interesting

If a network produces a routine artifact at a predictable time, schedule it. If a network needs a person’s judgment to start (which file to feed it, which customer to research), keep it manual.

Pair an event trigger with a “deliver back” step

When an event triggers a network, end the network with a step that delivers the result somewhere a person will see it — a Slack channel, an email, an update on the original record. Otherwise the network runs in silence and its work goes unnoticed.

Always include who/what/why in the output

For scheduled and triggered runs, the result lands without a person watching it run. The output should be self-documenting: “This is the Monday CS digest, covering March 17–23, generated at 6:00 a.m.” A future reader (sometimes future you) will thank present you.

Where to go next

• Node types — the blocks inside the workflow you’re triggering.
• Runs and monitoring — what you see when a trigger fires.
• Versions and templates — manage networks as they grow.
• Tool catalog — the actions a Tool step can take inside a triggered network.