FlowSharp - items, tasks and operational work

After Flow design comes daily work: real items, tasks, people, data, transitions, history and responsibility.

1. From Flow definition to real execution

The Flow is the model. The item is the real case moving through that model.

This distinction is essential:

• the Flow says how the process should work;
• the item shows what is happening in this specific case;
• tasks show what must be done now;
• the timeline explains what happened before;
• transitions show what can happen next.

In FlowSharp, the process does not remain a diagram: it becomes tracked work.

2. Items: active cases

An item can represent an order, customer request, contract, ticket, administrative case, project or any entity that must move through a process.

The Items list lets you:

• filter by flow, status, assignee, period and search text;
• switch between operational views;
• export data;
• create new items when the Flow allows it;
• open a quick view or the full detail.

3. Item detail and timeline

The item detail shows:

• current status;
• item data;
• active tasks;
• available transitions;
• item origin;
• related items;
• complete history;
• linked executions or automations;
• the Flow map;
• operational badges: status reason, WIP queue, priority.
• score, final outcome and any warning that the item departed from the expected path.

The goal is to let an operator understand what happened, what they must do now and what can happen next.

4. Tasks as units of work

The Tasks page is designed for people who must do or monitor operational work.

It lets you:

• see pending, running, completed, failed or skipped tasks;
• filter by flow, type, status, text and "only mine";
• switch between table, kanban and calendar views;
• open task detail;
• complete manual tasks;
• enter outcome, notes, feedback and rating;
• retry automatic tasks when allowed.

This area makes FlowSharp an operational workbench, not only a behind-the-scenes engine.

5. Human-in-the-loop

Human work is not an exception to tolerate: it is part of the process design.

FlowSharp can govern:

• approvals;
• quality checks;
• document reviews;
• responsibility decisions;
• escalations;
• data integration requests;
• feedback on AI output;
• closure activities.

A manual task can be assigned, completed, commented and measured. If it is blocking, the process waits. If it is non-blocking, it can coexist with background automation.

This makes clear where a person is needed, why they are needed and how much that step weighs in the overall process.

6. Origin, correlations and handoff

When an item starts from an event, another item, an API or an automation, FlowSharp shows the origin in a readable way.

Related items help show multiple cases connected to the same entity: for example a sales request that opens a project and then a billing process.

Handoffs become clearer because they no longer live only in chat or email: they are tracked steps, with status, responsibility and history.

7. Events between processes

Events are how FlowSharp connects different parts of a process.

An event can:

• be generated by a task;
• start another Flow;
• notify an external system;
• correlate items;
• represent a signal coming from another system.

Events let multiple Flows collaborate without turning everything into one huge process.

8. Operational workbench

Items and Tasks together form the operational workbench.

For an operator this means:

• knowing what to do now;
• seeing assigned cases;
• understanding priorities;
• completing activities without searching elsewhere;
• leaving outcome and notes.

For a manager this means:

• seeing workload and blocks;
• finding failed or late tasks;
• understanding where human support is needed;
• distinguishing repetitive work from decision work.

9. What changes for teams

FlowSharp moves work from "following the process from memory" to "working inside a visible process".

This reduces:

• dependency on email and spreadsheets;
• untracked steps;
• manual status chasing;
• decisions without context;
• automations disconnected from human work.

And increases:

• responsibility;
• audit;
• coordination;
• measurability;
• continuous improvement capability.

10. WIP queues, status reason and role-based visibility

When a flow uses WIP limits (see the "Flows and designer" guide), the queue becomes visible and actionable directly in daily work.

On the item detail:

• a "status reason" badge explains why the item is in its current phase (timed out, max iterations reached, redirected by WIP, etc.);
• a "WIP queued" badge indicates the item is waiting for capacity, with its position in the queue;
• when the phase allows it, a button lets an Admin force admission beyond the limit, with a mandatory reason;
• if a phase in "warning only" mode exceeds its limit, admitted items show an "Over WIP limit" badge.

On the board (Monitor):

• every waiting item shows the "WIP queued" badge and a P{n} priority tag;
• in the Kanban view, items queued for capacity drop below a dedicated separator, distinct from items actually being worked on;
• a "WIP queued" filter isolates everything parked waiting for capacity with one click.

Role-based visibility: Operator and ReadOnly users only see the flows where they can actually operate — published flows their role can start, or flows where they have (or had) an item. The rule applies to every view: flow list, items, history, activity and Process Maps. Admin and FlowDesigner users keep full visibility.

11. Journey quality and exceptional interventions

An item does not only tell you where it is: it also tells you how it got there. When a Flow has an expected path, the item detail and Monitor flag deviated cases. The timeline keeps the step that raised the warning alongside ordinary transitions and score changes.

