Roadmap

# Elsa Roadmap

Last refreshed: 2026-09-09 (post-3.8 Studio BPMN and runtime-admission status)

This roadmap is a product direction document, not a fixed release calendar. Elsa is developed through a mix of core maintainer work, customer-funded work, and community contributions, so sequencing can change when real-world demand changes. The intent is stable: make Elsa the most productive, dependable, and extensible workflow platform for the .NET ecosystem.

This version is grounded in the current `elsa-core`, `elsa-studio`, and `elsa-extensions` repositories, including source code, open issues, open pull requests, releases, and discussions where available.

## North Star

Elsa should feel like the natural workflow engine for .NET teams:

- productive enough for application developers to model real business processes quickly
- dependable enough for production operations, rolling deploys, multi-tenant systems, and distributed workloads
- open enough to embed, customize, extend, and automate without fighting the framework
- powerful enough to connect systems, run long-lived processes, expose human tasks, and observe what is happening

## Capability Checklist

Legend: `[x]` shipped foundation, `[~]` partially shipped or needs productization, `[ ]` roadmap candidate.

### Engine

- [x] Non-blocking activity execution
- [x] Fork, join, and explicit flowchart merge modes
- [x] State machine core activity
- [~] State machine Studio semantic authoring is released in `3.8.0`; maintained docs/examples and broader authenticated browser validation remain
- [~] Extensible activity output conversion: Core contracts, descriptor discovery, binding validation, and Studio selection/settings UX are released in `3.8.0`; a maintained extension converter catalog remains productization work
- [~] Graceful shutdown and interrupted recovery
- [ ] Atomic workflow admission for configured activation strategies across every start path; correlated and singleton policies need an atomic reservation rather than a check-then-act count ([#7948](https://github.com/elsa-workflows/elsa-core/issues/7948), [#8042](https://github.com/elsa-workflows/elsa-core/issues/8042))
- [ ] Full workflow execution recovery UX
- [ ] Compensation / saga support
- [ ] Variable history tracking
- [ ] Native workflow-aware background execution
- [ ] Actor-runtime abstraction

### Runtime And Operations

- [x] Runtime admin pause, resume, status, and force-drain endpoints
- [x] Distributed runtime package
- [x] Structured logs
- [x] Console logs
- [x] Studio structured-log, console-log, and OpenTelemetry diagnostics foundations
- [x] Durable structured log persistence
- [~] Operational dashboard API and Studio dashboard productization
- [~] Scheduler and message-bus foundations through Quartz, Hangfire, MassTransit, Kafka, and Azure Service Bus
- [~] OpenTelemetry diagnostics backend and default workflow metrics
- [ ] Scheduler/message reliability hardening for clustered production workloads
- [ ] Production security guide
- [ ] Enterprise deployment platform and checklist

### Authoring And Studio

- [x] Visual designer foundation
- [x] Modular Studio shell, feature system, menus, widgets, themes, localization, and remote feature gating
- [x] Studio custom elements for embedding definition editors, instance viewers, and workflow lists
- [x] Activity unit testing helpers
- [x] ElsaScript experimental DSL
- [~] React Flow, sequence, and state-machine designer foundations
- [~] Workflow organization with labels/categories/folders
- [~] Workflow progress/timeline surface
- [x] Studio OIDC and identity modules
- [~] External-authentication broker, Studio SSO connection management, and configurable login themes (released in `3.8.0`; operational recipes and broader provider verification remain)
- [~] Studio user and role administration (released in `3.8.0`; operational verification and authoring-side governance remain)
- [~] Studio diagnostics pages for structured logs, console logs, and OpenTelemetry
- [~] Studio alterations module
- [~] User Tasks and human-workflow workbench: identity-neutral workflow tasks and the paired Studio workbench are on `main`; release packaging, realtime delivery, and operational validation remain
- [ ] Designer reliability/regression hardening
- [ ] Input validation and activity version visibility
- [ ] Async dispatch/run UX
- [ ] User preferences, table state, and layout persistence
- [ ] First-class workflow debugging
- [ ] Designer extensibility, embedding, and white-label recipes
- [ ] Tenant/role-based activity visibility
- [~] AI-assisted workflow generation and copilot foundations

### Integrations

- [x] HTTP, scheduling, scripting, and persistence provider foundations
- [x] Connections and Secrets foundations
- [x] Extension packages for SQL, CSV, Email, Slack, Telnyx, GitHub DevOps, Azure Storage, Azure Service Bus, Kafka, MassTransit/RabbitMQ, Quartz, Hangfire, Dapper, MongoDB, Elasticsearch, OpenTelemetry, Logging, Agents, OpenAPI, Webhooks, OrchardCore, IO, compression, and ProtoActor-backed runtime/caching
- [~] MQTT publish and message-trigger foundation (main-only; release and production hardening pending)
- [~] Modular package loading and manifest metadata
- [~] OpenAPI activity/provider foundations
- [ ] Connector SDK
- [ ] Marketplace/plugin installation
- [~] Agent provider matrix, with MCP/tool lifecycle still roadmap
- [ ] Dynamic activity generation from OpenAPI, Azure Functions, registered methods, and schemas
- [ ] Azure DevOps, Teams, OneDrive, SharePoint, Google Docs, and Google Sheets integration strategy
- [ ] SQL authoring quality: Studio drag/drop reliability and IntelliSense
- [~] Dapper package split and MongoDB secrets parity
- [ ] MassTransit v9 strategy
- [ ] Azure Functions / worker-service hosting guidance
- [ ] WatchFileSystem and command-line automation activities
- [ ] Data pipeline / ETL primitives
- [~] BPMN execution and interchange foundations, with main-only Studio schema types, rendering, import/export, and nested-scope authoring; broader editing, inspection, conformance, and release packaging remain ([elsa-studio#1008](https://github.com/elsa-workflows/elsa-studio/pull/1008)-[#1013](https://github.com/elsa-workflows/elsa-studio/pull/1013))

## Current Foundations

These are already present in the codebase and should be treated as foundations for the next roadmap slices:

- Multi-targeting for `net8.0`, `net9.0`, and `net10.0` in [`src/Directory.Build.props`](src/Directory.Build.props).
- The `3.7.0` release train shipped across [Core](https://github.com/elsa-workflows/elsa-core/releases/tag/3.7.0), [Studio](https://github.com/elsa-workflows/elsa-studio/releases/tag/3.7.0), and [Extensions](https://github.com/elsa-workflows/elsa-extensions/releases/tag/3.7.0) in May 2026, promoting shell integration, Studio authentication, workflow diagnostics, and extension package metadata into released foundations. The [Core](https://github.com/elsa-workflows/elsa-core/releases/tag/3.8.0-preview1) and [Studio](https://github.com/elsa-workflows/elsa-studio/releases/tag/3.8.0-preview1) `3.8.0-preview1` releases on June 1, 2026 then added the next preview slice of graceful shutdown, richer diagnostics, secrets, and newer designer surfaces. The `3.7.1` patch train then shipped across [Core](https://github.com/elsa-workflows/elsa-core/releases/tag/3.7.1), [Studio](https://github.com/elsa-workflows/elsa-studio/releases/tag/3.7.1), and [Extensions](https://github.com/elsa-workflows/elsa-extensions/releases/tag/3.7.1) on June 21, 2026, tightening Azure Service Bus startup reliability, aligning Studio with the released Core API client, and hardening Quartz durability and endpoint-name pressure in Extensions. [Core](https://github.com/elsa-workflows/elsa-core/releases/tag/3.8.0-rc2), [Studio](https://github.com/elsa-workflows/elsa-studio/releases/tag/3.8.0-rc2), and [Extensions](https://github.com/elsa-workflows/elsa-extensions/releases/tag/3.8.0-rc2) then published `3.8.0-rc2` between August 21 and 23, consolidating the production-operability, security, secrets, SSO, observability, newer designer surfaces, and BPMN package foundations ahead of the final 3.8 release.
- Elsa `3.8.0` stable shipped on September 5, 2026 across [Core](https://github.com/elsa-workflows/elsa-core/releases/tag/3.8.0), [Studio](https://github.com/elsa-workflows/elsa-studio/releases/tag/3.8.0), and [Extensions](https://github.com/elsa-workflows/elsa-extensions/releases/tag/3.8.0). It releases the paired diagnostics, dashboard, Secrets, external authentication, Weaver, and newer Studio designer foundations, plus runtime and security hardening. These opt-in modules still require host configuration. This is a release-status update, not a claim that every feature on `main` or every broader productization item shipped in this stable branch.
- Modular core packages under [`src/modules`](src/modules), with code-first features and CShells shell features documented in [`doc/wiki/module-system.md`](doc/wiki/module-system.md).
- A modular server host using CShells and Nuplane package loading in [`src/apps/Elsa.ModularServer.Web`](src/apps/Elsa.ModularServer.Web).
- Runtime admin, quiescence, drain, and interrupted recovery infrastructure in [`Elsa.Workflows.Runtime`](src/modules/Elsa.Workflows.Runtime) and runtime admin endpoints in [`Elsa.Workflows.Api`](src/modules/Elsa.Workflows.Api/Endpoints/RuntimeAdmin).
- Distributed runtime support in [`Elsa.Workflows.Runtime.Distributed`](src/modules/Elsa.Workflows.Runtime.Distributed).
- Structured diagnostics with recent/live capture plus SQLite persistence in [`Elsa.Diagnostics.StructuredLogs`](src/modules/Elsa.Diagnostics.StructuredLogs) and [`Elsa.Diagnostics.StructuredLogs.Persistence.Sqlite`](src/modules/Elsa.Diagnostics.StructuredLogs.Persistence.Sqlite).
- Raw stdout/stderr console diagnostics in [`Elsa.Diagnostics.ConsoleLogs`](src/modules/Elsa.Diagnostics.ConsoleLogs), with the post-3.7 console pipeline now carrying workflow and activity execution context through [PR #7536](https://github.com/elsa-workflows/elsa-core/pull/7536).
- Core `3.8.0` includes `Elsa.Diagnostics.OpenTelemetry`, which provides OTLP ingestion, bounded in-memory storage, REST APIs, SignalR live updates, collector configuration, permissions, and tests in [`src/modules/Elsa.Diagnostics.OpenTelemetry`](src/modules/Elsa.Diagnostics.OpenTelemetry). The productization gap is no longer "does a backend exist?" but rather operational recipes, default workflow semantic metrics, and diagnostics correlation.
- Core `3.8.0` includes [`Elsa.Dashboard.Api`](src/modules/Elsa.Dashboard.Api), a read-only operational-dashboard backend with overview, trends, attention, recent-activity, and workflow-hotspot endpoints plus independent diagnostics capability states ([#7529](https://github.com/elsa-workflows/elsa-core/pull/7529), [#7532](https://github.com/elsa-workflows/elsa-core/pull/7532)). Studio `3.8.0` supplies the operational health, trends, activity, attention, and diagnostics surface through [elsa-studio#923](https://github.com/elsa-workflows/elsa-studio/pull/923); broader operational verification, robust deep links, and unavailable-state handling remain productization work.
- Core `main` now includes `Elsa.AI.Abstractions`, `Elsa.AI.Host`, `Elsa.AI.Copilot`, and `Elsa.AI.Persistence.EFCore` through [PR #7523](https://github.com/elsa-workflows/elsa-core/pull/7523), and Studio `main` now includes `Elsa.Studio.AI` through [elsa-studio#900](https://github.com/elsa-workflows/elsa-studio/pull/900). That gives Weaver both server and Studio workspace foundations, while proposal actions, broader authoring contracts, and polished product UX remain roadmap work.
- State machine core activity support in [`Elsa.Workflows.Core/Activities/StateMachine`](src/modules/Elsa.Workflows.Core/Activities/StateMachine).
- Studio's state-machine designer now has semantic lifecycle slots, a context-aware activity picker, malformed-definition preservation, and nested-designer support through [elsa-studio#958](https://github.com/elsa-workflows/elsa-studio/pull/958) and [elsa-studio#959](https://github.com/elsa-workflows/elsa-studio/pull/959). The semantic-authoring foundation is released in `3.8.0`, with further StateMachine runtime and designer fixes in [Core #8010](https://github.com/elsa-workflows/elsa-core/pull/8010) and [Studio #985](https://github.com/elsa-workflows/elsa-studio/pull/985). Maintained documentation/examples and broader authenticated browser validation still keep the product surface partial.
- Core `main` now has extensible output-converter contracts, registration, definition/runtime validation, privacy-safe conversion faults, and an authorized descriptor API through [PR #7902](https://github.com/elsa-workflows/elsa-core/pull/7902). Studio `main` consumes that API with unavailable-state handling, converter selection, and schema-driven settings editing in [elsa-studio#922](https://github.com/elsa-workflows/elsa-studio/pull/922). Converters are opt-in at a variable or workflow-output binding, so the activity output and its diagnostics remain native. This foundation is included in `3.8.0`; a maintained extension converter catalog is still follow-up work ([#7770](https://github.com/elsa-workflows/elsa-core/issues/7770), [elsa-extensions#164](https://github.com/elsa-workflows/elsa-extensions/issues/164)).
- ElsaScript DSL and blob storage integration in [`Elsa.Dsl.ElsaScript`](src/modules/Elsa.Dsl.ElsaScript) and [`Elsa.WorkflowProviders.BlobStorage.ElsaScript`](src/modules/Elsa.WorkflowProviders.BlobStorage.ElsaScript).
- Core `main` now contains `Elsa.Bpmn` and `Elsa.Bpmn.Interchange`: a BPMN process container, persisted execution state, activity bindings, message/signal/timer triggers, and analyze/import/export endpoints ([#7938](https://github.com/elsa-workflows/elsa-core/pull/7938), [#7945](https://github.com/elsa-workflows/elsa-core/pull/7945), [#7946](https://github.com/elsa-workflows/elsa-core/pull/7946), [#7954](https://github.com/elsa-workflows/elsa-core/pull/7954), [#7956](https://github.com/elsa-workflows/elsa-core/pull/7956)). The two packages joined Core `3.8.0-rc2` through [#7970](https://github.com/elsa-workflows/elsa-core/pull/7970). Studio `main` now adds schema-generated BPMN payload types, a canvas-neutral model and X6 renderer, read-only imported-process viewing, import/export, and nested-process-scope authoring ([elsa-studio#1008](https://github.com/elsa-workflows/elsa-studio/pull/1008), [#1009](https://github.com/elsa-workflows/elsa-studio/pull/1009), [#1010](https://github.com/elsa-workflows/elsa-studio/pull/1010), [#1011](https://github.com/elsa-workflows/elsa-studio/pull/1011), [#1012](https://github.com/elsa-workflows/elsa-studio/pull/1012), [#1013](https://github.com/elsa-workflows/elsa-studio/pull/1013)). This Studio slice landed after `3.8.0` and is not a release claim. Publish-time validation, compensation/transaction and event-subprocess conformance, full element/property editing, element-level instance inspection, configured-host verification, and release packaging remain productization work ([#7958](https://github.com/elsa-workflows/elsa-core/pull/7958), [#7960](https://github.com/elsa-workflows/elsa-core/pull/7960), [#7909](https://github.com/elsa-workflows/elsa-core/issues/7909), [elsa-studio#1000](https://github.com/elsa-workflows/elsa-studio/issues/1000), [elsa-studio#1001](https://github.com/elsa-workflows/elsa-studio/issues/1001), [elsa-studio#1004](https://github.com/elsa-workflows/elsa-studio/issues/1004)).
- Core and Studio `main` now provide the paired User Tasks foundation: Core has durable, identity-neutral workflow-bound tasks, authorized lifecycle APIs, guest invitations, workers, and in-memory, EF Core, and VNext persistence; Studio has a capability-gated queue, detail and manager workspace, guest completion page, and polling fallback ([#7955](https://github.com/elsa-workflows/elsa-core/pull/7955), [elsa-studio#941](https://github.com/elsa-workflows/elsa-studio/pull/941)). It landed after `3.8.0-rc2`, so release packaging, Core realtime invalidation, cross-provider conformance coverage, samples, and operational validation remain.
- Activity unit testing helpers and guidance in [`src/common/Elsa.Testing.Shared`](src/common/Elsa.Testing.Shared) and [`doc/qa/test-guidelines.md`](doc/qa/test-guidelines.md).
- Label infrastructure now spans Core and Studio: [`Elsa.Labels`](src/modules/Elsa.Labels) exposes label and workflow-label endpoints, and [`Elsa.Studio.Labels`](https://github.com/elsa-workflows/elsa-studio/tree/main/src/modules/Elsa.Studio.Labels) adds label management pages plus workflow-definition label editing. Folder views, broader metadata search, and richer organization UX remain roadmap work.
- Elsa Studio is already a modular Blazor product shell with workflow authoring, instance browsing, designer modules, diagnostics, authentication, localization, branding, custom elements, and early React wrapper work in [elsa-workflows/elsa-studio](https://github.com/elsa-workflows/elsa-studio).
- Studio `3.7.0` shipped the modern authentication framework, Elsa Identity and OIDC modules, activity call-stack visualization, incident count badges, pending-instance filtering, and custom theme/DataPanel extensibility.
- Studio `3.8.0-preview1` shipped the server logs module, console logs module, structured-log storage diagnostics, the OpenTelemetry diagnostics page from [elsa-studio#834](https://github.com/elsa-workflows/elsa-studio/pull/834), sequence and state-machine designer foundations, the secrets module, and the alterations designer.
- Core `3.8.0-rc1` contains a protocol-neutral external-authentication broker with configuration- or database-backed OIDC connections, PKCE, secret handling, identity linking/JIT users, session management, persistence, and tests ([#7889](https://github.com/elsa-workflows/elsa-core/pull/7889)). Its Studio companions add Settings-based SSO connection management and a generic login-method UI ([elsa-studio#920](https://github.com/elsa-workflows/elsa-studio/pull/920)), configurable login themes ([elsa-studio#921](https://github.com/elsa-workflows/elsa-studio/pull/921)), and the all-host feature-stack integration ([elsa-studio#925](https://github.com/elsa-workflows/elsa-studio/pull/925) through [elsa-studio#931](https://github.com/elsa-workflows/elsa-studio/pull/931)). The cross-repository stable release is now complete in `3.8.0`; operational verification, provider coverage, and maintained documentation remain productization work.
- Studio `3.8.0-rc2` now has permission-aware user and role list, create, edit, and delete flows; role assignments; permission-token editing; tenant-scope display; and Server/WASM API-client integration ([elsa-studio#936](https://github.com/elsa-workflows/elsa-studio/pull/936)). This is a partially shipped identity-administration foundation, not workflow-authoring governance: broader operational validation and documentation remain after the `3.8.0` stable release, and tenant/role-based activity visibility is still roadmap work.
- Core `main` now has a structured `{resource}:{verb}` authorization model with hierarchical wildcard matching, a module-contributed permission catalog, endpoint-coverage enforcement, permission introspection, revocation bounds, and tenant-isolation hardening ([#7980](https://github.com/elsa-workflows/elsa-core/pull/7980)). This breaking change landed after `3.8.0-rc2`; migration support, broader live-host verification, and client-side governance remain productization work.
- Core `main` now scopes managed Secrets to the active tenant and makes secret names unique per tenant ([#7991](https://github.com/elsa-workflows/elsa-core/pull/7991)). Existing multi-tenant secret rows remain in the default tenant until deliberately assigned, and the VNext document store fails closed outside that tenant rather than exposing another tenant's secret. This is an important security foundation, with migration planning and tenant-aware VNext storage still productization work.
- Elsa Extensions is an active modular integration repository with 70+ module projects in [elsa-workflows/elsa-extensions](https://github.com/elsa-workflows/elsa-extensions), targeting `net8.0`, `net9.0`, and `net10.0`.
- Extensions already provide broad integration foundations: Connections, Secrets, Agents, OpenAPI, SQL/CSV/data tooling, messaging, schedulers, cloud storage, logging, webhooks, persistence providers, LDAP, and external system activities.
- Extensions `3.7.0` adds package manifest metadata, infrastructure attributes, shell features for MassTransit/Quartz/Webhooks, Dapper and MongoDB activity execution-chain lookups, Dapper bookmark queue filtering, Kafka multitenancy/schema-trigger work, Quartz lifecycle/job cleanup fixes, and other operational hardening.
- Extensions `main` now includes an MQTT module with publish and message-received trigger activities, broker/TLS/QoS configuration, Studio UI hints, and focused tests ([elsa-extensions#157](https://github.com/elsa-workflows/elsa-extensions/pull/157)). It remains a main-only foundation; its documented MQTT 5, advanced TLS, binary-payload, and error/DLQ gaps keep release and operational productization on the roadmap.

The public roadmap issue remains useful history: [elsa-workflows/elsa-core#3232](https://github.com/elsa-workflows/elsa-core/issues/3232). Several items in that issue are now done in code but still open in the issue body, so this file should be considered the current working roadmap.

## 1. Production Confidence

**Goal:** Operators should trust Elsa during deploys, restarts, scale-out, tenancy changes, and partial failures.

High-value items:

- Complete the graceful-shutdown operational slice: back-pressure-aware bookmark queueing, health checks, pause persistence across reactivation, and contract tests. The remaining task list is visible in [`specs/002-graceful-shutdown/tasks.md`](specs/002-graceful-shutdown/tasks.md).
- Close the workflow recovery story around interrupted, crashed, and stuck-running instances. This directly addresses [#4833](https://github.com/elsa-workflows/elsa-core/issues/4833) and should include Studio-facing recovery states, operator actions, and clear audit records.
- Harden distributed execution semantics: child workflow completion, bookmark races, duplicate dispatch, timer/delay behavior, and clustered refresh/reload. Community signal shows this repeatedly in [discussion #5857](https://github.com/elsa-workflows/elsa-core/discussions/5857), [#7397](https://github.com/elsa-workflows/elsa-core/issues/7397), [#7405](https://github.com/elsa-workflows/elsa-core/issues/7405), and related FlowJoin/bookmark issues.
- Treat scheduler and messaging correctness as release-blocking infrastructure. The new `3.7.1` patch line improved Azure Service Bus startup behavior and stable instance naming in Core ([#7732](https://github.com/elsa-workflows/elsa-core/issues/7732), [#7736](https://github.com/elsa-workflows/elsa-core/issues/7736), [#7742](https://github.com/elsa-workflows/elsa-core/pull/7742)) and tightened Quartz durable trigger scheduling in Extensions ([elsa-extensions#162](https://github.com/elsa-workflows/elsa-extensions/pull/162)). Current unreleased Extensions work on Proto.Actor startup ordering, remote configuration, subscriber storage, and per-member cache invalidation ([elsa-extensions#168](https://github.com/elsa-workflows/elsa-extensions/pull/168), [elsa-extensions#171](https://github.com/elsa-workflows/elsa-extensions/pull/171), [elsa-extensions#172](https://github.com/elsa-workflows/elsa-extensions/pull/172), [elsa-extensions#174](https://github.com/elsa-workflows/elsa-extensions/pull/174)), plus Quartz provider configuration ([elsa-extensions#176](https://github.com/elsa-workflows/elsa-extensions/pull/176)), reinforces the same need. Active issues around Quartz clustering and recovery ([elsa-extensions#109](https://github.com/elsa-workflows/elsa-extensions/issues/109), [elsa-extensions#101](https://github.com/elsa-workflows/elsa-extensions/issues/101)), Hangfire duplicate jobs ([elsa-extensions#121](https://github.com/elsa-workflows/elsa-extensions/issues/121)), MassTransit stimulus routing ([elsa-extensions#72](https://github.com/elsa-workflows/elsa-extensions/issues/72)), Kafka extensibility ([elsa-extensions#134](https://github.com/elsa-workflows/elsa-extensions/issues/134)), and Azure Service Bus backlog/startup pressure ([#7735](https://github.com/elsa-workflows/elsa-core/issues/7735), [#7737](https://github.com/elsa-workflows/elsa-core/issues/7737)) all point to the same production theme: clustered workload behavior must be boring, observable, and customizable.
- Turn the draft native background execution architecture into an implementation plan. [#7356](https://github.com/elsa-workflows/elsa-core/issues/7356) and [#7313](https://github.com/elsa-workflows/elsa-core/issues/7313) point toward an engine-owned, workflow-aware runtime that can evolve toward an actor-model abstraction without coupling Elsa to Orleans, Proto.Actor, or any single backend.
- Treat persistence and migration reliability as a product feature: provider-specific migration validation, large-tenant performance tests, safer defaults, and upgrade notes that cover SQL Server, PostgreSQL, MySQL, SQLite, Oracle, and MongoDB scenarios.
- Promote the Elsa Deployment Platform PRD into scoped implementation work. [#7469](https://github.com/elsa-workflows/elsa-core/issues/7469) defines the right product boundary: declarative environment manifests, immutable deployment artifacts, dry-run validation, deployment history, and GitOps-compatible reconciliation should manage control-plane state without reconciling runtime execution state.
- Maintain a security hardening track: document scripting trust boundaries, production-safe Docker posture, OIDC setup, default auth patterns, and secrets redaction. [#7096](https://github.com/elsa-workflows/elsa-core/issues/7096) is a reminder that optional code execution must be explained and guarded clearly.

Recommended success measures:

- rolling deploys do not leave workflows ambiguous or unrecoverable
- every runtime admin action is observable and auditable
- deployments can be previewed, validated, promoted, rolled back, and audited without copying databases or reconciling runtime state
- core distributed scenarios have component tests, not only unit coverage
- upgrade guides call out migrations, package renames, and production security implications before users hit them

## 2. Authoring Productivity

**Goal:** Developers and business users should be able to create, understand, test, and change workflows without ceremony.

High-value items:

- Ship workflow organization as a coherent feature: labels/categories, folder-like views, search/filter by metadata, and Studio support. This consolidates [#5872](https://github.com/elsa-workflows/elsa-core/issues/5872), [#6307](https://github.com/elsa-workflows/elsa-core/issues/6307), the existing `Elsa.Labels` module, and workflow definition `CustomProperties`.
- Make designer reliability a visible workstream. Recent Studio issues show expression/input rendering regressions after 3.6 ([elsa-studio#791](https://github.com/elsa-workflows/elsa-studio/issues/791), [elsa-studio#781](https://github.com/elsa-workflows/elsa-studio/issues/781), [elsa-studio#795](https://github.com/elsa-workflows/elsa-studio/issues/795)), persistent browser/JS failures ([elsa-studio#903](https://github.com/elsa-workflows/elsa-studio/issues/903)), and fragile Playwright automation ([elsa-studio#919](https://github.com/elsa-workflows/elsa-studio/issues/919)). These should drive a regression harness for designer rendering, property editors, expression descriptors, drag/drop, stable test identifiers, deterministic canvas state, and WASM/Server parity.
- Make workflow progress visible to application users: a current-state/step API, timeline model, and embeddable progress component. This responds to [discussion #6012](https://github.com/elsa-workflows/elsa-core/discussions/6012) and should reuse execution logs, activity records, call-stack tracking, and real-time workflow updates.
- Finish the state machine product surface. Core support is in place and the `release/3.8.0` Studio branch now adds semantic lifecycle editing and safe malformed-definition handling ([elsa-studio#958](https://github.com/elsa-workflows/elsa-studio/pull/958), [elsa-studio#959](https://github.com/elsa-workflows/elsa-studio/pull/959)); [#5085](https://github.com/elsa-workflows/elsa-core/issues/5085) should close only after docs/examples and authenticated browser validation make the released `3.8.0` workflow approachable.
- Build first-class workflow testing and debugging: test runners for full workflows, breakpoint-like inspection, replay from execution logs where feasible, better failed-activity retry flows, child/descendant workflow instance navigation, and Studio affordances for fault investigation. The Studio `3.7.0` activity call-stack viewer is a useful foundation, but requests for child workflow visibility ([elsa-studio#152](https://github.com/elsa-workflows/elsa-studio/issues/152)) and breakpoint debugging ([elsa-studio discussion #662](https://github.com/elsa-workflows/elsa-studio/discussions/662)) still need a coherent debugging experience.
- Productize the paired User Tasks implementation into a released human-workflow feature. Core now supplies durable, identity-neutral workflow tasks, invitations/guest sessions, authorization, persistence, audit, and delivery reliability; Studio supplies the queue, task/manager workbench, guest completion page, and polling fallback ([#7955](https://github.com/elsa-workflows/elsa-core/pull/7955), [elsa-studio#941](https://github.com/elsa-workflows/elsa-studio/pull/941)). Prioritize release packaging, a Core invalidation hub, cross-provider conformance coverage, samples, and operational validation.
- Improve Studio authoring fundamentals: input validation ([elsa-studio#15](https://github.com/elsa-workflows/elsa-studio/issues/15)), activity version indicators ([elsa-studio#284](https://github.com/elsa-workflows/elsa-studio/issues/284)), async `/dispatch` instead of blocking `/execute` where appropriate ([elsa-studio#811](https://github.com/elsa-workflows/elsa-studio/issues/811)), designer image export ([elsa-studio#585](https://github.com/elsa-workflows/elsa-studio/issues/585)), and expression evaluation controls ([elsa-studio#643](https://github.com/elsa-workflows/elsa-studio/issues/643)).
- Productize activity output conversion across Core, Studio, and Extensions. Core now supplies opt-in, typed, server-discoverable converter contracts, while Studio `main` provides selection and schema-driven settings editing ([#7902](https://github.com/elsa-workflows/elsa-core/pull/7902), [elsa-studio#922](https://github.com/elsa-workflows/elsa-studio/pull/922)). Release the cross-repository slice and add a small, maintained extension converter catalog instead of workflow-specific wrapper activities ([#7770](https://github.com/elsa-workflows/elsa-core/issues/7770), [elsa-extensions#164](https://github.com/elsa-workflows/elsa-extensions/issues/164)).
- Improve designer extensibility, embedding, and white-labeling: custom activity property editors, custom list actions, embeddable designer/viewer recipes, custom elements, React wrapper direction, auth modes, base-path hosting, branding/theme, and clear Blazor/WASM/Server guidance. Community demand appears in [#4743](https://github.com/elsa-workflows/elsa-core/issues/4743), [#6685](https://github.com/elsa-workflows/elsa-core/issues/6685), [discussion #7246](https://github.com/elsa-workflows/elsa-core/discussions/7246), [elsa-studio#137](https://github.com/elsa-workflows/elsa-studio/issues/137), and [elsa-studio discussion #665](https://github.com/elsa-workflows/elsa-studio/discussions/665).
- Ship user preference and UI state persistence as a Studio platform feature. [elsa-studio#703](https://github.com/elsa-workflows/elsa-studio/issues/703) already scopes theme, layout, table state, local/session storage, reset behavior, and future server profile storage.
- Promote ElsaScript from experiment to useful authoring path: stable syntax, import/export round-tripping, editor diagnostics, examples, and clear boundaries with JSON and visual authoring. See [#7055](https://github.com/elsa-workflows/elsa-core/issues/7055) and the current [`Elsa.Dsl.ElsaScript`](src/modules/Elsa.Dsl.ElsaScript) module.
- Decide the Studio UI framework direction before broad UX work. [elsa-studio#714](https://github.com/elsa-workflows/elsa-studio/issues/714) proposes a MudBlazor-to-Radzen migration, while current work still touches both ecosystems; roadmap work should avoid expensive churn.

Recommended success measures:

- teams with 100+ workflow definitions can find and govern them without naming hacks
- a developer can unit test an activity, integration test a workflow, and debug a failed instance from documented recipes
- common Studio customization no longer requires replacing entire pages or reverse engineering internals
- designer regressions are caught before release across Blazor Server, WASM, and embedded component scenarios

## 3. Integrations And Ecosystem

**Goal:** Elsa should make external systems feel like native workflow building blocks.

High-value items:

- Create an Extension Platform track. Package manifests, shell-feature discovery, Connections/Secrets adoption, generated activity providers, test harness patterns, documentation, and contribution templates should make extensions feel like product-quality packages rather than repo-adjacent samples.
- Create an OpenAPI activity provider that turns an OpenAPI document into typed designer activities. This is a recurring ask in [#2961](https://github.com/elsa-workflows/elsa-core/issues/2961) and [#6360](https://github.com/elsa-workflows/elsa-core/issues/6360), and it is the best foundation for a broad connector story. The existing Extensions OpenAPI work should be reconciled with this product goal.
- Define a connector SDK before adding many one-off integrations. The SDK should cover authentication, secrets, generated activities, testing, metadata, versioning, packaging, Studio property editors, and manifest-driven installation.
- Continue marketplace and plugin infrastructure. The Nuplane modular server, sample package, extension package manifest metadata, and [#7310](https://github.com/elsa-workflows/elsa-core/issues/7310) point to a compelling future where Elsa distributions can install safe custom modules without users maintaining a separate host app.
- Promote Agents to a strategic integration lane: provider matrix, OpenAI and Claude PR resolution, local/OpenRouter/custom endpoints, MCP/tool lifecycle, tool selection in Studio, and auditability. The Extensions source already contains Agents, OpenAI, Azure OpenAI, persistence, API, and Studio modules, while [elsa-extensions#58](https://github.com/elsa-workflows/elsa-extensions/issues/58), [elsa-extensions#98](https://github.com/elsa-workflows/elsa-extensions/pull/98), and [elsa-extensions#63](https://github.com/elsa-workflows/elsa-extensions/pull/63) show the provider matrix and Claude/OpenAI work are still actively moving.
- Prioritize enterprise productivity integrations by leverage: Azure DevOps has a concrete implementation path ([elsa-extensions#124](https://github.com/elsa-workflows/elsa-extensions/issues/124), [elsa-extensions#125](https://github.com/elsa-workflows/elsa-extensions/pull/125)); Teams, OneDrive, SharePoint, Google Docs, and Google Sheets should follow a shared connector model rather than separate bespoke designs.
- Treat dynamic activity generation as a platform primitive. Azure Functions ([elsa-extensions#39](https://github.com/elsa-workflows/elsa-extensions/issues/39)) and registered-method activities ([elsa-extensions#48](https://github.com/elsa-workflows/elsa-extensions/issues/48)) both point toward schema/method-driven activity generation that can also serve OpenAPI, SDK-generated connectors, and internal enterprise APIs.
- Improve data and automation authoring quality: SQL result typing ([elsa-extensions#153](https://github.com/elsa-workflows/elsa-extensions/issues/153), [elsa-extensions#154](https://github.com/elsa-workflows/elsa-extensions/pull/154)), SQL drag/drop reliability ([elsa-extensions#79](https://github.com/elsa-workflows/elsa-extensions/issues/79)), SQL IntelliSense ([elsa-extensions#88](https://github.com/elsa-workflows/elsa-extensions/issues/88)), Dapper package splitting ([elsa-extensions#131](https://github.com/elsa-workflows/elsa-extensions/issues/131), [elsa-extensions#132](https://github.com/elsa-workflows/elsa-extensions/pull/132)), MongoDB secrets parity ([elsa-extensions#126](https://github.com/elsa-workflows/elsa-extensions/issues/126)), WatchFileSystem ([elsa-extensions#90](https://github.com/elsa-workflows/elsa-extensions/issues/90)), and command-line activities ([elsa-extensions#36](https://github.com/elsa-workflows/elsa-extensions/issues/36)).
- Resolve the MassTransit strategy after the v9 licensing change. [discussion #6583](https://github.com/elsa-workflows/elsa-core/discussions/6583) raises a practical ecosystem risk; Elsa should either provide a clean split or reduce dependency weight through a smaller messaging abstraction.
- Clarify Azure Functions and worker-service hosting patterns. [discussion #4707](https://github.com/elsa-workflows/elsa-core/discussions/4707) and [discussion #7420](https://github.com/elsa-workflows/elsa-core/discussions/7420) show demand for non-traditional hosts, Windows services, and serverless-adjacent deployments.
- Add data movement and streaming workflow primitives. [#4809](https://github.com/elsa-workflows/elsa-core/issues/4809) frames this as datasets, linked services, transforms, and stream-oriented processing inspired by Azure Data Factory and stream analytics.
- Productize the BPMN foundation rather than treating BPMN as a distant, unimplemented candidate. Core `3.8.0-rc2` packages execution and interchange, and Studio `main` now has schema-generated types, X6 rendering, import/export, and nested-scope authoring ([elsa-studio#1008](https://github.com/elsa-workflows/elsa-studio/pull/1008)-[#1013](https://github.com/elsa-workflows/elsa-studio/pull/1013)). The next work is compensation/transaction and event-subprocess conformance, configured-host and release validation, full element/property editing, and element-level instance inspection described in [#7909](https://github.com/elsa-workflows/elsa-core/issues/7909). Keep interoperability commitments explicit until the supported BPMN 2.0 subset has public conformance evidence.

Recommended success measures:

- a team can connect to a REST API from its OpenAPI spec without hand-building HTTP activities
- marketplace packages can declare features, dependencies, settings, infrastructure needs, and security posture
- integrations are tested with the same rigor as core modules, not shipped as opaque examples
- extension maturity is visible to users as released, main-only, PR open, proposal, or needs-maintainer

## 4. Observability And Operations

**Goal:** Elsa should be easy to inspect from Studio and from standard production telemetry stacks.

High-value items:

- Finish the diagnostics trilogy: structured logs, console logs, and OpenTelemetry. Structured and console logs now exist; Studio `3.8.0-preview1` ships an OpenTelemetry diagnostics page from [elsa-studio#834](https://github.com/elsa-workflows/elsa-studio/pull/834), and Core `main` now includes the OpenTelemetry backend module in [`src/modules/Elsa.Diagnostics.OpenTelemetry`](src/modules/Elsa.Diagnostics.OpenTelemetry). Core and Studio now release these opt-in modules together in `3.8.0`. The remaining product work is to operationalize the backend, maintain collector setup guidance, and correlate diagnostics with workflow incidents.
- Add default workflow semantic metrics: started, resumed, suspended, faulted, completed, active, activity executed/faulted, queue depth, recovery count, drain count, and dispatch latency. [#5988](https://github.com/elsa-workflows/elsa-core/issues/5988) remains the durable demand signal, while [#7537](https://github.com/elsa-workflows/elsa-core/pull/7537) supplies the first current module boundary.
- Productize the Studio diagnostics pages released in `3.8.0`: live console, structured logs, and OpenTelemetry traces/metrics/logs now have shipped surfaces. Continue validating source health, dropped-event counters, source selection, filters, URL state, and export/copy affordances under operational load; extend workflow incident timelines and direct deep links without treating the entire diagnostics experience as finished.
- Make execution history easier to reason about: distinguish faulted, interrupted, cancelled, crash-recovered, retried, and operator-modified workflows consistently across API, Studio, logs, and metrics.
- Connect diagnostics to workflow navigation: trace/span IDs, log source IDs, child workflow chains, alterations, runtime admin actions, and recovery actions should be correlated instead of presented as isolated tables.

Recommended success measures:

- local developers can troubleshoot from Studio without opening server logs
- production operators can answer "what is stuck, why, and what changed?" from first-party telemetry
- diagnostic modules have safe redaction defaults and bounded memory behavior

## 5. Security, Identity, And Enterprise Readiness

**Goal:** Elsa should be straightforward to secure in real enterprise hosts.

High-value items:

- Productize the external-authentication and SSO foundation for Blazor Server, WASM, separate server/studio, all-in-one hosts, and reverse-proxy sub-path deployments. The `3.8.0-rc2` releases include an Elsa-owned extensible broker and OIDC adapter in Core ([#7889](https://github.com/elsa-workflows/elsa-core/pull/7889)), Settings-based SSO administration and generic login composition in Studio ([elsa-studio#920](https://github.com/elsa-workflows/elsa-studio/pull/920)), and configurable login themes ([elsa-studio#921](https://github.com/elsa-workflows/elsa-studio/pull/921)). Finish solution-level verification, operational recipes, migration/release guidance, and broad provider hardening without conflating upstream identity claims with Elsa authorization.
- Provide a production security guide: API keys, JWT/OIDC, default admin bootstrap, scripting trust levels, C# expression risks, Docker demo boundaries, secret masking, tenant isolation, and permission design.
- Productize the new Core authorization model: use the documented migration from legacy permission strings, extend coverage gates and live-host smoke tests to every endpoint-bearing module, and bring the catalog and introspection experience into Studio ([#7980](https://github.com/elsa-workflows/elsa-core/pull/7980)).
- Complete the Secrets tenancy migration and provider story: make the default-tenant treatment of existing rows explicit in upgrade guidance, provide safe assignment/validation workflows for multi-tenant operators, and design tenant-aware VNext document keys before enabling non-default tenant access ([#7991](https://github.com/elsa-workflows/elsa-core/pull/7991)).
- Extend the Studio user/role administration foundation into workflow governance: tenant/role-based activity visibility, granular permission-aware menus/routes, feature-gated modules, and clear behavior for hidden activities in existing workflow definitions. The administration flows are in `3.8.0-rc2` ([elsa-studio#936](https://github.com/elsa-workflows/elsa-studio/pull/936)), but [elsa-studio#584](https://github.com/elsa-workflows/elsa-studio/issues/584) and [elsa-studio#908](https://github.com/elsa-workflows/elsa-studio/issues/908) show that the authoring-side and permission-honoring product work still remains.
- Complete localization and white-label readiness: translation contribution docs, coverage status, missing key checks, branding hooks, and supportable customization patterns. Studio issues and discussions show setup/coverage friction in [elsa-studio#771](https://github.com/elsa-workflows/elsa-studio/issues/771), [elsa-studio discussion #695](https://github.com/elsa-workflows/elsa-studio/discussions/695), and [elsa-studio discussion #678](https://github.com/elsa-workflows/elsa-studio/discussions/678).
- Improve multi-tenant ergonomics: tenant-agnostic workflows, high tenant counts, tenant validation modes, cache isolation, and clear migration guidance after the 3.6 tenant ID convention changes.
- Create an enterprise deployment checklist for Kubernetes, reverse proxies/base paths, TLS/custom CAs, database migrations, health checks, backups, and disaster recovery.

Recommended success measures:

- a new enterprise adopter can stand up Elsa behind their identity provider from docs alone
- optional dangerous capabilities are explicit opt-ins with plain-language warnings
- tenant and permission regressions are caught by targeted tests before release

## 6. AI-Assisted Workflow Engineering

**Goal:** AI should make workflows more transparent, not less.

High-value items:

- Build AI-assisted workflow generation that produces multiple visible activities from intent rather than hiding logic in one script activity. This direction is proposed in [discussion #7367](https://github.com/elsa-workflows/elsa-core/discussions/7367), and merged [#7523](https://github.com/elsa-workflows/elsa-core/pull/7523) now provides the first Weaver AI Copilot server foundation with AI abstractions, provider/session contracts, chat/tool endpoints, audit events, proposal persistence, EF Core storage, and integration/unit tests.
- Provide an Elsa MCP/tooling surface for reading, validating, editing, and explaining workflow JSON/ElsaScript. This would make Elsa a strong fit for AI-enabled .NET development environments.
- Align AI authoring with the Extensions Agents work: provider abstractions, MCP tools, OpenAI/Claude/local model support, tool approval, secrets handling, and Studio UX should share contracts instead of creating parallel AI stacks.
- Productize the Studio copilot foundation that landed in [elsa-studio#900](https://github.com/elsa-workflows/elsa-studio/pull/900): proposal review/apply flows, validation, generated activity metadata, designer APIs, diagnostics links, and test scaffolding should be available before AI generation becomes prominent. [elsa-studio#553](https://github.com/elsa-workflows/elsa-studio/issues/553) remains the durable demand signal, and the current Studio workspace still depends on Core exposing more proposal/action endpoints.
- Add "explain this workflow", "find risky activities", "suggest tests", and "generate migration notes" capabilities backed by workflow graph metadata.
- Pair AI generation with validation: generated workflows should include test scaffolds, required input/output definitions, secrets handling, and clear review diffs.

Recommended success measures:

- AI-generated workflows remain inspectable in Studio
- generated workflows come with runnable tests or validation plans
- teams can use AI to refactor workflows without losing visibility, auditability, or review discipline

## Recommended Sequencing

Near term:

1. Finish runtime confidence work: graceful shutdown remaining tasks, recovery clarity, atomic admission for configured activation strategies, distributed runtime regressions, security documentation, and OIDC recipes.
2. Stabilize Studio authoring: designer regression harness, input/property-editor fixes, async dispatch/run UX, state machine Studio/docs completion, and a clear UI framework direction.
3. Operationalize the diagnostics modules released in Core and Studio `3.8.0`: maintain collector setup guidance, validate the paired experience under operational load, and correlate traces/logs/metrics with workflow incidents.
4. Make workflow authoring easier to manage at scale: organization, search, progress/timeline APIs, testing docs, output-converter release/extension completion, and user preference/table-state persistence.
5. Reconcile shipped extension foundations with roadmap status: package manifests, Connections/Secrets, OpenAPI, Agents, schedulers, messaging, and integration maturity labels.
6. Productize the BPMN runtime/interchange foundation: complete validation and conformance work, define the supported subset, release the main-only Studio rendering/import/export/nested-authoring slice, and then add full editing and instance inspection.

Mid term:

1. Promote [#7469](https://github.com/elsa-workflows/elsa-core/issues/7469) from deployment-platform PRD into an implementation spec covering manifests, immutable artifacts, dry-run validation, deployment history, and API/CLI surfaces.
2. OpenAPI activity provider plus connector SDK.
3. Extension Platform: generated activities, contribution harnesses, Studio extension recipes, package manifest maturity, and marketplace/plugin installation path built on Nuplane and shell features.
4. Workflow debugging, replay-oriented incident analysis, child workflow navigation, and operator recovery UX.
5. Weaver AI Copilot productization and Agents provider matrix/MCP lifecycle, with Studio UX that keeps generated workflows inspectable.

Longer term:

1. Native workflow-aware background execution and actor-runtime abstraction.
2. Data pipeline/stream processing primitives.
3. AI-assisted authoring and workflow MCP tools.

## Maintainership Recommendations

- Keep this roadmap in source control and mirror major changes to [#3232](https://github.com/elsa-workflows/elsa-core/issues/3232). Users are explicitly asking for roadmap visibility in [discussion #7202](https://github.com/elsa-workflows/elsa-core/discussions/7202) and the latest roadmap issue comment.
- Use labels, milestones, or GitHub Projects to connect Core, Studio, and Extensions issues to these roadmap themes. Many high-value issues are currently unlabeled, which makes demand hard to see.
- Close or update stale roadmap items that are already implemented, especially state machine, activity testing, ElsaScript, diagnostics, and graceful shutdown foundations.
- Prefer platform primitives over one-off features: connector SDK before many connectors, Extension Platform before bespoke package work, plugin system before bespoke managed extensibility, runtime abstraction before framework-specific actor work.
- Do not hide reliability work under "maintenance". Recovery, distributed correctness, migrations, security posture, and observability are core product features for a workflow engine.
- Enable GitHub Discussions for `elsa-extensions` or explicitly route roadmap discussion into labeled issues/projects. Right now extension demand is visible, but fragmented across issue comments and open pull requests.