Templates

Start from a working workflow instead of a blank canvas. Three short templates show how your app, BuildBase and your backend connect; the rest are ready-made automations.

Every organization comes with a set of workflow templates. Open Workflows > Templates in the console, pick one, and Use template copies it into a draft workflow you own, with your default sender and your email templates already filled in. Then you review it in the builder and publish.

The first three exist to teach. Each shows one thing about how the pieces connect, in two or three steps you can run in a minute. The rest are automations you would otherwise build by hand.

How a workflow connects to your app

flowchart LR
  A[Your app] -->|SDK call: sign-up, plan change, form submit| B[BuildBase records an event]
  B -->|a published workflow's trigger matches| C[Workflow run]
  C -->|send_email / send_push| D[Your users<br/>from your sender, your templates]
  C -->|http_webhook| E[Your backend]
  E -->|flip a flag, update a CRM| A

Your app produces events. You do not call a workflow. When your app registers a user through the SDK, user.registered is recorded. When a plan changes, subscription.updated. When a form is submitted, form.submitted. The full list is in Triggers and actions.
A trigger matches, a run starts. Every published workflow whose trigger is that event starts a run with the event's data: the user's email, the workspace id, the form fields.
Steps act. A step can email or push to your users (with your sender and your email templates), wait for something to happen, branch on a condition, or call your own backend with http_webhook.
Your backend closes the loop. The webhook body is JSON you define. Your endpoint reads it and does what only your code can: turn a feature on, update your CRM, post to your team chat.

Start here

Welcome a new user

Shows: an event from your app starts a workflow, and BuildBase sends email for you.

Step	What it does
Trigger `user.registered`	Your app registered a user through the SDK
`send_email`	Sends your Welcome email template to `{{trigger.email}}` from your default sender

Filled for you: the sender and the email template. You fill in: nothing.

Verify: publish, then sign a test user up in your app, or press Test run in the builder. The email lands wherever your default sender delivers. If the Welcome notification under Notifications is also on, the user gets two emails; turn one of the two off.

Send events to your backend

Shows: BuildBase calls your backend, and exactly what arrives.

Step	What it does
Trigger `user.registered`	Your app registered a user
`http_webhook`	`POST`s this JSON to a URL you own

{
  "event": "user.registered",
  "userId": "{{trigger.userId}}",
  "email": "{{trigger.email}}",
  "name": "{{trigger.name}}"
}

You fill in: the URL. Paste a request-catcher URL first to watch the payload arrive, then point it at your real endpoint. Your endpoint should answer 2xx. Any other status completes the step with success: false, so branch on {{success}} if a bad answer should stop the flow. A request that gets no answer (a timeout or a refused connection) is retried with backoff, and if every attempt fails the run fails or takes the step's error path (see HTTP webhook actions).

Follow up if they do not act

Shows: waiting and branching, so a follow-up stops the moment the person does the thing.

Step	What it does
Trigger `audience.member_created`	Someone joined your audience
`send_email`	A short welcome with one link in it
`wait_for_event`	Waits up to 3 days for a click in that email
`send_email` (timeout branch only)	A short reminder, with its own subject and body

If they click, the run ends on the event_received branch, which has no next step. If 3 days pass, the timeout branch sends the reminder. This is the pattern for "remind them, unless they already did it".

The first email is a plain one rather than your Welcome template, because the wait step listens for a click and the seeded Welcome email has no link in it. Any link in that email counts as the click.

Filled for you: the sender. You fill in: the link in the first email, which points at example.com until you change it to a page in your app. You will want to reword both emails.

Ready-made automations

Every one of these that emails a workspace owner starts with a Look up the workspace step, because billing events carry a workspace id but not an email address. The email steps then address {{nodes.action_1.ownerEmail}}, and their Template variables field hands the email template what it prints, such as workspaceName from the lookup and daysRemaining from the event.

Templates marked with an asterisk send an email that a notification event under Notifications also sends. If that notification is on, the person gets two emails: turn one of the two off.

Template	Trigger	Steps	You fill in
Trial Ending Reminder *	`subscription.trial_will_end`	look up workspace → push "Your trial ends in N days" → wait 1 day → if still no active plan, email Trial Ending Soon	nothing
Payment Failed Recovery *	`payment.failed`	look up workspace → email Payment Failed → wait 2 days → if still in dunning, push "Update your payment method"	nothing
Canceled subscription win-back *	`subscription.canceled`	look up workspace → email Subscription Canceled → wait 7 days → if still not active, one win-back email	nothing, though reword the win-back
Unsubscribe Follow-up	`audience.unsubscribed`	`POST` `{event, audienceId, email, reason, unsubscribedAt}` to your CRM	the URL
Form Submission to Webhook	`form.submitted`	`POST` `{event, formId, formName, recordId, data}`	the URL
Sync profile changes to your CRM	`audience.member_updated`	`PUT` `{event, audienceId, email, name, changedFields, changedKeys}`	the URL
Update feature flags on subscription change	`subscription.updated`	look up workspace → `POST` `{event, workspaceId, subscriptionId, subscriptionStatus, planName}`	the URL; your endpoint flips the flags

What a template is

System templates are read-only. You cannot edit or delete one, and every organization has the same set. When we improve one, your copy is refreshed the next time someone on your team opens the console after the release; workflows you already created from it are yours and never change.
Use template makes a draft you own. Edit anything in the builder: reword an email, change a wait, add a step. Publishing works exactly as for a workflow you built from scratch.
What gets filled in. Your default sender (Messaging > Sender accounts) and your own copy of the named system email template (Messaging > Templates). If you have no default sender, the sender field is left blank and the builder points at it.
What does not. Webhook URLs, lists and tags are yours alone, so a template never guesses them. The template's details panel lists exactly what you have to fill in before you use it.
Your own templates. POST /api/workflows/templates saves a flow as a reusable template for your organization. Those you can delete.

Limitations

No feature-flag step. A workflow cannot flip a feature flag itself. "Update feature flags on subscription change" posts the new plan to your backend, which does.
No "renewal due in N days" trigger. A reminder ahead of a renewal date has no trigger to start from today. subscription.cancel_scheduled fires when a cancellation is scheduled, which is the closest event.
wait_for_event listens to earlier steps. It waits for an event produced by a step before it, such as a click on the email that step sent, matched by that email's tracking code. It cannot wait for an unrelated event.

Next Steps

Triggers and actions - every event your app can start a workflow from.
Webhook actions - what your endpoint receives and how to answer.
Monitoring - runs, retries and the dead-letter queue.