Operations

Pipelines

Pipelines connect a trigger to predictable, repeatable steps. The same input follows the same connected path every time, and every Run records what happened.

Create a Pipeline

Open Pipelines from the section menu and choose Create pipeline. Name the outcome in plain language, add an optional purpose, then choose how the pipeline starts:

Manual
A Member starts it with Run now. Use this for one-off work, internal tools, and testing.
Schedule
Genosyn starts it automatically from a standard five-field cron schedule.
Webhook
Another system starts it by sending JSON to a private URL.
Email received
A genuinely new inbound email in a connected Gmail inbox starts it.
Task created
A new task in Projects + Todos starts it.

Choose Open builder. The trigger is already on the canvas; add what should happen next from the Step library.

Use the builder

  1. Select the trigger or an existing step. Choosing another item from the Step library places it after the selected step and connects it when there is one unambiguous path.
  2. Select a step on the canvas to open its settings. Complete the required fields marked with *.
  3. Use Next step in the Flow section to make or change a connection. For an If / else step, choose separate If true and If false destinations. You can also drag the dot on the right of one step to the left dot on another.
  4. Choose Arrange to lay connected steps out from left to right. This changes only their positions, not what runs.
  5. Follow the setup bar above the canvas. Run now stays unavailable until every required field and connection is ready.

Step library

Start the pipeline
Manual, Schedule, Webhook, Email received, and Task created triggers. A Pipeline needs at least one trigger.
Work in Genosyn
Send a channel message, add a task, create a Project, add a Base record, ask an AI employee, or write a journal note.
Transform or decide
Run JavaScript, make an HTTP request, set named values, branch with If / else, or pause for up to 60 seconds.
Use a Connection
Choose a Connection and one of the actions its Integration exposes, then supply the action arguments as JSON.

Pass data between steps

Text and JSON fields can insert values with double-brace references. Data that started the Run lives under trigger.payload. For example, a webhook body like {"name":"Ada"} can be inserted with {{trigger.payload.name}}.

Each step also shows an Output reference in its settings. If a step's reference id is n_abc123, a later step can read one of its output fields with {{n_abc123.field}}. The Run's Step outputs section shows the exact object produced under each reference id.

  • A reference that fills the whole field preserves numbers, booleans, arrays, and objects. A reference inside a longer sentence becomes text.
  • JSON setup fields must contain an object. The builder checks syntax before enabling Run now.
  • Add record (Base) keys its JSON by field name — for example {"Email": "{{trigger.payload.email}}"}. The step lists the table's field names as you type, and a name that matches no field fails the Run rather than writing a cell nobody can read. Pipelines saved before this keep working: field ids are still accepted.
  • Branch paths are labelled true and false on the canvas and in Flow settings.

Run JavaScript

The Run JavaScript step runs the code you write, exactly as written, with a chosen timeout (1–60 seconds, 10 by default). Whatever the code returns becomes the step's output: return an object to give later steps named fields, and read it like any other step with {{<reference-id>.field}}. A thrown error fails the Run with that message in the log. Because the code carries company-wide authority, only a human can add or edit this step — an AI employee authoring a Pipeline is refused it.

javascript
// Look up a lead, call an external API, and keep a score in a Base.
const [lead] = await genosyn.base.queryRecords("crm", "leads", {
  where: { Email: input.email },
});
const res = await axios.get("https://api.example.com/score", {
  params: { email: input.email },
});
if (lead) {
  await genosyn.base.updateRecord("crm", "leads", lead.id, { Score: res.data.score });
} else {
  await genosyn.base.createRecord("crm", "leads", {
    Email: input.email,
    Score: res.data.score,
  });
}
return { score: res.data.score };

The code sees a small, fixed set of globals:

input
The trigger payload — a copy of the same data as trigger.payload. Double-brace references are not rewritten inside code; read data from these globals instead.
steps
Outputs of earlier steps, keyed by reference id: steps.n_abc123.field.
genosyn.base
Base records: listBases(), listTables(base), getTable(base, table), createRecord(base, table, values), getRecord(base, table, id), queryRecords(base, table, { where, limit, offset, order }), countRecords(base, table), updateRecord(base, table, id, values), and deleteRecord(base, table, id). Bases and tables are addressed by slug; cells accept the column name or field id. Setting a cell to null clears it.
axios
An axios-style HTTP client: axios.get(url, config), axios.post(url, data), put, patch, delete. Responses come back as { status, headers, data } with JSON parsed automatically, and non-2xx statuses throw with error.response attached.
console + sleep
console.log(…) writes to the Run log; sleep(ms) pauses within the step's time budget.
  • Everything is scoped to your company, and requests follow the same private-network protections as the HTTP request step.
  • Limits per step: 50 HTTP requests with responses up to 2 MB, 200 Base operations with up to 500 records per query, and a returned value up to 256 KB of JSON.

