Workflow Execution Inspector

Workflow Execution Inspector gives support and operations teams a work-item-level view of workflow activity that is still in flight. Instead of leaving the matter or work item to search through workflow administration screens, teams can see the active executions directly where the issue is being investigated.

The widget shows whether workflows are running, waiting, or errored, when they started, which plan is involved, and which sub-processes are present. Where permissions allow, an authorised user can also cancel a live execution from the same panel.

Why it matters

Workflow issues are often time-sensitive and hard to diagnose from the front end. A user may report that “nothing happened”, a task may not appear, or an automation may seem stuck. The first support question is usually simple: is a workflow currently running, waiting, or errored on this work item?

Workflow Execution Inspector answers that question in one glance.

What it shows

For the current work item, the widget lists currently tracked workflow executions and displays:

• Workflow state, including running, waiting, errored, completed, cancelled, and failed states where returned by the platform.
• Plan title and plan system name.
• Start time, shown as both relative and absolute time.
• Plan type, where available.
• Last errored timestamp, where available.
• Parent execution ID, where available.
• Sub-processes and their flags.
• Sub-process state highlighting.
• Copy controls for plan system name and execution ID.
• A cancel control for cancellable executions, subject to platform permissions.

Live support view

The widget automatically refreshes every five seconds while any execution on the work item is running or waiting. When nothing is live, it pauses polling to reduce unnecessary traffic.

A visible LIVE indicator appears while auto-refresh is active.

Built for triage

Workflow Execution Inspector is designed for support and debug pages, particularly where teams need to answer questions such as:

• Is a workflow currently active on this work item?
• Is it waiting rather than running?
• Did it error?
• Which workflow plan is involved?
• Which execution ID should be used for deeper investigation?
• Is there a runaway execution that an administrator should cancel?
• Are sub-processes present, and what state are they in?

Filtered views

Filter chips make it easy to narrow the list by state:

• All
• Running
• Waiting
• Errored

Each chip includes a live count.

Expandable technical detail

Clicking an execution row opens a detailed view with plan metadata, identifiers, parent execution information, and sub-process information. This makes it easier to hand off an investigation to another support engineer or to open the relevant workflow tooling with the correct plan system name.

Important scope note

This widget shows currently tracked executions. It is not a complete historical workflow audit trail and does not expose per-step logs or execution variables. For completed history, detailed execution logs, and variable inspection, use the platform’s workflow modeller or execution administration tools.

Permission-aware cancellation

Where a workflow execution is cancellable, the widget displays a stop control. Cancellation requires the relevant platform permission, typically administrator-level access. If the user does not have permission, the widget surfaces a friendly permission message rather than silently failing.

Best-fit placements

Workflow Execution Inspector is best placed on:

• Support dashboards.
• Work-item diagnostic pages.
• Internal operations pages.
• Workflow rollout verification pages.
• Administrator-only troubleshooting layouts.

It is not intended as a general end-user widget.

Workflow Execution Inspector — Technical Notes

Component identity

• Namespace: Alt.WorkflowExecutionInspector
• Designer namespace: Alt.WorkflowExecutionInspectorDesigner
• Source path: src/widgets/workflow-execution-inspector
• Kind: Sharedo widget
• Category: Alterspective / Support
• Tier: T2
• Status: deployed
• Foundry-backed: yes, for lifecycle/error/polling helper surfaces
• Placement configuration: designer exists, but no runtime settings are currently exposed

Runtime behaviour

The widget self-contextualises from:

$ui.pageContext.sharedoId()

If no work-item context is available, it shows:

No matter context — open this widget on a work item page.

The wrapper in widget.ts is intentionally thin. It creates WorkflowExecutionInspectorCore, exposes core.model to the Knockout template, calls initialise() from loadAndBind, and calls onDestroy() when the widget is torn down.

Data source

The widget uses Sharedo execution-engine endpoints:

GET /api/executionengine/plans/executing?limit=500&offset=0
POST /api/executionengine/plans/executing/{id}/cancel

