Automation

Create server-side flows triggered by events, webhooks, cron schedules, or manual actions, with a rich library of built-in operations.

#Automation

EmuView's automation engine lets you build server-side workflows without writing backend code. You define a flow — a trigger plus a sequence of operations — and EmuView runs it whenever the trigger fires.

#What you can do

Action Description
React to data changes Run flows when records are created, updated, or deleted — or validate writes before they happen
Process webhooks Give a flow a public URL for external services like Stripe or GitHub
Schedule tasks Run flows on cron schedules for reports, syncs, and cleanup jobs
Call AI models Classify, extract, generate, review, summarise, and translate with seven AI operations
Send emails and notifications Notify users with template variables from the trigger data
Chain flows Compose larger workflows by triggering one flow from another

#Key concepts

Concept What it means
Flow A named automation: one trigger, a sequence of operations, and options
Trigger The event that starts a flow — data event, webhook, schedule, manual action, API endpoint, or another flow
Operation A single step. Built-in operations span data, logic, utility, AI, files, network, script, and communication categories
Run One execution of a flow, with status, duration, and step-by-step logs
Version An immutable snapshot of a flow. Triggers execute the published version, so you can edit safely

#How it fits together

A trigger fires, the engine loads the published version of each matching flow, and the operations run in order. Each step's output feeds the steps after it, and everything is recorded as a run.

flowchart LR
    subgraph triggers [Triggers]
        E[Data event]
        W[Webhook]
        S[Schedule]
        M[Manual or API]
    end
    E --> F[Flow engine]
    W --> F
    S --> F
    M --> F
    F --> S1[Step 1<br>read records]
    S1 --> S2[Step 2<br>transform]
    S2 --> S3[Step 3<br>send email]
    S3 --> R[(Run log)]

Operations run with the permissions of the flow's Run As identity, so flows respect the same access control rules as the REST API.

#Who can view, run, and build flows

Access to Automate is controlled by the system/automate resource in role permissions (Auth → Roles):

Action Grants
read See flows, run history, and versions
execute Run flows manually (the Run and Test buttons)
create / update / delete Build, edit, and remove flows
manage Everything above, plus changing a flow's Run As policy

The built-in roles follow a simple split: admins manage flows, editors can view and run them, viewers can only view. To let a custom role run flows, open the role in the permission matrix and tick the Execute column on system/automate — the column appears only for resources that support it.

Tip

Only manual runs check execute. Event, webhook, and scheduled flows fire on their own — what they're allowed to do is governed by the flow's Run As identity, not by who has execute.

#Flow lifecycle

Flows move through three states:

  • Draft — editing and testing. Dry-run with mock data using testFlow(); triggers don't fire.
  • Active — live. Triggers fire against the published version. Publish new versions without downtime.
  • Inactive — paused. Triggers are ignored until you reactivate.

#Guides in this section