Outbox
The events recorded when records change, on their way to the rules that listen to them, with the runs each event produced and the panel from which a failed event is requeued.
Outbox
This is the queue of events on their way to your rules. Whenever a record changes in a way some active rule listens to, an event is written here; the engine then hands it to each listening rule, which produces a run. Use it to check that an event was raised, see which runs it produced, and requeue an event that failed.
Where to find it
Account menu > Settings > Workflows > Outbox. You also land here from the Outbox event link in a run's panel, from Parent event in another event's panel, and from a count on the Health tab (filtered to that status).
You need the View permission on Workflow Runs. Without it the page shows "No access" and "You do not have permission to view the workflow outbox. Ask your administrator."
What you see
The page header reads "Events written when records change, picked up by the automation every 10 seconds. Each event fans out into one run per rule that listens to it; Failed events can be requeued from their panel." with a Refresh button.
Above the grid you have:
- Status filter ("Any status"): Pending, Dispatched, Processing, Processed or Failed.
- Event type filter ("Any event type"): shown only if you may view rules; entries read "CODE · name".
- Entity filter ("Any entity").
- From date and To date.
- A removable blue chip when the list was opened for one record.
The grid columns:
| Column | What it shows |
|---|---|
| Created | When the event was written and how long ago. |
| Event | The event code with its name underneath, and "depth N" for an event raised by a chained rule. |
| Record | The record the event is about, as a link when you may open that kind of record. |
| Status | The status badge, and "retried N×" when the engine had to retry it. |
| Dispatched | When the event was handed to the engine. |
| Processed | When the engine finished with it. |
| Error | The first line of the last error, if any. |
| (icon) | Open (the eye icon) opens the event's panel. |
The list shows the newest events first. When nothing matches, the grid reads "No outbox events match".
The event panel
Opens with the title "Event <id>" and the status badge. It shows Event type, Record, Status (with "retried N×"), Trace depth, Parent event (a link, for an event raised by a chained rule), Origin (api for a change made in the app, workflow for a chained event, scheduler for a scheduled rule's firing), Dedupe key, Celery task, Created, Dispatched, Processed and Event id.
A Failed event shows Last error in red; an event that recovered after a retry shows "Last error (recovered)" in yellow. Changed columns lists what changed on the record (open by default), and Payload holds everything the rules received.
Under Runs, one row per rule that reacted: a link to the run, its status and a link to the rule. A processed event that no rule reacted to reads "No rule listened to this event."; an event not yet processed reads "No runs yet."
What you can do
Refresh
Reloads the list.
Open
Opens the event's panel (described above).
Requeue
Puts a Failed event back to Pending so the engine picks it up again, with the message "Event requeued; it is picked up within a few seconds." Its retry count starts again from zero.
- Who: anyone with the Edit permission on Workflow Rules (only the Administrator in the default roles), even though the tab itself needs Workflow Runs. Without it the button isn't shown.
- Shown only on Failed events. If the event has moved on in the meantime you see "Only failed events can be requeued."
Close
Closes the panel.
Statuses
- Pending: written together with the change to the record, waiting for the engine.
- Dispatched: handed to the engine's queue.
- Processing: the automation has taken it and is creating the runs.
- Processed: done; the Runs list shows what it produced.
- Failed: not processed after five attempts ("not processed after N dispatches"), or processing hit an error. Requeue sends it back to Pending.
An event that sits in Dispatched or Processing for 30 minutes is sent again automatically.
Things to know
- Only events some active rule listens to are written. Changing a record for which no active rule matches (including the rule's project scope and, for On Update rules, its watched columns) writes nothing here. An empty outbox for a change you expected to trigger a rule usually means the rule is inactive, scoped to another project, or watching other columns.
- Rules' own changes never appear here. What a rule changes doesn't raise events, so rules can't set each other off. Only a rule's Emits event type writes a chained event, shown with "depth N" and a Parent event.
- Waiting events are picked up every 10 seconds, and saving a record also nudges the automation straight away, so an event normally moves to Dispatched within seconds. If events pile up in Pending, check the Health tab: automation or its queue is probably down.
- Processed events are cleared after 30 days, so this is a recent log, not an archive. The runs themselves stay on the Runs tab.
- Date filters count days in UTC, five and a half hours behind India.
Related
Related
- RunsScreen
Every time a rule ran: what started it, which record it worked on, how each action went, and the panel from which an errored run is retried.
- HealthScreen
Whether the automation engine can process what the rules produce: the engine flag, its message queue, its worker, the outbox and run counts, and the scheduler's heartbeat.
- Event typesScreen
The named events a rule can listen to: the system events NirmaanOne raises itself and the custom events you add to chain rules or to raise from your own integrations.
- RulesScreen
Every automation rule in your organization, system and custom, with filters, the switch that turns each rule on or off, and shortcuts to edit, test, clone, see the run history of or delete a rule.
- Workflow runs and the outboxConcept
How a change becomes automation: the outbox event written with the change, the pick-up that hands it to the engine, one run per listening rule with a recorded result per action, the statuses each passes through, and how Errored runs are retried and Failed events requeued.
- Triggers and event typesConcept
The five ways a workflow rule starts (On Create, On Update, On Event, Scheduled, Manual), the catalogue of system event types the app raises, the daily due-date events for instalments and overdue demands, how recurrences are counted, and custom event types that chain rules.
- Investigate a failed automationHow-to
When a reminder, task or automatic run didn't happen, check that the workflow engine is working, find the run that failed and read its error, fix the cause, then retry the run or requeue the event.
- Workflow runs stay Pending: automation is off, its queue is down or processing has stoppedTroubleshooting
Rules keep saving and events keep being recorded, but nothing runs while automation is switched off on the server, the queue that carries changes to it is missing or down, or processing has stopped; the Health tab shows which, the NirmaanOne team fixes it, and the waiting work is then processed.
- WorkflowsScreen
The Workflows area of Settings, where you manage automation rules, event types and message templates, and check the runs, the outbox and the engine's health.