diff --git a/ROADMAP.md b/ROADMAP.md index 964d1733e..e34c12f26 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -1,6 +1,6 @@ # Elsa Roadmap -Last refreshed: 2026-09-09 (post-3.8 Studio BPMN and runtime-admission status) +Last refreshed: 2026-09-16 (post-3.8.2 operational patches and BPMN authoring 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. @@ -86,14 +86,14 @@ Legend: `[x]` shipped foundation, `[~]` partially shipped or needs productizatio - [ ] 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 +- [~] Azure DevOps connector implementation is under review; Teams, OneDrive, SharePoint, Google Docs, and Google Sheets still need a shared integration strategy ([elsa-extensions#199](https://github.com/elsa-workflows/elsa-extensions/pull/199)) - [ ] 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)) +- [~] BPMN execution and interchange foundations, with main-only Studio schema types, rendering, import/export, nested-scope authoring, guarded document save, and task-to-Elsa-activity binding; broader visual 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), [#1031](https://github.com/elsa-workflows/elsa-studio/pull/1031), [#1033](https://github.com/elsa-workflows/elsa-studio/pull/1033)) ## Current Foundations @@ -102,6 +102,7 @@ These are already present in the codebase and should be treated as foundations f - 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. +- The `3.8.1` patch train shipped on September 12 across [Core](https://github.com/elsa-workflows/elsa-core/releases/tag/3.8.1), [Studio](https://github.com/elsa-workflows/elsa-studio/releases/tag/3.8.1), and [Extensions](https://github.com/elsa-workflows/elsa-extensions/releases/tag/3.8.1). It restores Studio-selectable activation strategies, corrects terminal-instance interrupted recovery, fixes Studio OIDC/static-feature dashboard/execution-detail regressions, and supplies the MongoDB/Dapper interruption-store companions. The aligned `3.8.2` train on September 15 is a critical package correction for MongoDB/Dapper hosts: upgrade all three repositories together when using those persistence packages ([Core](https://github.com/elsa-workflows/elsa-core/releases/tag/3.8.2), [Studio](https://github.com/elsa-workflows/elsa-studio/releases/tag/3.8.2), [Extensions](https://github.com/elsa-workflows/elsa-extensions/releases/tag/3.8.2)). These fixes improve the shipped operational foundation; recovery, atomic admission, and cross-provider confidence remain roadmap work. - 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). @@ -115,7 +116,7 @@ These are already present in the codebase and should be treated as foundations f - 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 `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, import/export, nested-process-scope authoring, element-keyed execution diagnostics, and guarded document editing: Core's whole-document GET/PUT uses an ETag, and Studio can bind authored BPMN tasks to Elsa activities through its Performed by editor ([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), [elsa-core#8060](https://github.com/elsa-workflows/elsa-core/pull/8060), [elsa-studio#1024](https://github.com/elsa-workflows/elsa-studio/pull/1024), [#1031](https://github.com/elsa-workflows/elsa-studio/pull/1031), [#1033](https://github.com/elsa-workflows/elsa-studio/pull/1033)). This Studio slice landed after `3.8.0` and is not a release claim. Publish-time validation, compensation/transaction and event-subprocess conformance, broader visual 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. @@ -193,13 +194,13 @@ High-value items: - 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. +- Prioritize enterprise productivity integrations by leverage: Azure DevOps has moved from a proposal to an active module implementation ([elsa-extensions#124](https://github.com/elsa-workflows/elsa-extensions/issues/124), [elsa-extensions#199](https://github.com/elsa-workflows/elsa-extensions/pull/199)); treat it as a connector-SDK proving ground rather than a precedent for bespoke integrations. Teams, OneDrive, SharePoint, Google Docs, and Google Sheets should follow a shared connector model rather than separate 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. +- Productize the BPMN foundation rather than treating BPMN as a distant, unimplemented candidate. Core `3.8.0-rc2` packages execution and interchange, while Studio `main` now has schema-generated types, X6 rendering, import/export, nested-scope authoring, element-keyed diagnostics, and guarded document editing with task-to-Elsa-activity binding ([elsa-studio#1008](https://github.com/elsa-workflows/elsa-studio/pull/1008)-[#1013](https://github.com/elsa-workflows/elsa-studio/pull/1013), [elsa-core#8060](https://github.com/elsa-workflows/elsa-core/pull/8060), [elsa-studio#1024](https://github.com/elsa-workflows/elsa-studio/pull/1024), [#1031](https://github.com/elsa-workflows/elsa-studio/pull/1031)). The next work is compensation/transaction and event-subprocess conformance, configured-host and release validation, broader visual 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: @@ -275,7 +276,7 @@ Near term: 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. +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 and guarded binding slice, then broaden visual editing and add instance inspection. Mid term: