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.

Execution blade — diagram zoom/pan & edit workflow

The per-execution blade's Diagram view (blade.ts) supports scroll-to-zoom, drag-to-pan, and an Edit workflow header button:

• Zoom is a native wheel listener attached directly to .alt-weib-diagram

(ensureWheelListener) — not Knockout's declarative event: { wheel: ... } binding — so it can register with { passive: false } and call stopPropagation(), guaranteeing the gesture is fully claimed regardless of host/browser wheel-handling quirks. Scroll up (deltaY < 0) zooms in, scroll down zooms out, clamped 8%–300%; re-entering the Diagram tab preserves a zoom/pan the user already set (_userAdjusted guard) instead of re-fitting every time.

• Edit workflow (pencil icon, enabled once planSystemName resolves) opens the platform's

own visual workflow editor via $ui.stacks.openPanel("Sharedo.Core.Case.WorkflowEditor.WorkflowEditorBlade", { planSystemName }). Config shape verified against the platform's actual WorkflowEditorBlade constructor (Sharedo.Web.UI/Plugins/Sharedo.Core.Case/_Content/WorkflowEditor/WorkflowEditorBlade/blade.js in the evidence corpus) — { planSystemName } takes its "Edit" path (GET /api/executionengine/visualmodeller/plans/{planSystemName}), vs. { cloneSystemName } (clone-to-new) or {} (blank new plan). The blade reloads (load(self)) on the editor's closing event so a save is reflected immediately. sharedo.d.ts's SharedoStacks.openPanel was widened to accept the real 5-arg platform signature (id, config, events, isInNewWindow, refreshExisting — confirmed against ui-stackmanager.js) as optional params; existing 2-arg call sites are unaffected.

Execution blade — diagram edge timing & resizable detail panel

Pure logic lives in diagram-timing.ts (no KO/namespace() dependency, unit-tested in diagram-timing.test.ts) so it doesn't require the Sharedo/KO globals blade.ts needs at module load. blade.ts imports from it and wires it into the SVG diagram.

• Node clock time — each diagram node's sub-label shows the step's actual start time

