Workflow Automation#
Novaza Office includes a visual workflow editor that lets you automate business processes without writing code. Workflows respond to events in your data — such as a record being created or a field value changing — and execute a sequence of actions in response.
Workflow Concepts#
A workflow consists of three parts:
- Trigger — the event that starts the workflow
- Conditions (optional) — logical filters that must be true for the workflow to proceed
- Steps — an ordered list of actions to execute
Workflows run server-side and are fully audited. Each execution is logged with its trigger event, condition results, step outputs, and final status (success, failed, or skipped).
Triggers#
| Trigger Type | Description |
|---|---|
| Record created | Fires when a new record is saved for the first time |
| Record updated | Fires when any field on an existing record is modified |
| Field changed | Fires when a specific field changes value |
| Record deleted | Fires when a record is removed |
| Manual | Triggered by a user clicking a button on a page or record |
| Scheduled | Runs on a cron schedule (e.g., every morning at 9:00) |
| Incoming webhook | Triggered by an external HTTP POST to a unique URL |
| Form submitted | Fires when a page form is submitted |
Scheduled (Cron) Triggers#
Scheduled triggers run a workflow on a recurring timetable expressed as a standard cron string. Common patterns:
| Schedule | Cron |
|---|---|
| Every day at 09:00 | 0 9 * * * |
| Every Monday at 08:30 | 30 8 * * 1 |
| Every hour, on the hour | 0 * * * * |
| First day of month at midnight | 0 0 1 * * |
Scheduled workflows execute in the workspace’s default timezone (configurable in Admin → System Settings) and are useful for nightly cleanup, SLA escalations, weekly digest emails, and recurring imports.
Event Taxonomy#
Record-based triggers expand across a before / after × create / update / delete / read matrix. The before variant runs inside the transaction and can veto the operation or mutate the payload; the after variant runs once the operation is committed and is used for side effects such as notifications and external integrations.
| Phase | Create | Update | Delete | Read |
|---|---|---|---|---|
| Before | validate payload, add defaults | enforce invariants, guard fields | prevent removal under conditions | gate access at query time |
| After | send welcome mail, link related records | recalculate derived fields, notify watchers | archive snapshot, cascade cleanup | log access for audit |
Conditions#
After the trigger fires, conditions are evaluated to determine whether to proceed. Conditions can test any field value on the triggering record, compare against static values or other fields, and be combined with AND/OR logic. For example: Status is "New" AND Assigned User is empty.
Steps (Actions)#
Workflows support the following step types:
- Update record — set field values on the triggering record or a related record
- Create record — insert a new record into any module
- Delete record — remove a specified record
- Send notification — push an in-app alert to a user or role
- Send email — deliver an email using a Pulse template (requires Novaza Pulse)
- HTTP request — call an external API (POST, PUT, PATCH, GET) with JSON body
- Run script — execute a sandboxed JavaScript snippet with access to record data
- Delay — pause execution for a specified duration before the next step
- Loop — iterate over a list of related records and apply steps to each
- Branch — conditionally execute different step sequences based on a field value
Building a Workflow#
- In your namespace, go to Workflows → New Workflow.
- Give the workflow a name and optionally a description.
- Select a Trigger type and configure it (e.g., choose the module for record-based triggers).
- Add Conditions if needed.
- Click Add Step to build your action sequence. Drag steps to reorder them.
- Toggle the workflow to Active when you are ready to deploy it.
Testing#
Before activating a workflow, create a test record in a sandbox namespace or use a dedicated test record in your live namespace to observe the workflow’s behavior. Step outputs, errors, and the final status are visible in the workflow’s execution log. Activating and deactivating the workflow lets you control when it runs against real data.
Error Handling#
If a step fails (e.g., an HTTP request times out), the workflow execution is marked as Failed and logged. You can configure a workflow to retry on failure up to 3 times with exponential backoff, or to send an alert to an admin user when a failure occurs.