The list endpoint does not expose a server-side work-item filter, so the widget retrieves up to 500 currently tracked executions and filters client-side by:

e.sharedoId === this.sharedoId

Internal API caveat

These endpoints are not under /api/v1/public/. They are internal platform APIs and may not be contract-stable across platform upgrades.

The manifest declares the internal API dependency:

"internalApi": {
  "endpoints": [
    "/api/executionengine/plans/executing",
    "/api/executionengine/plans/executing/{id}/cancel"
  ],
  "reason": "No public equivalent in /api/v1/public/... for currently-executing plans. Re-check on each Sharedo upgrade.",
  "publicEquivalentTracked": null
}

Re-check these endpoints on every Sharedo upgrade.

Foundry usage

The core imports Foundry helpers and types:

import {
  loadSequence,
  poll,
  SharedoApiError,
  type SharedoExecutionPlan,
  type SharedoExecutionSubProcess,
  type PollHandle,
} from "@alterspective-engine/foundry";

Current source uses Foundry for:

• loadSequence() stale-response guarding.
• poll() auto-refresh lifecycle management.
• SharedoApiError classification where available.
• Sharedo execution plan/sub-process typings.

The actual HTTP calls currently go through the repo runtime ajax wrappers:

ajaxGet(...)
ajaxPost(...)

This is intentional per the designer help text: Foundry ApiClient was bypassed for these read-side widgets to avoid authentication failures against these internal endpoints.

Polling

Constants:

const PAGE_LIMIT = 500;
const POLL_INTERVAL_MS = 5000;

The widget polls only while any row is live:

rows().some((r) => r.state === "RUNNING" || r.state === "WAITING")

The same computed drives the UI LIVE indicator and the Foundry poll() when predicate.

Polling is tied to an AbortController signal and disposed during onDestroy().

State mapping

Known execution state mappings:

Unknown states are rendered using the raw state label, unknown CSS class, and are not cancellable.

Row model

Each execution row includes:

• id
• planSystemName
• planTitle
• planDescription
• planType
• state
• stateLabel
• stateClass
• startTime
• startTimeAbsolute
• startTimeRelative
• lastErrored
• parentPlanExecutionId
• subProcesses
• isCancellable
• Knockout observables for expanded/cancelling/copied/error state

Existing row UI state is preserved across refreshes by merging rows by execution ID.

Sorting

Rows are sorted newest-first by startTime.

Filtering

Supported filters are:

type FilterKey = "all" | "running" | "waiting" | "errored";

The errored filter includes both ERRORED and FAILED.

Cancellation

Cancellation flow:

1. User clicks the row stop button.
2. Browser confirmation prompts: Cancel execution of "{planTitle}"?
3. Widget posts to /api/executionengine/plans/executing/{id}/cancel.
4. On success, the widget reloads the execution list.
5. On failure, a row-level error message is shown.

Cancellation is only offered for states marked cancellable in STATE_CONFIG.

The error-message helper maps permission failures to a friendlier message:

permission denied (AdminAccess required to cancel)

Clipboard support

The widget supports copying:

• Execution ID.
• Plan system name.

It uses navigator.clipboard.writeText when available and falls back to a temporary textarea plus document.execCommand("copy").

Copied indicators flash for 1500ms.

Time formatting

Time formatting prefers global moment if available:

• Absolute: D MMM YYYY HH:mm:ss
• Relative: fromNow()

If moment is not available, the widget falls back to native Date handling and a simple relative formatter.

Error handling

Load errors appear as a widget-level error banner.

Cancel errors appear inline on the affected execution row.

Stale responses are ignored via loadSequence(). Aborted requests are ignored during teardown.

Template highlights

The main template provides:

• Header with count and LIVE indicator.
• Manual refresh button.
• Loading state.
• Error banner.
• Filter chips.
• Empty state.
• Filtered empty state.
• Execution rows.
• Expandable detail panel.
• Sub-process list with state and flags.
• Detail hint pointing users to the modeller’s execution tooling for logs and variables.

Limitations