(fmtNodeTime(info.startMs), "HH:mm:ss", no sub-second precision — the node is too small for it) alongside its state and duration, e.g. "Done · 16ms · 14:32:07". Uses the same startMs already populated for gap math (InspectorStep.startMs, set once the step's log loads) — no new data source. Blank when the step hasn't run yet or its log hasn't loaded.

• Executed vs. pending edges — the plan graph (GET /api/executionengine/visualmodeller/plans/{planSystemName})

shows every path the workflow could take; only some fired for a given run. isEdgeExecuted(fromSystemName, toInfo, edgeExecution) classifies an edge A→B as executed when B's live state is COMPLETE/RUNNING/WAITING/ERRORED (control actually reached it) — a todo target means that branch wasn't taken — and, for a fan-in/join target with more than one possible incoming edge, that A is specifically the one resolveEdgeExecution() determined actually fired. Without that disambiguation, every edge into a join step that ran would show as "taken" even for branches that never fired — resolveEdgeExecution reuses the same "latest predecessor whose endMs is still ≤ the target's startMs" heuristic as applyPlanGraphGaps (see below) to resolve which one it was; an unresolved fan-in (timestamps not loaded yet) conservatively reports no candidate edge as executed rather than guessing. Executed edges render solid + on-brand teal (.wfd-edge--executed, #036670) with their own arrowhead marker; pending edges render thin dashed grey (.wfd-edge--pending). Pending edges are drawn first so executed paths (and their gap labels) always sit on top at a branch point.

• Gap-time labels on edges — computeEdgeGapMs(fromInfo, toInfo) is `toInfo.startMs -

fromInfo.endMs (null when either timestamp isn't loaded yet, or the result isn't positive — clock skew / same-tick). Rendered as a small pill at the edge's Bézier midpoint (edgeMidpoint() — the specific horizontal-tangent control points this diagram uses make the t=0.5 point collapse to the plain average of the two endpoints, so no need to carry the control points through). gapTier(ms) escalates styling — trivial (<250ms, quiet grey) → normal (<5s) → notable (<60s, amber) → long` (≥60s, red/bold) — so a step stuck waiting on the Sharedo event engine for minutes stands out from a routine sub-second handoff.

• Graph-based gap for the steps list + detail panel — `applyPlanGraphGaps(plan, steps,

fmtDuration) supersedes the steps-list's original array-order gap guess (computeTimeline()'s "step N+1 followed step N" assumption, which is wrong for anything but a strictly linear plan) once the plan graph is available. For each step it walks the plan's real incoming connections and, among predecessors that actually ran, picks whichever has the latest endMs that's still ≤ this step's startMs — i.e. the one that actually triggered it in a fan-in. Mutates gapLabel/gapFromName in place; steps with no resolvable graph predecessor (entry points, or the predecessor's log hasn't loaded yet) keep the array-order fallback. The plan graph is fetched eagerly in load() regardless of which view is active — buildDiagram() fetches it when the Diagram tab is opened, but a background fetch also runs when the blade loads showing the Steps view, so Steps-only users get the same accurate gaps as Diagram visitors instead of only the array-order fallback (the SVG itself still isn't built until Diagram is actually opened — only the graph JSON is fetched early). Both paths go through ensurePlanGraph(), which caches the result on self._plan and shares one in-flight promise (self._planFetchPromise) — without it, switching to the Diagram tab before the Steps-view eager fetch resolves would fire a second, redundant network request for the identical graph. applyPlanGraphGaps is called from: that eager Steps-view fetch, buildDiagram(), refreshTimingDerivedState() (in turn called from every loadStepLog() resolution — see below), and refreshLive() (live re-poll) — each followed by self.model.steps.valueHasMutated() so the steps-list view picks up the mutation (gapLabel is a plain string, not an observable). gapFromName renders as "waited Xs after Main entry point" in both the steps-list gap connector and the diagram's node detail panel, instead of the ambiguous "waited Xs before" a branching workflow can't otherwise disambiguate. Gaps below MIN_STEPS_LIST_GAP_MS (1000ms, exported from diagram-timing.ts) are cleared (gapLabel/ gapFromName set to ""), not merely skipped — once the true predecessor resolves to a negligible gap, that's a real, more-accurate answer, and it must overwrite whatever computeTimeline's array-order guess had already put there (which may have been computed against an entirely different, wrong predecessor and shown an unrelated multi-second wait). The diagram's own edge labels (computeEdgeGapMs`) intentionally have no such floor — that view is opt-in and specifically about handoff timing, where sub-second gaps are still useful detail.

• Resizable detail panel — .wfd-detail (the inline node-detail panel opened by clicking a

diagram node) width is bound to detailWidth (KnockoutObservable<number>, default 340px, persisted to localStorage["alt-weib-detail-width"]), dragged via a .wfd-detail-resize handle on its left edge using the same left-edge-drag mechanic as the blade's own width resize (startResize/WIDTH_STORAGE_KEY). Clamped to [280px, 80% of the diagram stage width] (clampDetailWidth) so it can't swallow the whole diagram. The stored width is also re-clamped every time the panel opens (onDiagramClick), not only while dragging — a width persisted from a wider browser session would otherwise render past the intended 80% cap (CSS max-width: 90% is only a hard backstop, not the real target) until the next drag.

Execution blade — "Trigger → Start" headline metric

Shows the delay between the plan execution being queued and its entry step actually starting — the closest available signal for "how long after the trigger fired did the workflow start".

Confirmed live against a real execution (client UAT tenant, 2026-07-02) that the platform does not expose a trigger-fire timestamp separate from the execution record's own creation time: GET /api/executionengine/triggers/{triggerId} (the id each subProcess entry carries) returns the trigger's static condition config (e.g. "when a sharedo... reaches the phase of X") with planExecutionId: null / executionStepId: null — it's the reusable trigger definition, not a per-fire log entry. GET .../headline-execution-times?planExecutionId={id} returns {} for an in-progress execution. Neither the list nor detail execution endpoints carry a queue/fire timestamp distinct from startTime.

Given that, computeStartDelayMs(queuedMs, entryStepStartMs) (diagram-timing.ts) is entryStepStartMs - queuedMs, clamped to null when either input is missing or the result isn't positive:

• queuedMs — the execution record's own startTime, from the list endpoint

(GET /api/executionengine/plans/executing) — passed through as planStartTime when the widget opens the blade (core.ts's openInspector; the detail endpoint's own startTime field is unreliable — observed as 0001-01-01T00:00:00 / C#'s DateTime.MinValue for a live WAITING execution on the verified tenant, so the blade never reads it).

• entryStepStartMs — the entry step's (InspectorStep.entryPoint === true, falling back to

steps[0]) own earliest log timestamp (InspectorStep.startMs, set once its log loads).

applyStartDelay() is not a one-shot computation — an earlier version assumed "the entry step is always in the first MAX_EAGER_LOG_STEPS, so its startMs is populated by the time the eager background batch in load() resolves", which doesn't hold for the exact case this metric exists to surface: an execution that's still queued (entry step hasn't started — no executionStepId yet, so it isn't in that batch at all), or one where the entry step was also the blade's preselected/focused step, whose loadStepLog call from selectStep() was already in flight when the batch's own (force=false) call for the same step short-circuited on the logStatus === "loading" guard without actually waiting for it. Both left the metric permanently blank. Fixed by making applyStartDelay() re-run from wherever entry.startMs might actually become known:

• loadStepLog()'s success path calls refreshTimingDerivedState(self) — not just

applyStartDelay() — every time any step's log resolves, whichever code path fetched it (eager batch, manual selection, live-poll refresh). refreshTimingDerivedState() recomputes computeTimeline, applyPlanGraphGaps + the diagram SVG (when a plan is known), and applyStartDelay, then re-renders — the Trigger → Start metric is only one of several things that can go stale from the exact same short-circuited-duplicate-fetch race described above; the steps-list gap, graph-based gap, and diagram edge label for whichever step's log actually resolved late are just as affected, and would otherwise stay blank/stale until a full reload or the next live poll (which may never come if the execution has already finished).

• refreshLive() additionally watches for the entry step's executionStepId appearing on a live

poll (i.e. it just started) while its startMs still isn't known, and proactively fetches it with eager: true — otherwise a still-queued execution's entry step would never get its log requested at all until the user happened to click it. This is deliberately not gated on logStatus() === "idle": if the entry step was ever selectStep()-selected before it had an executionStepId (e.g. as load()'s preselect target, via the "waiting" branch of its selection chain — a step can apparently be WAITING before the engine assigns it an executionStepId), loadStepLog()'s own no-op guard (if (!step.executionStepId) { step.logStatus("loaded"); return; }) already left logStatus stuck at "loaded" despite nothing having actually been fetched — an idle-only gate would then never retry once the step legitimately starts. entry.startMs == null is itself what stops this from refetching once real data is in, so bypassing the stale status (matching the selected-step refresh right above it, which also uses eager: true) is safe.

"The entry step" is resolved by a shared findEntryStep(steps) (steps.find(s => s.entryPoint) || steps[0]) used by both of the above — they used to disagree (the refreshLive watcher checked entryPoint with no steps[0] fallback), so the proactive-fetch watcher could silently never fire for the exact plan where no step carries entryPoint: true and applyStartDelay was still falling back to steps[0].

Renders as a "Trigger → Start" headline metric next to Started/Duration/Steps, hidden entirely while unavailable (e.g. the blade was opened from somewhere other than the widget's row click, so planStartTime was never passed, or the entry step's log hasn't resolved yet) and appearing as soon as it is.

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.

Execution blade — Diagram view and editing the workflow

Clicking an execution row opens the execution blade, which offers a Diagram view alongside the Steps list: the workflow's designer layout, coloured live by each step's run state.

• Scroll to zoom in/out, drag to pan, click a step for its detail and log.
• Use Fit to view to re-centre; re-opening the Diagram tab keeps a zoom/pan you already set.
• Each node shows the clock time it actually ran at alongside its state and duration (e.g. "Done ·

16ms · 14:32:07"), not just how long it took.

• Edges show whether that path was actually taken (solid teal) or not taken (dashed grey)

— useful on a branching workflow to see which fork actually fired.

• Every executed edge is labelled with how long the handoff took — e.g. "waited 2.1s" — so you can

see the gap between one step finishing and the next starting, not just each step's own duration. The same gap (with which step it waited on) shows in the Steps list and in a clicked step's detail panel too.

• The node detail panel (opened by clicking a step in the diagram) is resizable — drag its left

edge; your chosen width is remembered.

• The headline row shows a Trigger → Start figure when available: the delay between the

workflow being queued and its first step actually starting — the closest signal the platform exposes for "how long after the trigger fired did the workflow start" (hover it for what exactly it measures). It only appears when you opened the blade from a row in this widget (so the queue time is known) and the entry step's log has loaded.

• The pencil icon Edit workflow definition in the blade header opens the platform's own

visual workflow editor for the workflow currently shown, so you can jump straight from triage into fixing the plan without hunting for it in the modeller. It's enabled once the plan's system name has loaded. Saving there and closing refreshes the execution blade.

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 beyond the diagram view.
• Full execution audit information.

Workflow Execution Inspector is a quick live triage tool, not a full workflow audit viewer — but the Edit workflow button gives you a direct path into the full editor when triage turns into a fix.

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.