Quickstart

The fastest way to understand RunDis is to make one rule fire and read what it says about itself. That takes about ten minutes and five steps.

You will need an invitation to an organisation on app.rundis.io; the organisation's workspace is set up the first time one of its members signs in. An admin invites, removes and changes roles from the People page's Add Person, which opens the organisation's profile; if you belong to several organisations, the switcher in the header moves between them.

1. Create a provider

Providers are where events come from. Create one of type inbound webhook and give it a name describing the system that will post to it — Workday, GitHub, whatever it actually is.

Then enable it. Providers, triggers and workflows are all created disabled, and a webhook posted to a disabled provider is rejected with 403.

When you create it, RunDis shows the webhook URL and a secret — the secret once only, so copy it now. Senders present it on every post; without it a post is refused with 401. If you lose it, Rotate secret on the provider page issues a new one and stops the old one. (A system that signs its posts with a secret of its own — GitHub, Stripe, Slack — is set up differently: choose its signature as the provider's Verification and name a stored secret. Providers has the table.)

https://app.rundis.io/provider/<id>/webhook

2. Send it an event

Post a payload. Anything that is valid JSON will do, but use a real one if you have it, because the next step gets easier when the shape is the shape you will actually receive.

curl -X POST https://app.rundis.io/provider/42/webhook \
  -H 'Authorization: Bearer whs_…' \
  -H 'Content-Type: application/json' \
  -d '{
        "employee": { "id": "E-2231", "status": "terminated" },
        "department": "engineering"
      }'

A 401 means the secret is missing or wrong (or none has been issued yet); a 403 means the provider is still disabled.

You should get a 201 back:

{
  "message_id": 118,
  "provider": "Workday",
  "status": "received",
  "trigger_count": 0,
  "matched_count": 0,
  "trigger_results": []
}

No triggers yet, so nothing matched. What matters is that the event is in — and RunDis has now seen the shape of your data, which it uses in the next step.

3. Write one rule

Create a trigger on that provider, and add a single condition to its root group.

Start typing in the field box and it will autocomplete from the event you just sent: employee, then employee.status. This is learned from real messages, not from a schema, so it knows the values too — pick terminated from the suggested values rather than typing it.

You want:

employee.status  EQUALS  "terminated"

Enable the trigger.

4. Watch it explain itself

Post the same payload again. This time the response tells you what happened:

{
  "trigger_count": 1,
  "matched_count": 1,
  "trigger_results": [
    {
      "trigger_id": 7,
      "trigger_name": "Employee terminated",
      "matched": true,
      "details": [
        {
          "field": "employee.status",
          "matched": true,
          "reason": "value \"terminated\" equals \"terminated\""
        }
      ]
    }
  ]
}

Now make it fail. Post the same event with "status": "on_leave":

{
  "matched_count": 0,
  "trigger_results": [
    {
      "matched": false,
      "details": [
        {
          "field": "employee.status",
          "matched": false,
          "reason": "value \"on_leave\" does not equal \"terminated\""
        }
      ]
    }
  ]
}

That is the whole idea. You did not go and read a run log to work out why nothing happened — the evaluation told you which condition failed and what it compared. It does this for every operator, at every level of a nested rule tree. See Rule operators.

5. Attach a workflow

A trigger that fires and does nothing is only half of it.

Create a workflow and attach it to the trigger. Add one step and point it at a Slack message action whose text reads from the event:

{{ .trigger.employee.id }} was terminated

Post the terminated payload one more time. The trigger fires, the workflow runs, and the run appears in run history with the step, its input, and what the action returned.

On your phone

RunDis has a phone layout, and it can live on the home screen. On Android, Chrome offers Add RunDis to your home screen under More in the tab bar; on an iPhone, open app.rundis.io in Safari, tap Share, then Add to Home Screen. The installed app opens full screen and keeps a session of its own, separate from Safari's, so sign in inside it once. With no connection it shows an offline page rather than a broken one; it does not work offline beyond that, and it tells you when a newer version is ready to reload.

Once installed, Notifications (under More, or the bell) has a switch per kind of alert for this device: when a run fails, and when a correlation is found. A failed run then arrives as a notification with a link to the run; a new correlation as one that opens Insights. They are best-effort, as push notifications are; the run history and Insights are always the record. The server has to be set up for it (RUNDIS_PUSH_ENABLED with a VAPID key pair); the page says so when it is not.

A run that is doing the wrong thing can be stopped from its page: Cancel run sits above the tabs beside Run again, and the run turns Cancelled as the executor stops it (see Cancelling a run).

Where to go from here

You now have the whole loop: provider → event → trigger → workflow → step → action.

What is worth learning next depends on what you are building:

• More than one condition, nested logic, or rules spanning several providers — Triggers and rules
• Steps that run in parallel, depend on each other, or need to survive a failure — Workflows and steps
• What each action type can do — Actions
• Polling an API instead of receiving webhooks — Providers