Notifications

The Notifications page is your in-app inbox. It lists workflow runs that are paused for your approval, requests to join a workspace, and status updates. You act on them there without leaving SteelEngine.

These are notifications to people inside SteelEngine. Alerts sent to a webhook, email, or Slack when a run completes are a different feature. They are configured on the Logs page and described under Notifications on the External API page.

Opening Notifications

Click the bell labelled Notifications in the workspace sidebar. A badge shows the unread count, up to 9+. The URL is /{orgSlug}/{workspaceSlug}/notifications. When new notifications arrive while you work, a toast appears with a Review action.

What Arrives Here

Approval requests: A Human in the Loop block paused a run. The workflow owner, the person who started the run, and any Additional Approvers each receive "Approval needed: (workflow name)".
Workspace access requests: Someone asked to join a workspace. Members who can manage that workspace's members receive "(email) requested access to (workspace)".
Access decisions: The requester learns whether the request was approved or declined.
Workflow copy results: A workflow copy finished or failed.

Waiting on You

When approvals are pending, the page opens with a Waiting on you section. It lists every paused run across the workspaces you can read in the organization, longest waiting first. Each row names the block that paused, the workflow, a summary of the display data, and how long it has waited.

The section shows up to 50 rows and a "+N more waiting" line for the rest. It reads directly from the paused runs, so an approval appears here even if its notification was never delivered. If the block was deleted after the run paused, the row is titled "A block that was removed".

Click Review to open the approval.

Reviewing an Approval

Review opens a drawer without leaving the page. It names the workflow and lists every pause point in that run. For the selected pause point it shows the status (Needs approval, Approved, or Denied), the block's Display Data, and the Your response form defined by the block.

Read the display data.
Fill in the response fields, if the block defines any.
Click Approve to resume the run, or Deny to stop it.

A toast confirms the result, for example "Approved — Invoice Review resumed". The drawer refreshes every 15 seconds while it is open, so you see the run move to queued and then resumed. Opening a review marks its notification as read.

What happens after Deny depends on the block's error connection. See Approve and Deny.

Access Requests

A workspace access request row has Approve and Deny buttons. Acting on it requires permission to manage members in that workspace. Otherwise the action fails with "Insufficient permissions". Approving adds the requester to the workspace with the requested role, which is read access by default. Either decision sends the requester a notification and archives the request.

Managing the Inbox

All, Unread, and Archived switch the list. Unread rows are highlighted with a dot.
Refresh reloads the list and the Waiting on you section.
Hover a row for Mark read and Archive. Archiving also marks the row as read. In Archived, use Restore to bring a row back.
Rows are grouped by workspace, then by workflow.

Common Questions

The workflow owner, the person who started the run, and every organization member listed under Additional Approvers on the Human in the Loop block. Anyone else who can read the workspace still sees the pending approval under Waiting on you.

Waiting on you reads from the paused runs themselves, not from delivered notifications. It shows every pending approval in the workspaces you can read, including ones whose notification was never written, for example when the block was deleted after the run paused.

Yes. The workflow editor's block panel lists a block's pending approvals with the same Approve and Deny actions, the approval portal at /resume/{workflowId}/{executionId} accepts the form, and the resume API and webhooks accept a decision programmatically. See the Human in the Loop page.

The run does not continue on the block's normal connections. If the block's error output is connected, execution follows it; otherwise the run stops at the block. The block output records denied: true and the reason.

Approving or denying an access request requires permission to manage members in that workspace. If you lack it, the action fails with 'Insufficient permissions'. Ask a workspace admin to decide.

No. Archiving only hides the row from All and Unread. The run stays paused and remains listed under Waiting on you until someone approves or denies it.