Automation primitives

The automation engine is conceptually similar to Make.com (or Zapier): a flow starts with a trigger, runs through a chain of nodes, and each node produces outputs that downstream nodes can reference. If you’ve used Make before, you’ll feel at home; if not, this section is the primer.

The engine is less flexible than Make and Zapier on purpose — every block has a domain-aware shape (e.g. “Set lead state”, “Send email”) that knows about pools, calendars, and the Studio variables.

Trigger

Every flow starts with exactly one trigger. There are six trigger event types:

Trigger (UI label)	Event ID	Fires when
Neuer Lead hinzugefügt	table.entry.added	A new lead is created in the Lead Pool
Leadstatus geändert	table.entry.leadState.changed	A lead transitions to a different lead state
Neuer Termin gebucht	calendar.appointment.booked	A new appointment is booked on the Calendar
Termin beginnt	calendar.appointment.hasStarted	An appointment’s start time arrives
Termin endet	calendar.appointment.hasEnded	An appointment’s end time arrives
Termin gelöscht	calendar.appointment.deleted	An appointment is deleted

The trigger:

• Defines when the flow fires.
• Provides the initial data every downstream node can reference — typically a tableEntry (the lead), an appointment (the booking), and the surrounding table / calendar metadata.
• Defines the scheduling of the flow:
  • Immediate (default) — fire as soon as the event happens.
  • Delayed — fire N days/hours/minutes after the event.
  • Pre-event — fire N units before the event (only meaningful on Termin beginnt / Termin endet; you can’t pre-fire on a “lead added” event because you don’t know the lead is coming).

Triggers also have a source filter — which Lead Pool or Calendar to listen on. Multi-source listening (one trigger watching multiple pools) is supported.

Action nodes

After the trigger, you add action nodes. The editor groups them into three tabs:

Group	UI label	Handler ID	Notes
communication	E-Mail senden	email.send	Plain email body
communication	Sendgrid Vorlage versenden	sendgrid.template.send	Uses a SendGrid dynamic template
communication	SMS senden	sms.send	Native SMS via configured provider
action	Leadstatus setzen	table.entry.leadState.set	Set the lead’s state
action	Follow-Up terminieren	followUpDate.set	Schedule a follow-up date on the lead
action	POST Request	webhook.post	Convenience wrapper around POST to a URL
action	HTTP Request	httpRequest	Arbitrary HTTP request (any method)
helper	Variable setzen	variable.set	Store a value for use by downstream nodes
helper	Warte	wait	Delay before the next node
helper	Router	router	Conditional branching — see below

There is no dedicated “appointment action” node — appointments are read-only from inside a flow (you can react to them via triggers but not modify them).

Router (conditional branching)

The Router node evaluates one or more conditions and routes the flow down matching paths. Typical use:

• “If the lead’s pool is Pool A → set state to ‘PT vereinbart’; else if Pool B → set state to the distinct ‘Probetraining geplant’ state.” (Only needed when locations use genuinely different states — lead states are org-global, so a shared state needs no branch.)
• “If the lead has an email → send confirmation; else → end.”

See Lead states across locations for how lead states behave across multiple Lead Pools.

The condition editor offers comparators (equals, not equals, greater than, less than, contains, is empty) but dates are compared as strings today — there’s no native datetime comparison yet. To compare dates, format both sides as ISO-8601 strings and rely on lexical comparison.

HTTP request — the escape hatch

The HTTP Request action sends an arbitrary HTTP request to an external service. Use it for:

• Forwarding lead data to a Make / Zapier scenario for further processing.
• Calling a third-party API directly (e.g. MATOOL, Magicline) — see the Integrations guides.
• Triggering WhatsApp via a third-party provider — there’s no native WhatsApp action yet.

The request body supports {{...}} placeholders against any upstream node’s data, plus a “Raw dates” toggle to format ISO timestamps with or without timezone normalization.

For simpler one-way POSTs (e.g. firing a Make webhook), use the POST Request node instead — it’s a thin wrapper that drops the URL + body fields without exposing headers/method config.

Variable picker

Each node’s edit view has a variable panel on one side that lists every upstream node’s outputs. Click a variable and it’s copied to the clipboard; paste into any input field.

Notable categories in the panel:

• Standort variables ($studio.*) — always available, regardless of upstream nodes; resolved dynamically at run time. See Snapshot semantics.
• Trigger output — the table, the table entry, the appointment, etc.
• Each upstream action’s output — e.g. the response of an HTTP Request node.

Custom Field values appear in a separate green-highlighted section because they have a different access path (customFieldData.<uuid> instead of data.<key>).

Saving and publishing

Each flow has two distinct save actions:

Action	Effect
Save	Save the draft. Doesn’t change the active version.
Save & publish	Save AND make this the active version. New trigger events from this point use this version.

Flows are versioned. When a trigger event fires, the then-published version is snapshotted alongside the event’s data. Subsequent edits don’t affect already-queued runs. See Snapshot semantics for the full implications.

What’s next

• Default templates — the 5 prebuilt flows every new org gets.
• Customer-source picker — why some triggers need an extra config step.
• Variable placeholders — silent-fail caveat to be aware of.