Demo: Continuous improvement for Process Street workflows

We have been testing a prototype that looks for improvement opportunities inside Process Street workflows.

In this Loom, Abdul walks through a simple employee onboarding workflow and shows how the prototype uses three signals: workflow run patterns, user feedback, and workflow design checks.

The interesting part is the review loop. The prototype does not just report that something is wrong. It suggests specific workflow updates, like stop tasks, SLA due dates, prerequisite checklists, evidence capture, and escalation steps, so the workflow owner can preview and approve the changes.

The loop is:

  1. Detect a bottleneck, repeated comment, or missing control.
  2. Preview the proposed workflow changes.
  3. Apply selected changes back to the workflow.
  4. Repeat across workflows over time.

This is still a demo, but the pattern is interesting because it turns workflow improvement into something that can happen from real run data and user feedback, not just periodic manual review.

For anyone running larger onboarding, compliance, QA, or recurring operations workflows: which improvement signals would be most useful to catch automatically?

Stalled runs, repeated comments, missing evidence, SLA gaps, skipped prerequisites, or something else?

Below is the breakdown of the full video if you prefer to skim it.

Video breakdown

1. Baseline onboarding workflow

Abdul starts with a simple new employee onboarding workflow. The workflow is intentionally basic so the continuous improvement engine has a clear example to analyze. The starting template includes seven onboarding tasks, including welcome and IT setup, workspace preparation, orientation sessions, compliance training, buddy assignment, manager check-in, and review goals.

Key point: The demo begins with a simple workflow template so the engine can show how it detects and fixes structural gaps.

00:00 to 00:37

2. Self-healing analysis

The continuous improvement engine offers three analysis modes: self-healing report, feedback report, and design audit. In the self-healing report, it analyzes completion patterns across workflow runs and detects that step four, compliance training, is the bottleneck. In this example, four out of four employees stall at the same point, which means twelve downstream tasks are never reached.

Key point: The engine finds run-pattern problems automatically and converts them into specific workflow improvement recommendations.

00:37 to 01:07

3. Previewing and applying recommended changes

Based on the detected pattern, the engine recommends three changes: add a stop gate, add a two business day SLA, and add a hidden manager escalation task using conditional logic. Abdul previews the changes, then applies them directly into the Process Street workflow template.

Key point: The workflow owner can review proposed changes before letting the engine update the live template.

01:07 to 01:48

4. Applied workflow updates

After applying the recommendations, the workflow template has been updated. The engine adds the stop task in the right place, applies a dynamic due date to compliance training, and inserts a manager escalation review task. The changes are made directly in Process Street, which removes the need for manual template editing.

Key point: The prototype demonstrates closed-loop improvement: analysis, recommendation, preview, and direct workflow update.

01:48 to 02:04

5. Feedback report

The feedback report analyzes comments from users who execute the workflow. In the demo, comments surface issues like missing VPN access, a broken training portal, and lack of urgency on compliance training. The engine turns those comments into themes and recommends changes like a prerequisite checklist, an “I’m Blocked” dropdown, and a conditional logic rule that shows a manager escalation task.

Key point: User comments become structured improvement signals instead of staying buried in workflow feedback.

02:04 to 02:38

6. Design audit

The design audit looks at the workflow itself and checks it against industry and use case best practices. It flags issues like missing evidence capture, missing stop gates, partial SLA coverage, missing linked resources, implicit dependencies, and missing onboarding checkpoints. It recommends changes by priority and lets the user preview and apply them.

Key point: The design audit expands the engine beyond run data and feedback by analyzing workflow structure against best practices.

02:38 to 03:29

FAQ

What is the continuous improvement engine shown in this demo?

The demo shows a prototype that connects to Process Street workflow data, reviews run patterns, user comments, and workflow design, then recommends improvements for a workflow owner to review. In this example, it analyzes a simple employee onboarding workflow and suggests changes to reduce bottlenecks.

Is this a released Process Street feature?

No. This post describes a demo that is still being tested, not a released product capability. The useful pattern is the workflow improvement loop: detect friction, recommend a change, preview it, and apply approved updates back to the workflow.

What workflow problems can this kind of analysis catch?

The demo focuses on stalled runs, repeated feedback, missing controls, weak SLA coverage, skipped prerequisites, missing evidence capture, and unclear escalation paths. Those signals are especially useful in onboarding, compliance, QA, and recurring operations workflows where small gaps can create repeated delays.

Can the engine update a Process Street workflow automatically?

The demo shows recommended changes being previewed and then applied to the workflow template. In practice, workflow updates like stop tasks, due dates, and escalation steps should stay review-gated so owners can approve changes before they affect a live process.

How is this different from manually reviewing workflows?

Manual workflow reviews usually happen periodically and depend on someone noticing the same issue repeatedly. This pattern turns workflow runs and user feedback into ongoing improvement signals, so owners can catch bottlenecks, missing controls, and design issues closer to when they happen.

Does this replace the workflow owner?

No. The demo is strongest as an assistant for workflow owners, not a replacement. It can surface patterns, suggest improvements, and prepare changes, but a human owner still decides which recommendations are appropriate for the process, team, and compliance context.