Build a workflow
Use the workflow editor: choose a trigger, add steps, fill fields with values from the run, test the draft and publish it.
What it is
The editor is a flow: the trigger at the top (When), then the steps, down to Run ends. Select any node to edit it in the inspector on the right. The draft saves itself about a second after each change; nothing changes for the published version until you publish.
Where to find it
SettingsWorkflowsa workflowThe editor has three tabs: Editor, Runs (this workflow's runs, see Runs) and History (published versions).
Key actions
Choose what starts it
Select the trigger and pick Starts:
| Starts | Asks for | Notes |
|---|---|---|
| When something happens | Signals: one to twenty signal types, such as Risk created | Narrow it further with Only when |
| When a date comes round | Record (risk, risk treatment, policy, evidence, security finding), its Date, When (days before, on the day or days after) and At (a time and time zone) | A date that moves fires again at its new value. A date already past when you publish does not fire. |
| On a schedule | A five-field schedule (minute, hour, day of month, month, weekday) and a Time zone. 0 9 * * 1 is Mondays at 09:00. | Missed times are not made up |
| When another system calls Noru | Hook: an inbound hook address. New hook creates one (admins). | See Inbound hooks for how the caller signs its message |
| When someone runs it | Inputs asked for each time it runs: a key, a Label, a type (text, number, boolean, date) and Required | Started with Run now in the … menu, or over the API |
Only when adds conditions every trigger must meet before a run starts, for example "Risk level is one of high, critical". Conditions can compare (is, is one of, is more than, contains, is set …) and, for signals about a change, check what changed (changed, changed from, changed to). Match all or any of them.
Add steps
Click a + in the flow (Add a step here) and pick a step. Drag a step onto another + to move it.
| Step | What it does | Fields |
|---|---|---|
| Action | Creates or changes a record: add a risk treatment, update a vendor, raise a security finding … | Action, then the action's own fields. If it fails: try up to 1–5 times, then stop the run or go on to the next step. |
| Notify | Sends a message In Noru, By email or To a Slack channel | Recipients (a member, everyone with a role, or a person from the run), Title, Message, Link. Slack needs the Noru app in the channel. |
| Ask for approval | Asks members to approve; the run waits | Ask, Details, Approvers, Needs (one approval or every approver), Days to answer (up to 90), and what happens if nobody answers: reject, or ask more people up to three times. By default the person who started the run cannot approve it. |
| Give someone a to-do | Gives members a to-do in their Inbox | To-do, For, Due in days, and whether the run goes on at once or waits until it is done |
| Wait | Pauses the run | Days, Hours, Minutes: from one minute to 365 days |
| If / otherwise | Branches on conditions | Two paths: If it holds and Otherwise |
| Send a webhook | Posts a signed JSON message to one of your webhook endpoints | Endpoint, Event name (the message's type, workflow.webhook by default) and Data (JSON). See Messages from workflows for the exact body. |
| Signal other workflows | Raises a named Workflow signal that other workflows can start on | Signal name, Payload |
| End | Ends the run here | — |
An approval has two paths, Approved and Rejected or timed out. With nothing on the second path, a rejection ends the run as Rejected.
Under Advanced, each step has a Step id. Later steps read its results by that id, so change it only before anything refers to it.
Use values from the run
Most text and JSON fields accept values from the run, written {{ … }} and
shown as pills. Type / or click {} to open Insert a value from the run;
it offers only what is available at that step:
| Group | Values |
|---|---|
| Trigger | What started the run. For a signal: trigger.data.record.title, trigger.data.changes, trigger.subject.id … For an inbound hook: trigger.data.payload. For a date: trigger.record.title, trigger.date. For a manual run: trigger.inputs.<key>. |
| Earlier steps | steps.<step id>.status and steps.<step id>.output…, for example the new treatment's id from an Action, or decision from an approval |
| Workflow | workflow.name, workflow.id, run.id, now |
A field that is exactly one value keeps its type (a number stays a number);
text around it makes a string: Review {{ trigger.data.record.title }}. A few
filters format values: upper, lower, default, join, json, and
date_add ({{ trigger.time | date_add: 14 }} is 14 days later). A value the
step cannot reach is shown in red and blocks publishing.
Test the draft
Test with a real signal shows what the draft would do with the most recent signal that starts it: whether the conditions hold, and each step's input with its values filled in. Nothing runs and nothing changes. Each step also shows a preview with the latest real values.
Publish
Click Publish v2 (the next version number). Publishing is blocked, with a count of problems, while anything is incomplete: a required field, a step nothing leads to, a loop, a webhook endpoint that is off. Problems are listed at the top of the inspector and counted on each node. Publishing turns the workflow on.
Only admins publish. A workflow published by an API key or an agent may do only what that key's scopes allow.
Restore an earlier version
The History tab lists every published version with who published it, when, what it changed ("Added Ask for approval, changed Add risk treatment") and the permissions it needs. View opens one read-only; Restore as draft makes it the draft, which you then publish.
Statuses and fields
| Next to the name | Meaning |
|---|---|
| v3 is live | Version 3 is published and on |
| Not published | Only a draft exists |
| Paused | Published, but not running |
| Draft has 2 changes · saved | Your draft differs from the live version |
| Saving…, Saved, Couldn't save | The draft's autosave. Retry save appears after an error. |
Workflow settings
In the … menu, Workflow settings holds:
- Description.
- Start on changes other workflows made: off by default, so workflows do not set each other off in a loop. Turn it on for a workflow that should start on Workflow signal or Workflow run failed.
- Runs allowed in five minutes: 100 by default. Runs beyond it are Held until someone releases them.
Tips and gotchas
Start from a template even when it is not quite what you want. The structure, conditions and values are already filled in, and the editor opens on the first field you need to change.
A Send a webhook step fails the run after a few quick retries if the endpoint does not answer 2xx. Check the endpoint with Send test delivery in Webhook settings before you publish.
A built-in workflow opens read-only. Duplicate to customize makes an editable copy; pause the built-in one if the copy replaces it.
What Noru does not do
- Only Action steps can be set to go on after a failure. Any other step that fails, after a few retries, stops the run.
- A workflow cannot make more than 50 steps or nest conditions more than three groups deep.
- Describing a workflow to Cortex is coming soon; for now, start from a template.
Related
Last updated on
Workflows
Automations that run steps for you when something happens in Noru, on a date, on a schedule, when another system calls, or when someone starts one.
Workflow runs
Follow what a workflow did: the runs list, a run's timeline with each step's inputs and results, held runs, approvals waiting on people, and exporting a run as evidence.