This helps teams distinguish three different situations:

• a late or WIP-queued case, which is waiting for capacity;
• a deviated case, which followed an unexpected route but remains governed;
• a case held in an exception phase, which needs an action planned by the process or an authorized release.

When a case genuinely needs to be recovered, an Administrator can force a status change within the same Flow. It does not replace everyday rules: it is an operational-continuity measure, clearly recorded in the item's history.

12. Operational lists, columns and per-flow views

Lists work over the full server-side archive: search, status, date range and other filters are not limited to entries already loaded. Tasks and Events use Load more with a stable cursor, so concurrent inserts or deletes do not skip or repeat rows.

In a single Flow's table, the Columns button lets you choose:

• fixed operational columns;
• fields declared in the Flow registry, with their labels;
• observed fields, marked as having an inferred type.

Numbers, booleans, objects and missing values render according to type. Sorting runs on the server across all items, not just the open page. A Flow designer can save the layout as the team view; each user can keep a personal override and return to the shared view. A field removed from the registry remains recognizable as missing without breaking the table. Sensitive fields stay masked for the ReadOnly role and cannot be sorted by that role.

The All Items page also provides CSV export for the selected Flow and a calendar by start, scheduled, due or completion date. If the selected date field has no values in the period, the calendar switches to start date and says so instead of showing an empty view.

When two people edit the same item's data concurrently, the second save based on an outdated revision is stopped. The view reloads the latest data, preventing one operational change from silently erasing the other.

13. Notes and AI Item Overview

The detail page lets you add a human note: it enters the timeline and remains part of the case audit. The data JSON can be copied directly for review or an integration handoff.

When enabled, the AI Item Overview card presents:

• a concise assessment of the item's state;
• a readable level such as good, warning or critical;
• a few sentences based on data, history, notes and score.

The overview is regenerated in the background when the item changes status and can be refreshed manually. It can be disabled at organization, Flow or individual phase level. If the provider uses Data Shield, sensitive fields are shielded before the AI call. The same overview is available to the Flow Agent and, with the correct permissions, to the MCP tool that reads the item.

14. Operating procedures and task guides

The Procedures page brings SOPs, role manuals and instructions into operational work. Each procedure has immutable versions, author, change note and content fingerprint. Text can be written in Markdown or extracted from a PDF; headings become citable sections.

In the designer, a task guide can identify the procedure, version and section from which it derives. When a new SOP version is created:

• links to older versions are marked for realignment for Admins and Flow Designers;
• the procedure page shows coverage by Flow and task;
• the designer can review the guide and mark it aligned to the current version;
• the operator continues to see the guide and its source citation, without maintenance warnings.

The premium generator proposes guides from the procedure, but always requires human review and confirmation before applying them. SOP links remain in exports/imports, templates and new Flow versions.

A procedure can be archived and restored. Permanent deletion is restricted to Admins, requires strong confirmation and is allowed only when the archived procedure is no longer linked.

For a need not anticipated by the model, authorized roles can also add an ad-hoc manual task from the item detail and choose whether it blocks the path. The task is limited to that case and enters the same history as other tasks.

15. Multichannel alerts and acknowledgement

Notification policies govern human work that remains waiting. A policy contains timed steps and can use email, webhook or event; a Flow can use the organization's default policy or a dedicated one.

To reduce noise:

• alerts for the same recipient can be grouped into a digest;
• allowed delivery hours respect the organization's time zone and daylight saving time;
• email and webhook deliveries outside the window are rescheduled, while in-app notifications remain immediate.

The recipient can acknowledge the alert from the notification bell or through a signed link received by email/webhook. Completing the task or advancing the item automatically resolves the wait. In Management → Notifications, Admins can also review acknowledgement and resolution times.

A Flow can be excluded from Dashboards and Analytics when it represents technical or test work. It can also define retention for completed items: at expiry, history is permanently deleted, so the policy must reflect operating and record-retention obligations.

16. Automation-stall alerts

When an item remains in an Auto/AI state because of NO_RULES, NO_MATCH_NO_DEFAULT, ALL_RULES_ERROR, or AI_EXECUTION_FAILED, FlowSharp creates one persistent AutomationStalled alert per item and status. Active tenant Admins receive it according to the flow alert policy and can acknowledge it like other alerts.

The alert resolves when the item leaves its anchor status. It is distinct from the statistical Process Map stall: the former records a specific runtime cause, while the latter is a signal calculated from process behavior.

Exceptional recovery requires an Admin and a reason. REST force-transition and the MCP force_transition tool share one service; they deliberately bypass adjacency and WIP, close abandoned tasks, and write an audit record. transition_item remains the ordinary channel and accepts no bypass.