Company event triggers

Event triggers start a Run when something changes inside the company. Add one from the Start the pipeline section of the Step library, then use its optional filters to decide which events should match.

Email received
Starts for genuinely new inbound messages in a connected Gmail inbox. Name the mailboxes to watch, or leave that empty for all of them, and filter by sender, subject, or whether the message has attachments. Connecting an inbox does not replay historical mail into Pipelines.
Task created
Starts when a task is added by a Member, AI employee, recurrence, or another Pipeline. Filter by Project, priority, or words in the title.

Email data is available under trigger.payload.message, including from, subject, bodyText, hasAttachments, accountAddress (the mailbox it arrived in), and receivedAt. Task data is available under trigger.payload.task, with its Project under trigger.payload.project. For example, use {{trigger.payload.task.title}} in a later message or task title.

Webhook Pipelines

Select a Webhook trigger to copy its private URL. Send a POST request with a JSON body; that body becomes trigger.payload for the Run. The Pipeline must be turned on for the URL to accept a Run.

Test and inspect Runs

Save the Pipeline and choose Run now. Genosyn starts a manual test with an empty payload, then opens Run history. Each Run shows:

  • whether it succeeded, failed, is still running, or was skipped;
  • what started it, when it started, and how long it took;
  • the step-by-step log and a plain error when a step failed;
  • the starting payload and the final output from every reached step.

Run now is always recorded as Started by a Member, even when the Pipeline normally starts from a schedule, webhook, or company event. Automatic Runs are labelled with the schedule, webhook, or event that started them.

How AI employees use it

AI employees build and maintain Pipelines through the built-in genosyn MCP server, not just run inside them. list_pipeline_node_types returns the step library with every config key; create_pipeline and update_pipeline write the steps and the connections between them; run_pipeline fires a test and hands back the log so the employee can fix what broke; list_pipeline_runs and get_pipeline_run answer "did it work" afterwards. rotate_pipeline_webhook_token issues a fresh webhook URL. Ask one to "stand up a receiver for our marketing events" and it can build the whole thing, test it, and hand you the URL.

Every step an employee writes is checked against its own access before the Pipeline is saved. A Pipeline runs as the company, so this is what keeps that from becoming a way around the Grants you gave the employee: it can only wire up work it could already carry out itself. A step writing into a Base it holds no Grant on, posting into a private channel it was never added to, adding tasks to a restricted Project, or calling a Connection it was not granted is refused, and the employee is told which step and why. The Run JavaScript step is refused outright: its code runs with company-wide authority that no Grant can bound, so only a human can add or edit one.

The check covers the whole Pipeline, not just the step being edited — a step reads {{other-step.field}} when it runs, so changing the step feeding a Connection changes what that Connection does. The practical consequence: once you add a step in the builder that an employee could not have written, that Pipeline's steps become yours. The employee can still see what it does and whether its Runs are passing, but it cannot change it, run it, delete it, read a Run's payload and outputs, or be handed its webhook URL.

Two triggers need more than the usual, because left unscoped both of them watch things the employee may not be allowed to see. Email received must name the mailboxes, and the employee needs read access on each — empty means every mailbox, including ones connected months later. Task created must name a Project the employee can read. In both cases a human can still leave the scope empty in the builder; the Pipeline then runs exactly as it always has.

A Member chatting with an employee delegates their own authority, so the same owner-or-admin rule as the Pipelines page applies: anyone can ask an employee to read Pipelines and Runs, but creating, editing, deleting, running, or rotating a webhook needs an owner or admin driving the conversation. An employee working on its own — a Routine Run — is bound by its Grants instead.

Pipeline or Routine?

Use a Pipeline when the path should be deterministic: same input, same connected steps. Use a Routine when an AI employee should interpret a brief, choose tools, and decide how to complete the work. A Pipeline can still use AI for one specific decision by adding an Ask AI employee step.