• Shows only currently tracked executions returned by the execution-engine endpoint.
• Does not show full completed workflow history.
• Does not expose per-step logs.
• Does not expose execution variables.
• Client-side filters the first 500 returned executions.
• Depends on internal APIs with no public equivalent at time of writing.
• Cancel requires appropriate platform permissions.

How it's built

Git is the single source of truth — the component lives at src/widgets/workflow-execution-inspector. Deployment is to the Sharedo IDE; the manifest defines how the platform loads it.

Workflow Execution Inspector — User Guide

Purpose

Use Workflow Execution Inspector when you need to see which workflows are currently active on a work item and what state they are in.

It is intended for support, operations, and administrator troubleshooting pages.

Adding the widget

1. Open the portal or page designer.
2. Add Workflow Execution Inspector from the Alterspective / Support category.
3. Place it on a work-item page or support page that has a current work-item context.
4. Save and publish the page.

The widget automatically uses the current work item from the page context. No field mapping is required.

Configuration

No placement settings are currently required.

The widget self-configures from the current page context and lists workflow executions for the current work item.

If the widget is opened somewhere without a work-item context, it will show a context error instead of execution data.

What users see

The widget header shows:

• The title Workflow Executions.
• A count of active execution rows when any exist.
• A LIVE indicator when auto-refresh is active.
• A manual refresh button.

Each execution row shows:

• State badge.
• Plan title.
• Plan system name where relevant.
• Start time.
• Plan type where available.
• Cancel button where the execution is cancellable.
• Expand/collapse chevron.

Using filters

Use the filter chips to narrow the list:

• All — all returned executions for this work item.
• Running — executions currently running.
• Waiting — executions paused or waiting.
• Errored — errored or failed executions.

Each chip shows a count.

Expanding a row

Click a workflow execution row to open more detail.

The expanded view may include:

• Plan description.
• Exact start time.
• Last errored time.
• Plan system name.
• Copy button for plan system name.
• Execution ID.
• Copy button for execution ID.
• Parent execution ID.
• Sub-processes.
• Sub-process state.
• Sub-process flags such as entry, end, optimal, and debug.

Use these details when escalating to a workflow designer, support engineer, or administrator.

Copying identifiers

In the expanded row, use:

• Copy beside Plan system name to copy the plan identifier.
• Copy beside Execution ID to copy the execution identifier.

A short “Copied” confirmation appears after a successful copy.

Cancelling an execution

If an execution is cancellable, a stop button appears on the row.

To cancel:

1. Click the stop button.
2. Confirm the browser prompt.
3. Wait for the row to refresh.

Cancellation requires the appropriate platform permission. If you do not have permission, the widget will show a row-level error message.

Only cancel an execution when you understand the business impact. Cancelling a workflow may stop downstream tasks, notifications, approvals, or automation.

Auto-refresh behaviour

The widget refreshes automatically every five seconds while any execution is running or waiting.

When there are no live executions, auto-refresh pauses.

You can always click the refresh button to reload manually.

Empty state

If the widget shows:

No active workflow executions on this work item.

then there are no currently tracked workflow executions for the current work item in the execution-engine list.

This does not necessarily mean no workflow has ever run. Completed history is outside this widget’s scope.

When to use other tools

Use the platform workflow modeller or execution administration screens when you need:

• Completed execution history.
• Per-step execution logs.
• Execution variables.
• Detailed workflow diagnostics.
• Full execution audit information.

Workflow Execution Inspector is a quick live triage tool, not a full workflow audit viewer.

Recommended audience

Recommended for:

• Support teams.
• Workflow administrators.
• Solution engineers.
• Internal operations users.
• Release verification users.

Not recommended for general end users unless they are expected to understand workflow execution states and cancellation impact.

How to use it

Add Workflow Execution Inspector to a portal page via the Sharedo Portal Designer (it appears under Alterspective / Support). Configure it via the designer cog on the placed widget.

For the authoritative configuration fields and behaviour, see the component's designer help panel and the source linked in the footer.