Event-Triggered Analytics Workflows

A workflow turns a matching analytics event into a team notification. You choose the trigger, add optional delays or conditions, and send the result to one or more notification destinations. Open a site and choose Workflows under Workspace to get started. Workflows are for internal automation. They do not send lifecycle messages to visitors, run arbitrary code, make user-defined HTTP requests outside a notification step, or trigger from a schedule, funnel, cohort, or alert.

​

Create a workflow

Click New workflow to open the template gallery, then follow the three-step guided setup:

1. Template — pick a starting point. Each card names the destination types it targets, and you can change everything later.
2. Set up — name the workflow, enter the trigger value (for example the custom event name or page path), choose 1–5 notification destinations — you can connect a new email, Slack, Discord, or webhook destination without leaving the dialog — and adjust the notification title and message.
3. Review & turn on — read the workflow back as one plain-English sentence and see how many times it would have run in the last 24 hours and 7 days. Turn on workflow publishes it immediately; Save as draft opens the editor instead. Closing the dialog after the review step keeps the draft in your list.

Blank workflow skips the guided steps and opens the editor directly.

​

Choose what starts a run

Every workflow has one trigger. It can match these event types:

• Pageview
• Custom event
• Error
• Outbound link
• File download
• Button click
• Form submit
• Copy

For a pageview, enter a path pattern such as /pricing*. For a custom event, enter its event name. In the editor the trigger appears as a one-line card that summarizes all of this — click it to open the trigger panel, where Filters (hostname plus up to 10 exact property filters) and Repeat limit sit in optional sections that stay collapsed until they hold values. The repeat limit controls how often one actor can start the workflow:

• Every match starts a run for every matching event. This is what a workflow does when no repeat limit is set — the trigger card says “runs on every match” so there is no ambiguity.
• Once per actor in a time window limits runs by session, anonymous user, identified user, or one of the five group slots. The window can be from 1 minute to 30 days. Some templates ship a limit (for example, the high-intent template starts at once per session per 24 hours).

​

Add workflow steps

Build the path below the trigger with these bounded step types: Each step is a one-line card; click it to configure the step in a side panel. The step’s name, description, and error handling — Stop the run or Continue to the next step — live in the panel’s Advanced section. A workflow can contain up to 20 nodes, and each possible path must end cleanly. Notification titles and messages accept non-executable template paths such as {{event.name}}, {{event.pathname}}, {{event.props.plan}}, and {{actor.identified_user_id}}. TinyAnalytics fills them from the triggering event and records only the event fields the published workflow references.

​

Read a workflow at a glance

A published workflow opens in a read-first view: its status, one sentence describing what it does — for example “When a pageview matches /pricing* → Wait 1 hour → Notify #sales” — its destinations, and Runs and Metrics tabs. Click Edit workflow to change it, and Done to return to the view. Never-published drafts open straight into the editor, since there is nothing to read yet; their view offers a Turn on button instead.

​

Work with drafts safely

The editor saves draft changes automatically. If someone else changes the same workflow first, TinyAnalytics stops autosaving and shows Reload latest instead of silently overwriting their draft. Publishing never changes a run already in progress; that run keeps the immutable version it started with.

​

Test before publishing

Open Test from the workflow editor to simulate the current draft against one sample event. You can enter the sample yourself or load a recent event that matches the trigger. A dry run shows the exact path, condition branches, skipped delays, rendered messages, missing values, and selected destinations. It does not create a run or consume a frequency cap. To make a real delivery test, confirm Send real test notifications to the chosen destinations, then click Send test notifications. Real test delivery is limited to 10 requests per minute per workflow.

​

Publish a version

Click Publish changes when the draft is ready (a never-published draft says Turn on instead). The dialog reads the workflow back as a sentence and states how many times it would have run in the last 24 hours and 7 days; the raw match counts, notification fan-out, and any missing or disabled destinations sit under Details.

• An every-match estimate above 1,000 runs in 24 hours requires explicit confirmation.
• An estimate above 10,000 runs in 24 hours cannot be published until you narrow the trigger or add a frequency limit.
• A site can have up to 20 active workflows. Draft, paused, and archived workflows do not count toward this limit.

Publishing creates an immutable version. Later edits remain draft changes until you publish again, and runs already in progress keep the version that started them. Activation changes can take up to five seconds to reach every ingestion server.

​

Pause, resume, or archive a workflow

The workflow list shows its status, trigger, current version, last-7-day run and failure counts, and last-triggered time. You can Edit, Pause or Resume, Duplicate, and Archive from the list, or from the menu on the workflow’s own page. Duplicating creates a fresh draft; archiving cannot recall a notification that was already sent. The workflow page shows status without version numbers; versions appear in the list and on individual runs.

​

Inspect runs and delivery

Use the workflow’s Runs tab to filter and open individual runs. Each run shows its named step timeline, condition branch, attempts, captured context, and the result for every destination. You can cancel a non-terminal delayed or queued run. The Metrics tab summarizes runs, completions, failures, cancellations, notifications, and failure rate for the date range you choose. Notification delivery is at least once. TinyAnalytics retries a failed destination up to three times, after 1 minute, 5 minutes, and 30 minutes. A rare timeout or retry can deliver the same notification twice; webhook deliveries include an Idempotency-Key header so your receiver can deduplicate them.

​

Who can manage workflows?

Anyone with access to the site can read its workflows, versions, metrics, and run status. Organization owners and admins can create, edit, test-deliver, publish, pause, resume, archive, and cancel runs. An API key with Workflows: Read can read workflow data as its owner. Workflow mutations require an owner or admin signed in with a dashboard session in version 1; API keys, Ask AI, and MCP cannot create or operate workflows.

​

Verify

​

Related