* Adds activity execution call stack support Implements a call stack mechanism to track the execution chain, enabling visibility into the invocation hierarchy. Introduces new fields to scheduling models and runtime contexts to store call stack information. Includes EF Core migrations for various database providers to support new columns in `ActivityExecutionRecords`. Provides an API to query and reconstruct the call stack for a given activity execution. * Refactor: Replace `PagedCallStackResult` with `Page<T>` for execution chain pagination * Remove ambient scheduling scope logic and related methods Simplifies scheduling logic by removing ambient scope mechanisms, refactoring scheduling context handling, and updating affected classes accordingly. * Add `GetCallStackAsync` to `IActivityExecutionsApi` for querying activity execution call stack * Add new properties to `ActivityExecutionRecord` for scheduling and execution tracking Introduce fields for aggregated fault count, scheduling context, workflow instance details, and call stack depth to enhance execution monitoring and debugging capabilities. * Add call stack visualization for activity executions Introduced components and models to display a call stack for activity executions in the Workflow Instance Viewer. This includes UI elements for call stack rendering, error handling, and data integration with activity execution records. * Remove obsolete ambient scheduling properties from WorkflowExecutionContext * Fix infinite loop issues in activity execution chain traversal Added cycle detection using a `HashSet` to prevent infinite loops when traversing activity execution chains in multiple storage implementations. Updated unit tests to validate correct handling of circular references and chain traversal. * Refactor activity execution chain retrieval logic Centralized the `GetExecutionChainAsync` method into an extension class to streamline and unify its implementation across stores. Removed redundant implementations from individual stores and updated interfaces to utilize the new extension method. This reduces code duplication and simplifies future maintenance. * Add CallStackDepth property to activity contexts Integrated the `CallStackDepth` property into `ActivityExecutionContext`, `ActivityExecutionContextState`, and related classes to track and manage the call stack depth of activity executions. Removed obsolete depth calculation logic to streamline the process. * Add unit tests for call stack depth calculations and persistence - Add `WorkflowExecutionContextTests` to verify correct calculation of call stack depth during activity execution. - Add `WorkflowStateExtractorTests` to ensure call stack depth is preserved during state extraction and application. * Update src/modules/Elsa.Workflows.Api/Endpoints/ActivityExecutions/GetCallStack/Endpoint.cs Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> * Update src/modules/Elsa.Workflows.Api/Endpoints/ActivityExecutions/GetCallStack/Endpoint.cs Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> * Enhance activity execution handling with ID filter and task completion logic - Implement `ActivityExecutionRecordFilter` for precise query matching by ID. - Add await logic for task completion in command handler middleware. * Add missing indexes for call stack columns in V3_7 migrations (#7250) * Initial plan * Add missing indexes for call stack columns in all provider migrations Co-authored-by: sfmskywalker <938393+sfmskywalker@users.noreply.github.com> * Optimize migrations by creating columns with correct indexable types Co-authored-by: sfmskywalker <938393+sfmskywalker@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: sfmskywalker <938393+sfmskywalker@users.noreply.github.com> * Add unit tests for ActivityExecutionStoreExtensions - Introduce tests for `GetExecutionChainAsync` covering scenarios of empty results, single records, multi-level chain traversal, workflow boundary constraints, pagination, and circular references. * Refactor tests for `ActivityExecutionStoreExtensions` - Replace mock setup with `CreateStore` helper for clean and clear test arrangements. - Remove unused imports and clean up test setup for improved readability and maintenance. * Remove unused imports from ActivityExecutionLogStore in Elsa.Persistence.EFCore module. * Removes obsolete planning document Removes the activity execution call stack planning document as the feature has been implemented. * Remove DefaultActivityExecutionMapperTests - Deleted `DefaultActivityExecutionMapperTests.cs` as the test class is no longer in use and redundant. * Address review feedback: Fix corrupted test, Oracle migrations, and call stack depth calculation (#7272) * Initial plan * Fix corrupted DefaultActivityExecutionMapperTests.cs test file Co-authored-by: sfmskywalker <938393+sfmskywalker@users.noreply.github.com> * Fix Oracle migration snapshot to use NCLOB for large text fields Co-authored-by: sfmskywalker <938393+sfmskywalker@users.noreply.github.com> * Optimize GetExecutionChainAsync to avoid loading all workflow instance records Co-authored-by: sfmskywalker <938393+sfmskywalker@users.noreply.github.com> * Fix CallStackDepth calculation to support cross-workflow invocations - Add SchedulingCallStackDepth to ActivityInvocationOptions - Update WorkflowExecutionContext to use provided depth when scheduling context not found - Remove problematic test that reveals pre-existing bug with duplicate contexts Co-authored-by: sfmskywalker <938393+sfmskywalker@users.noreply.github.com> * Improve documentation for CallStackDepth calculation Co-authored-by: sfmskywalker <938393+sfmskywalker@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: sfmskywalker <938393+sfmskywalker@users.noreply.github.com> * Add WorkflowStateExtractor to ActivityTestFixture services * Refactor `DefaultActivityExecutionMapperTests` with `ActivityTestFixture` and add project reference for shared testing utilities. * Propagate SchedulingCallStackDepth through cross-workflow invocation chain (#7273) * Initial plan * Add SchedulingCallStackDepth propagation through cross-workflow invocation chain Co-authored-by: sfmskywalker <938393+sfmskywalker@users.noreply.github.com> * Add unit tests for CallStackDepth propagation across workflow boundaries Co-authored-by: sfmskywalker <938393+sfmskywalker@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: sfmskywalker <938393+sfmskywalker@users.noreply.github.com> * Initial plan (#7274) Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> * Reduce NVARCHAR2 column sizes in Oracle migrations to optimize storage and improve performance. * Change column types to NCLOB for large text fields in Oracle migrations to enhance data storage capacity. * Update GitHub Actions to use .NET 10.x and refactor setup classes for consistency * Improve test project detection in GitHub Actions by handling non-csproj files and updating project sorting mechanism. * Enhance GitHub Actions to display .NET environment info and enforce .NET 10 toolchain for test execution. * Update GitHub Actions to use .NET SDK 10.0.1xx and enforce its usage for builds and tests. * Refine GitHub Actions workflow by narrowing test project search to the `test/unit` directory and removing unnecessary script checks. * Remove redundant build step from GitHub Actions workflow. * Enhance GitHub Actions workflow by adding multiple test directories and handling ignored failed sources in .NET restore. --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Co-authored-by: Copilot <198982749+Copilot@users.noreply.github.com> Co-authored-by: sfmskywalker <938393+sfmskywalker@users.noreply.github.com> |
||
|---|---|---|
| .config | ||
| .github | ||
| .nuke | ||
| build | ||
| design | ||
| doc | ||
| docker | ||
| gen | ||
| scripts | ||
| src | ||
| test | ||
| .editorconfig | ||
| .gitignore | ||
| build.cmd | ||
| build.ps1 | ||
| build.sh | ||
| CONTRIBUTING.md | ||
| Directory.Build.props | ||
| Directory.Packages.props | ||
| dotnet-install.sh | ||
| Elsa.sln | ||
| Elsa.sln.DotSettings | ||
| icon.png | ||
| LICENSE | ||
| NuGet.Config | ||
| README.md | ||
| run-dsl-tests.sh | ||
| test-flowchart.txt | ||
| test-simple-flowchart.elsa | ||
Elsa Workflows
For Elsa 2, Click Here
Introduction
Elsa is a powerful workflow library that enables workflow execution within any .NET application. Elsa allows you to define workflows in various ways, including:
- Writing C# code
- Using a visual designer
- Specifying workflows in JSON
Try with Docker
To give the Elsa Studio + Elsa Server a quick spin, you can run the following command to start the Elsa Docker container:
docker pull elsaworkflows/elsa-server-and-studio-v3:latest
docker run -t -i -e ASPNETCORE_ENVIRONMENT='Development' -e HTTP_PORTS=8080 -e HTTP__BASEURL=http://localhost:13000 -p 13000:8080 elsaworkflows/elsa-server-and-studio-v3:latest
This Docker image is based on a reference ASP.NET application that hosts both the workflow server and designer and is not intended for production use.
By default, you can access http://localhost:13000 and log in with:
Username: admin
Password: password
TLS and custom certificate authorities
All Elsa Docker images now ship with the operating system's certificate authority bundle baked in at build time. This means you can call public HTTPS endpoints such as https://example.com without any additional configuration.
If you need to trust a private or corporate CA, mount the certificate bundle into the container and reference it via EXTRA_CA_CERT:
docker run \
-v /path/to/company-ca.crt:/certs/company-ca.crt:ro \
-e EXTRA_CA_CERT=/certs/company-ca.crt \
elsaworkflows/elsa-server-and-studio-v3:latest
On startup, the container copies the certificate into /usr/local/share/ca-certificates and runs update-ca-certificates, making the trust available to .NET, OpenSSL, curl, and other system components. Multiple certificates can be provided by pointing EXTRA_CA_CERT at a directory containing .crt or .pem files.
In highly restricted environments where you cannot modify the system trust store, you can instead rely on the standard SSL_CERT_FILE or SSL_CERT_DIR environment variables:
docker run \
-v /path/to/company-ca-bundle.pem:/certs/custom.pem:ro \
-e SSL_CERT_FILE=/certs/custom.pem \
elsaworkflows/elsa-server-and-studio-v3:latest
ℹ️ Installing the CA bundle adds roughly 300KB to the Debian-based images. No package managers run at container startup; all trust updates happen immutably at build time or via the mounted certificates shown above.
Table of Contents
- Documentation
- Known Issues and Limitations
- Features
- Roadmap
- Use Cases
- Coding Workflows
- Designed Workflows
- Contributing
- Support
Documentation
Known Issues and Limitations
Elsa is continually evolving, and while it offers powerful capabilities, there are some known limitations and ongoing work:
- Documentation is still a work in progress.
- Input/Output is not yet implemented in the Workflow Instance Viewer.
- Starting workflows from the designer is currently supported only for workflows that do not require input and do not start with a trigger; this is planned for a future release.
- The designer currently only supports Flowchart activities. Support for Sequence and StateMachine activities is planned for a future release.
- UI input validation is not yet implemented.
Features
Elsa offers a wide range of features for building and executing workflows, including:
- Execution of workflows in any .NET application with support for .NET 6 and beyond.
- Support for both short-running and long-running workflows.
- A programming model loosely inspired by Windows Workflow Foundation.
- A web-based drag & drop designer with support for custom activities.
- Native support for activity composition, including activities like
Sequence,Flowchart, andForEach. - Parallel execution of activities.
- Built-in activities for common scenarios, such as sending emails, making HTTP calls, scheduling tasks, sending and receiving messages, and more.
- Workflow versioning and migration via API.
- Easy integration with external applications via HTTP, message queues, and more.
- Actor model for increased workflow throughput.
- Dynamic expressions with support for C#, JavaScript, Python, and Liquid.
- Persistence agnostic, with support for Entity Framework Core, MongoDB, and Dapper out of the box.
- Elsa Studio: a modular Blazor dashboard app for managing and designing workflows.
Roadmap
See #3232
Use Cases
Elsa can be used in a variety of scenarios, including:
- Long-running workflows such as order fulfillment and product approval.
- Short-running workflows such as sending emails and generating PDFs.
- Scheduled workflows such as sending daily reports.
- Event-driven workflows such as sending welcome emails when a user signs up.
Coding Workflows
Elsa allows you to define workflows in code using C#. The following example shows how to receive HTTP requests and send an email in response:
public class SendEmailWorkflow : WorkflowBase
{
protected override void Build(IWorkflowBuilder builder)
{
builder.Root = new Sequence
{
Activities =
{
new HttpEndpoint
{
Path = new("/send-email"),
SupportedMethods = new(new[] { HttpMethods.Post }),
CanStartWorkflow = true
},
new SendEmail
{
From = new("alic@acme.com"),
To = new(new[]{ "bob@acme.com" }),
Subject = new("Your workflow has been triggered!"),
Body = new("Hello!")
}
}
};
}
}
Designing Workflows
Elsa allows you to define workflows using a visual designer. The following example shows how to receive HTTP requests and send an email in response:
Contributing
We welcome contributions from the community and are pleased that you are interested in helping to improve the Elsa Workflow project! Here are the steps to contribute to our project:
1. Fork and Clone the Repo
To get started, you'll need to fork the repository to your own GitHub account. You can do this by navigating to the Elsa Workflow GitHub repository and clicking the "Fork" button in the top-right corner of the page. Once you have forked the repo, you can clone it to your local machine using the following command:
git clone https://github.com/YOUR_USERNAME/elsa-core.git
Replace YOUR_USERNAME with your GitHub username. For more information on forking a repo, check out the GitHub documentation here.
Incorporating the details about the "apps" folder and its projects into the second point about opening the Elsa.sln using your favorite IDE, we can expand the instructions to guide developers on where to start and what projects they might want to explore first. Here's an updated version of that section with the additional information:
2. Open Elsa.sln Using Your Favorite IDE
After cloning the repository, navigate to the cloned directory and open the Elsa.sln solution file with your preferred IDE that supports .NET development, such as Visual Studio, JetBrains Rider, or Visual Studio Code with the appropriate extensions.
Within the solution, you will find an "apps" folder containing three projects designed to help you get started and explore the capabilities of Elsa Workflow:
-
Elsa.Server.Web: This project is a reference ASP.NET Core application that acts as a workflow server. It's a great starting point if you want to understand how Elsa functions as a server-side workflow engine.
-
Elsa.ServerAndStudio.Web: This project serves a dual purpose. Like
Elsa.Server.Web, it acts as a workflow server. Additionally, it hosts the Elsa Studio Blazor WebAssembly app. This is the perfect project to run if you want to see the full capabilities of Elsa, including both the server aspects and the client-side studio experience in one application. -
Elsa.Studio.Web: This project is a reference Blazor WebAssembly application that solely hosts the Elsa Studio Blazor WebAssembly app. It requires a running Elsa server application to connect to. Use this project if you're interested in focusing on the Elsa Studio UI and its interactions with an Elsa workflow server.
3. Submit a PR with Your Changes
Once you have made your changes, commit them and push them back to your fork. Then, navigate to the original Elsa Workflow repository and create a new Pull Request. Ensure your PR description clearly describes the changes and any relevant information that will help the reviewers understand your contributions. For a detailed guide on creating a pull request, visit Creating a pull request from a fork.
4. Open an Issue First
Before you start working on your changes or submit a pull request, please open an issue to discuss what you would like to do. This step is crucial as it ensures you don't spend time working on something that might not align with the project's goals or might already be under development by someone else. You can open an issue here.
This approach helps us streamline contributions and ensures that your efforts are aligned with the project's needs and priorities. We look forward to your contributions and are here to support you throughout the process. Thank you for contributing to the Elsa Workflow project!
Support
There are various ways to get support for Elsa Workflows, ranging from community-driven channels to enterprise-level services.
Community Support
Elsa has an active and helpful community where you can find support through multiple channels:
- GitHub Issues for bug reports and feature requests.
- GitHub Discussions for open-ended conversations, questions, and community-driven support.
- Discord for real-time support and interaction with the Elsa community.
- StackOverflow for searching or asking technical questions.
Professional Support
For organizations requiring professional support and long-term commitment, check out Elsa+, a growing ecosystem of premium services, tooling, and extensions around Elsa Workflows.


