DEV Community: ABP.IO

ABP.IO Platform 10.6 Final Has Been Released!

ABP.IO — Mon, 27 Jul 2026 11:30:06 +0000

ABP.IO Platform 10.6 Final Has Been Released!

We are glad to announce that ABP 10.6 stable version has been released.

What's New With Version 10.6?

All the new features were explained in detail in the 10.6 RC Announcement Post, so there is no need to review them all again. You can check it out for more details.

Here are some of the highlights of this version:

Background jobs now support dedicated workers, parallel execution, and successful job retention.
API definition and generated proxies have better support for response content types, remote streams, and multipart uploads.
Angular UI packages and templates have been upgraded to Angular 22.
Antiforgery and OpenIddict flows include important security and reliability improvements.
ABP Commercial adds OpenIddict access-token generation from the UI and React CRUD page generation support in ABP Suite.
AI Management indexing is more resilient for large or memory-constrained workloads.
The final release also includes dependency updates and stability fixes collected during the RC period.

Getting Started with 10.6

How to Upgrade an Existing Solution

You can upgrade your existing solutions with either ABP Studio or ABP CLI. In the following sections, both approaches are explained:

Upgrading via ABP Studio

If you are already using the ABP Studio, you can upgrade it to the latest version. ABP Studio periodically checks for updates in the background, and when a new version of ABP Studio is available, you will be notified through a modal. Then, you can update it by confirming the opened modal. See the documentation for more info.

After upgrading the ABP Studio, then you can open your solution in the application, and simply click the Upgrade ABP Packages action button to instantly upgrade your solution:

Upgrading via ABP CLI

Alternatively, you can upgrade your existing solution via ABP CLI. First, you need to install the ABP CLI or upgrade it to the latest version.

If you haven't installed it yet, you can run the following command:

dotnet tool install -g Volo.Abp.Studio.Cli

Or to update the existing CLI, you can run the following command:

dotnet tool update -g Volo.Abp.Studio.Cli

After installing/updating the ABP CLI, you can use the update command to update all the ABP related NuGet and NPM packages in your solution as follows:

abp update

You can run this command in the root folder of your solution to update all ABP related packages.

Migration Guides

This version includes explicitly marked migration-impacting changes for specific customization scenarios, especially custom background job stores/workers and custom AI Management document chunk repositories. The new background job runtime features are opt-in and existing applications keep the current behavior unless they enable them explicitly.

Please read the migration guide carefully, if you are upgrading from v10.5 or earlier versions: ABP Version 10.6 Migration Guide

If you use the Angular UI, also check the dedicated Angular 22 and ABP 10.6 Upgrade Guide.

Community News

New ABP Community Articles

As always, exciting articles have been contributed by the ABP community. I will highlight some of them here:

Thanks to the ABP Community for all the content they have published. You can also post your ABP related (text or video) content to the ABP Community.

About the Next Version

The next feature version will be 10.7. You can follow the release planning here. Please submit an issue if you have any problems with this version.

Event Recap - WeAreDevelopers World Congress 2026

ABP.IO — Fri, 17 Jul 2026 12:26:38 +0000

WeAreDevelopers World Congress 2026 has come to an end, and we'd like to thank everyone who stopped by the ABP booth in Berlin!

We had the opportunity to meet developers, architects, engineering leaders, and technology enthusiasts from around the world. It was a pleasure connecting with so many members of the developer community, hearing about the projects you're building, and discussing the challenges and opportunities shaping modern software development.

Great Conversations and Product Demos

Throughout the event, our team showcased the latest developments across the ABP ecosystem, including ABP Framework, ABP Studio, and our AI-powered development capabilities.

We had countless conversations about modular application development, clean architecture, microservices, AI-assisted development, and how teams can build enterprise applications faster while maintaining long-term quality and maintainability.

Thank you to everyone who shared feedback, asked questions, and explored how ABP can support your development journey.

Sharing Our Experience on Stage

In addition to connecting with attendees at our booth, we were proud to see our Co-founder, Halil İbrahim Kalkan , speak at WeAreDevelopers World Congress 2026.

His session, "Dynamic Entities in .NET: Building Low-Code Systems on Top of Entity Framework Core" explored how developers can build flexible, dynamic applications while leveraging the power of Entity Framework Core and the .NET ecosystem.

It was a great opportunity to share the engineering practices and ideas behind ABP with the wider developer community. Thank you to everyone who attended the session and joined the discussion.

More Than Just a Conference

WeAreDevelopers World Congress wasn't only about technical sessions. The event also featured interactive experiences, including a lively arcade gaming area, creating plenty of opportunities for attendees to relax, connect, and enjoy the conference between talks.

This is the approach I'd recommend. It keeps the ABP story focused while giving you a natural place to include photos or videos of the arcade area.

Meeting The Developer Community

One of the best parts of WeAreDevelopers World Congress is bringing together developers, architects, engineering leaders, and technology experts from around the world. The conference featured inspiring keynotes and technical sessions covering AI, software architecture, cloud, developer productivity, and many other topics that are shaping the future of software development.

Until Next Time

A big thank you to the WeAreDevelopers team for organizing another fantastic event and to everyone who visited us at Hall A, Booth A-41.

If we didn't get the chance to meet in Berlin, you can always explore ABP online, join our community, or reach out to us with your questions and feedback.

We appreciate everyone who made WeAreDevelopers World Congress 2026 such a memorable experience, and we look forward to seeing you again at future events!

Building a Vendor Onboarding Workflow with ABP Low-Code

ABP.IO — Mon, 13 Jul 2026 12:51:56 +0000

Building a Vendor Onboarding Workflow with ABP Low-Code

Vendor onboarding usually starts with a few familiar steps.

A company sends its details, someone checks the documents, another person reviews the score, and the team either approves the vendor or asks for more information. After a while, the process turns into a mix of spreadsheets, uploaded files, status notes, and "who is waiting on this one?" messages.

In this article, we'll build that workflow with the Low-Code System. We'll model the data in the Low-Code Designer, let the React runtime render the page, and then add one custom endpoint for a summary that does not belong to normal CRUD.

The example is an internal operations page where a team receives vendor applications, reviews compliance documents, tracks deadlines, and follows rejected or priority vendors from one place.

That is a good place to try ABP Low-Code, because the first version of the workflow is mostly data, screens, validation rules, and a few process-specific actions. You do not need to hand-write a React page only to list vendor applications, upload a compliance document, or show a rejection reason when the status is rejected.

We will start from an already running ABP React + EF Core application with Low-Code enabled, so the article can stay focused on the Admin Console, the Designer, and the runtime flow.

What We Are Building

The workflow has one main record: VendorApplication.

A reviewer should be able to:

Create a vendor application with company and contact details.
Track whether the vendor is Submitted, InReview, Approved, or Rejected.
Set the requested date and approval deadline.
Mark priority vendors.
Assign a category such as Software, Services, or Hardware.
Upload a logo and a compliance document.
Fill in a rejection reason only when the application is rejected.
Filter the generated grid by status, requested date, priority, and category.
Call a summary endpoint that returns counts for dashboard-like use.

We'll also touch two extra pieces around that main record. VendorReviewTemplate comes from C# so you can see how code-defined metadata appears in the Designer. Later, a VendorEscalation model is added while the Designer is switched to Runtime JSON. You could build the whole workflow with one entry point, but using these three entry points makes the hybrid model visible without turning the article into three separate implementations.

A Quick Note on How Low-Code Fits Together

The Low-Code Designer is where you describe the model and the UI metadata. In this article we use four areas:

Data for enums and entities.
Pages for the generated grid route.
Forms for the create/edit form layout.
Actions for the custom HTTP endpoint.

The Designer stores metadata. The React runtime reads that metadata and renders the page at runtime. That is the important mental model: when we add a field to the entity, the field can become a grid column, a filter, a validation rule, or a form input depending on how we configure the metadata around it.

There is also one database detail to keep in mind. Metadata that comes from C# code or from Dev JSON is source-controlled application metadata. When it introduces or changes a persisted entity, run the normal EF Core migration and database update flow before using the generated runtime page. In the validated demo for this article I used SQLite, so the migration updated the local SQLite database. Runtime JSON is different: it is authored at runtime, so I do not run a C# migration in that section.

Add a Code-Defined Review Template

Let's start with one model that does not come from the Designer.

In this workflow, vendor reviewers can use review templates. The template itself is not the center of the workflow, so I kept it focused on the review rules:

[DynamicEnum]
public enum VendorReviewTemplateType
{
    Standard = 0,
    Security = 1,
    Finance = 2
}

[DynamicEntity(DefaultDisplayPropertyName = nameof(Name))]
[DynamicEntityUI(DisplayName = "Vendor Review Templates")]
public class VendorReviewTemplate : DynamicEntityBase
{
    [Required]
    [StringLength(128)]
    [DynamicPropertyUnique]
    public string Name { get; set; }

    public VendorReviewTemplateType TemplateType { get; set; }
    public int MinimumComplianceScore { get; set; }
    public bool RequiresDocumentReview { get; set; }
    public string? Notes { get; set; }
}

Then include the entity in your EF Core DbContext. This is the part that makes the migration create a real backing table for the code-defined model:

public DbSet<VendorReviewTemplate> VendorReviewTemplates { get; set; }

builder.Entity<VendorReviewTemplate>(b =>
{
    b.ToTable(
        VendorOnboardingLowCodeConsts.DbTablePrefix + "VendorReviewTemplates",
        VendorOnboardingLowCodeConsts.DbSchema
    );
    b.ConfigureByConvention();
    b.Property(x => x.Name).IsRequired().HasMaxLength(128);
    b.Property(x => x.Notes).HasMaxLength(512);
    b.HasIndex(x => x.Name).IsUnique();
});

Because this model is defined in C#, treat it like the rest of your application schema changes: add the entity, add the DbSet/mapping, create/apply the EF Core migration, and then start the application.

After the app starts, open Admin Console > Low-Code Designer > Data. The model is visible there, but it is read-only because it was defined in code.

Open the Properties tab and you can see the fields that came from the C# class. They are available to the Low-Code System, but the Designer marks them as code-owned.

That is useful in real projects. Some metadata can be shipped with the application, while the rest of the workflow can still be designed through the Admin Console.

Create the Vendor Enums

Now move to the part we actually build in the Designer.

The animation below shows the Designer path in one pass. The next sections slow it down and explain the enum, entity, page, and form steps.

Open Data > Enums and create the status enum:

VendorApplicationStatus
Submitted
InReview
Approved
Rejected

Before saving, the enum modal should contain the name and the four values:

Then create the category enum:

VendorCategory
Software
Services
Hardware

The order of the status values matters for the custom endpoint later, because the script checks the enum values by their numeric indexes. In this example Submitted is 0, Approved is 2, and Rejected is 3.

After saving, the enum detail page shows the numeric values that the runtime and scripts will use:

Create the VendorApplication Entity

Go to Data > Entities and create VendorApplication.

This is the model that drives the rest of the article. Add these fields:

| Field | Type | Configuration | | --- | --- | --- | | CompanyName | String | Required and unique | | ContactEmail | String | Required, email validation | | Status | Enum | VendorApplicationStatus | | RequestedOn | Date | Application date | | ApprovalDeadline | Date | Review deadline | | IsPriority | Boolean | Priority flag | | Category | Enum | VendorCategory | | ComplianceScore | Int | Review score | | Logo | Image | Logo upload | | ComplianceDocument | File | Document upload | | RejectionReason | String | Optional |

The Properties tab is where the entity becomes more than a name. The table shows the field types, enum bindings, and source layer. Scroll down and the upload-related fields are visible with their Image and File types:

There is no React code yet, but we already have a lot of behavior described: required fields, uniqueness, email validation, enum fields, upload fields, and the data shape that the runtime will use.

The Image and File types are worth calling out. They are not plain strings with a path. In the generated form they become upload controls, which is exactly what we need for vendor logos and compliance documents.

Since VendorApplication is authored in the Dev JSON layer, it also belongs to the source-controlled model. After saving the entity metadata, create/apply the EF Core migration before you open the generated page in the runtime. This is the step that creates the backing table for the low-code entity in the database.

Generate a Grid Page

The reviewers need a page where they can work with applications, so go to Pages and create a dataGrid page named vendor-onboarding.

Bind it to VendorApplication.

Before saving the page, the modal connects the route name, title, icon, and entity:

After the page is created, set RequestedOn as the default sort field, keep it descending, adjust the icon if you want, and assign vendor-application-form as the create/edit form:

For the review workflow, keep the configured columns focused on the fields reviewers use most:

Company name
Status
Requested date
Priority
Category

Then configure the filters you want reviewers to use most often. In this workflow, the important filters are company, status, requested date, priority, and category. Depending on the runtime defaults, the generated grid may still expose additional fields such as contact email; the workflow is still driven by the focused page metadata above.

Once the page is saved, the React runtime can resolve the route from the page metadata. The grid is generated from the entity and page configuration rather than from a hand-written React component.

Build the Create/Edit Form

A grid is not enough. We also need a form that feels like the workflow.

Go to Forms and create vendor-application-form for VendorApplication. Split the fields into three tabs:

Company : CompanyName, ContactEmail, Category, IsPriority
Review : Status, RequestedOn, ApprovalDeadline, ComplianceScore, RejectionReason
Documents : Logo, ComplianceDocument

Now add the conditional behavior for RejectionReason. In this demo I used two complementary rules: one rule shows the field when Status = Rejected, and the other hides it for non-rejected statuses.

This is one of the places where Low-Code becomes more than "generate a CRUD page". The runtime does more than render a static form; it evaluates the rule while the user edits the record.

Apply the Migration Before Opening the Runtime

Before opening the generated page, apply the database migration for the Dev JSON changes. We used Dev JSON for VendorApplication, so the Designer wrote source-controlled descriptor files under _Dynamic. The entity shape is now part of the application model, and the database needs the matching backing table before the React runtime can save records.

That is why Dev JSON is a good fit during development: the metadata files and the EF Core migration can be reviewed, committed, and reproduced in another environment. If the same entity had been created in the Runtime JSON layer, you would not create a C# migration for that runtime edit; the metadata change would be stored in the database instead. In practice, use Dev JSON for development-time, source-controlled changes, and use Runtime JSON when you want production-time changes to be managed from the Admin Console and persisted in the database.

Try It in the React Runtime

Open the generated vendor-onboarding page in the React runtime and create a vendor application.

On the Documents tab, the Logo and ComplianceDocument fields are rendered as upload fields:

Now edit a record and change the status to Rejected. The RejectionReason field becomes available on the Review tab:

After saving a few records, use the generated filters to narrow the list to rejected vendors. Depending on the runtime configuration, the filter panel can expose more fields than the small set you configured for the workflow; here we only use the Status = Rejected filter:

The short animation below gives a quick pass through the same runtime states: upload fields, the conditional rejection reason, and the filtered grid.

At this point we have a working page, form, validation, uploads, and filters. The important part is that all of it came from the metadata we configured in the Designer.

Add a Custom Summary Endpoint

Generated CRUD is enough for day-to-day record editing, but teams often need one operation that is specific to their process.

For vendor onboarding, a summary endpoint is a good example:

GET /api/custom/vendor-onboarding/summary

In the Designer, open Actions and create a custom HTTP action with that route. The script can use the Scripting API to query the same VendorApplication data that the generated grid uses.

Here is the script used in the demo:

var entityName = 'Acme.VendorOnboardingLowCode.Procurement.VendorApplication';
var vendorQuery = await db.query(entityName);
var totalVendors = await db.count(entityName);
var submittedVendors = await vendorQuery.where(x => x.Status === 0).count();
var approvedVendors = await vendorQuery.where(x => x.Status === 2).count();
var today = query.today || new Date().toISOString().slice(0, 10);
var overdueReviews = await vendorQuery
  .where(x => x.ApprovalDeadline != null && x.ApprovalDeadline < today && x.Status !== 2)
  .count();

return ok({
  totalVendors: totalVendors,
  submittedVendors: submittedVendors,
  approvedVendors: approvedVendors,
  overdueReviews: overdueReviews,
  evaluatedOn: today
});

Use the entity name shown in your Designer. In the screenshots, it is Acme.VendorOnboardingLowCode.Procurement.VendorApplication.

When the endpoint runs, it returns the current counts from the low-code records:

That is the bridge I like here. The page and form stay metadata-driven, but the process-specific summary is a short script exposed as a custom endpoint.

Add One Runtime Model

Now switch the Designer layer to Runtime JSON and add one more entity: VendorEscalation.

This model represents the items that need extra attention. It could have been created in the same place as VendorApplication; I am adding it here only to show that runtime-authored metadata participates in the same Low-Code System.

Unlike the code and Dev JSON examples above, this runtime-authored model is not part of the source-controlled migration flow in this walkthrough.

The create modal is the same Designer experience, but the selected layer is now Runtime JSON:

Create a data grid page for it and open it in the React runtime:

From the user's point of view, it behaves like the first generated page. From the metadata point of view, we have now seen code-defined metadata, Designer-authored metadata, and runtime-authored metadata in the same application.

Read the Same Data from ABP Code

The last bridge is application code.

Sometimes the generated page is not the only consumer. You may want a typed application service, a scheduled job, or another API to read the same low-code records. The code below shows the idea by returning a backlog summary:

private readonly IRepository<DynamicEntity, Guid> _vendorApplicationRepository;
private readonly IAsyncQueryableExecuter _queryableExecuter;

public async Task<VendorBacklogDto> GetBacklogAsync()
{
    var entityDescriptor = DynamicModelManager.Instance.Find(
        "Acme.VendorOnboardingLowCode.Procurement.VendorApplication"
    );

    if (entityDescriptor == null)
    {
        throw new UserFriendlyException("VendorApplication model was not found.");
    }

    var query = await _vendorApplicationRepository
        .SetEntityName(entityDescriptor.Name)
        .GetQueryableAsync();
    var today = DateOnly.FromDateTime(Clock.Now);
    var priorityQuery = query.Where(vendor =>
        vendor.Data["IsPriority"] != null &&
        (bool?)vendor.Data["IsPriority"] == true);

    var nextPriorityVendor = await _queryableExecuter.FirstOrDefaultAsync(
        priorityQuery.OrderByDescending(vendor =>
            (DateOnly?)vendor.Data["RequestedOn"]));

    return new VendorBacklogDto
    {
        TotalVendors = checked((int)await _queryableExecuter.LongCountAsync(query)),
        PriorityVendors = checked((int)await _queryableExecuter.LongCountAsync(priorityQuery)),
        RejectedVendors = checked((int)await _queryableExecuter.LongCountAsync(
            query.Where(vendor =>
                vendor.Data["Status"] != null &&
                (int?)vendor.Data["Status"] == 3))),
        OverdueReviews = checked((int)await _queryableExecuter.LongCountAsync(
            query.Where(vendor =>
                vendor.Data["ApprovalDeadline"] != null &&
                (DateOnly?)vendor.Data["ApprovalDeadline"] < today &&
                vendor.Data["Status"] != null &&
                (int?)vendor.Data["Status"] != 2))),
        NextPriorityVendor = nextPriorityVendor?.GetData<string>("CompanyName")
    };
}

The important detail is that the aggregate operations stay on IQueryable; the code does not load every vendor into memory just to count them. This is not a replacement for the generated page. It is the other direction: use the generated page for the admin experience, then read the same records from normal ABP code when another part of the application needs them.

Going Further

The workflow we built is intentionally focused, but the same shape can grow in a few directions:

Add permissions around the generated pages and custom endpoint.
Add more form rules for review-specific fields.
Add an approval notification after a vendor is accepted.
Add a scheduled job that checks overdue applications.
Build a dashboard widget on top of the summary endpoint.

The main pattern stays the same: model the data in the Low-Code Designer, let the React runtime render the operational page, and add code or scripting only for the parts that are specific to your business process.

Conclusion

ABP Low-Code is useful when the first version of a business workflow is mostly metadata: entities, fields, filters, forms, validation, uploads, and a few custom actions.

In this vendor onboarding example, the VendorApplication model gave us a generated grid and form, the runtime handled upload fields and conditional UI, and a custom endpoint added the summary that CRUD would not provide by itself. We also saw that low-code metadata can come from the Designer, from runtime JSON, or from C# code when you need that bridge.

That is the part worth remembering: you can start with a working admin experience quickly, then extend the workflow where the generated behavior stops being enough.

Introducing ABP Low-Code: Build Real ABP Apps in Minutes

ABP.IO — Mon, 13 Jul 2026 12:44:16 +0000

Introducing ABP Low-Code: Build Real ABP Apps in Minutes

Create runtime-managed pages, generated React screens, code-first C# entities, and Script API extensions without leaving the ABP application model.

Want to try the same path? Start from ABP Studio, enable the Low-Code runtime and designer, define pages in the Admin Console, and see them resolve inside the running ABP app.

ABP Low-Code at a glance

Built into the ABP Platform

Low-code is most useful when speed does not create a separate stack to maintain later.

That is where many low-code products start to strain. They move quickly at the beginning, then force a second implementation track when the app needs permissions, auditability, custom logic, or tighter integration with existing application code.

ABP Low-Code takes a different path. It runs inside the ABP Platform , so runtime-managed pages are part of an application foundation that already includes identity, permissions, audit logging, APIs, and code-level extensibility.

Edit at runtime. See it in the app.

In the Low-Code Designer, you update a runtime-managed page. A few seconds later, the same application surface is visible in the live app. No rebuild loop. No parallel front-end implementation. No "we will wire it later" gap between authoring and runtime.

ABP Low-Code shortens the cycle from model change to running screen while keeping the output grounded in the same ABP application.

What this shows: authoring and runtime are connected. Pages are defined in the designer and resolved in the running application.

CRUD is table stakes

If low-code only saves you from drawing a table and a form, it is not enough. Business applications need richer operational surfaces.

In the generated app, the Events screen ships with search, actions, filters, and form-driven editing. The form structure already understands tabs, relations, validation, and business-shaped input instead of leaving you with a blank shell to finish by hand.

The point is not just generated CRUD. It is generated CRUD that already looks like the operational screens teams maintain in real applications.

One model, multiple operational screens

Business users do not think in one view. Operators want a calendar for scheduling, a kanban board for workflow, a grid for bulk operations, a gallery when media matters, and a dashboard when they need the state of the business at a glance.

ABP Low-Code keeps those surfaces attached to the same underlying model. The same Session model can appear as a calendar for planning and a kanban pipeline for operational flow. The same generated app can also include a speaker gallery and an overview dashboard for metrics.

This is where ABP Low-Code starts to feel less like a form generator and more like a runtime application layer: one model, many working screens, no second implementation track for each view type.

When low-code needs code

The real differentiator is not that ABP Low-Code can go fast. It is that speed does not require isolation from the application foundation.

When generated CRUD is not enough, you extend the same app instead of throwing the low-code layer away.

ABP Low-Code exposes a server-side Script API inside the same application model. That scripting surface can back:

Custom endpoints when the UI needs an API-shaped response.
Interceptors when create or update commands need validation or mutation.
Event handlers when logic should react to runtime events.
Background jobs when work should continue asynchronously.
Background workers when operational logic should run on a schedule.

In this article, the visible proof happens to be GET /api/custom/eventflow/highlights. The GIF shows an endpoint because it is the easiest proof surface to read. But the broader point is that endpoints are only one consumer of the same low-code scripting layer.

That hybrid model matters in both directions:

Code-first ABP entities can be surfaced in low-code flows and runtime pages.
Low-code-managed data and screens stay reachable from Script API actions, application services, repository queries, and custom endpoints.
Teams do not lose architectural control just because they gained a faster authoring layer.

The actual capability is the shared ABP application model behind it: script when runtime logic is enough, C# when typed application services and repository queries are the better fit.

This is the difference between "low-code as a shortcut" and "low-code as part of your application platform."

From code-first entity to generated page

The first direction is code-first to low-code. A code-first SponsorActivation entity checked into the ASP.NET Core project can still become a working runtime page without forking into a separate low-code-only model.

The code-first entity carries the same metadata that ABP Low-Code uses to generate the page:

[DynamicEntity(DefaultDisplayPropertyName = nameof(CompanyName))]
[DynamicEntityUI("Sponsor Activations")]
[DynamicEntityAttachments("application/pdf", "image/*", MaxFileCount = 4)]
public class SponsorActivation : DynamicEntityBase
{
    [Required]
    [DynamicPropertyUI(DisplayName = "Sponsor")]
    public string CompanyName { get; private set; }

    [Required]
    [EmailAddress]
    [DynamicPropertyUI(DisplayName = "Contact Email")]
    public string ContactEmail { get; private set; }

    public SponsorActivationStatus Status { get; set; }

    [DynamicForeignKey("EventFlow.Events.Event", "Title")]
    public Guid? EventId { get; set; }

    [DynamicForeignKey("Volo.Abp.Identity.IdentityUser", nameof(IdentityUser.UserName), ForeignAccess.View)]
    public Guid? OwnerUserId { get; set; }

    [DynamicPropertyType(EntityPropertyType.Money)]
    public decimal ActivationBudget { get; set; }

    [DynamicPropertyImageOptions("image/png", "image/jpeg")]
    public string? BrandLogo { get; set; }

    [DynamicPropertyFileOptions("application/pdf", ".pptx", ".docx")]
    public string? ActivationBrief { get; set; }
}

That class lives as normal C# source, gets migrated like the rest of the application, and is seeded with real records so the runtime page does not open as an empty shell.

Inside the designer, selecting the SponsorActivation entity auto-generates the page identity, binds the grid to the entity, and lands on a real runtime route at /dynamic/sponsor-activation. The generated surface includes sponsor, email, event lookup, owner lookup, budget, image, and file fields directly from the C# model.

That is the distinction that matters: code-first ABP entities can move through low-code without becoming throwaway artifacts, and low-code-generated surfaces remain part of the same application story.

Low-code data stays reachable from C

The bridge also works in the other direction. A normal ABP application service can query a low-code model through IRepository<DynamicEntity, Guid>, apply real filters, and combine that result with code-first aggregates.

The service behind the endpoint in the previous section looks like this:

public async Task<EventFlowLowCodeProofDto> GetHybridSummaryAsync()
{
    var liveSessionQuery = (await _dynamicEntityRepository
            .SetEntityName("EventFlow.Events.Session")
            .GetQueryableAsync())
        .Where("int(it[\"Status\"]) == @0", 2);

    var publicSessionQuery = liveSessionQuery
        .Where("bool(it[\"IsPublic\"]) == @0", true);

    var sponsorQuery = (await _sponsorActivationRepository.GetQueryableAsync())
        .Where(activation =>
            activation.Status == SponsorActivationStatus.Approved ||
            activation.Status == SponsorActivationStatus.Live);

    var liveSessionCount = await AsyncExecuter.CountAsync(liveSessionQuery);
    var publicSessionCount = await AsyncExecuter.CountAsync(publicSessionQuery);
    var activeSponsorActivationCount = await AsyncExecuter.CountAsync(sponsorQuery);

    return new EventFlowLowCodeProofDto
    {
        LiveSessionCount = liveSessionCount,
        PublicSessionCount = publicSessionCount,
        ActiveSponsorActivationCount = activeSponsorActivationCount
    };
}

Here, low-code-managed Session rows are filtered from C# with real Where(...) clauses, then combined with the typed SponsorActivation repository. The endpoint and dashboard are just one presentation surface for that shared ABP query path.

That is the ABP difference: low-code data stays reachable from code, and code-first entities stay reachable from low-code.

Why ABP Low-Code matters

The value is not novelty. It is a faster way to build real business applications without separating speed from the application foundation.

Speed without replatforming. Runtime-managed screens reduce delivery time without moving the team onto a separate application stack.
Governance without friction. Permissions, identity, auditability, and ABP platform foundations stay part of the story from day one.
Extensibility without rewrite pressure. When custom behavior shows up, the same application can be extended instead of replacing the low-code output.

That is the core ABP Low-Code promise: faster delivery, still inside the application model you can extend.

Try it yourself

The public starting point for ABP Low-Code is ABP Studio.

Open ABP Studio and create a new solution.
In the solution wizard, enable Include Low-Code runtime and designer.
Complete the wizard, then run the generated backend and React UI from the solution.
Sign in with the administrator account created for that solution.
Open Admin Console to define runtime-managed entities, forms, pages, permissions, endpoints, and script actions.
Switch to the application side to see those changes resolve live in the running app.

ABP Platform 10.6 RC Has Been Released

ABP.IO — Wed, 08 Jul 2026 05:41:45 +0000

ABP Platform 10.6 RC Has Been Released

We are happy to release ABP version 10.6 RC (Release Candidate). This blog post introduces the new features and important changes in this new version.

Try this version and provide feedback for a more stable version of ABP v10.6! Thanks to you in advance.

Get Started with the 10.6 RC

You can check the Get Started page to see how to get started with ABP. You can either download ABP Studio ( recommended , if you prefer a user-friendly GUI application - desktop application) or use the ABP CLI.

By default, ABP Studio uses stable versions to create solutions. Therefore, if you want to create a solution with a preview version, first you need to create a solution and then switch your solution to the preview version from the ABP Studio UI:

Migration Guide

You can check the migration guide if you are upgrading from v10.5 or earlier: ABP Version 10.6 Migration Guide.

What's New with ABP v10.6?

In this section, I will introduce some major features released in this version. Here is a brief list of titles explained in the next sections:

Background Jobs: Dedicated Workers, Parallel Execution, and Successful Job Retention
API Definition and Proxy Improvements for Content Types and Multipart Uploads
Angular UI: Upgrade to Angular 22
Antiforgery and OpenIddict Security Improvements
OpenIddict: Generate Access Token from the UI
Dependency Updates

Background Jobs: Dedicated Workers, Parallel Execution, and Successful Job Retention

ABP v10.6 adds three opt-in enhancements to the default background job worker. All of them are disabled by default, so existing applications keep the current behavior unless you enable them explicitly.

Storing successful jobs

By default, a job is deleted as soon as it runs successfully. You can now set StoreSuccessfulJobs = true to keep completed jobs in the store. A new CompletionTime column marks completed jobs, and a cleanup worker prunes them after SuccessfulJobRetentionTime (default: 7 days).

Dedicated workers per job type

AddDedicatedWorker(...) registers a worker that processes only the configured job argument types, each with its own distributed lock. The default worker continues handling all remaining job types.

Parallel job execution

Set MaxParallelJobExecutionCount greater than 1 to execute multiple jobs in the same poll cycle. In this mode, each job is claimed with its own distributed lock so different application instances can process different jobs concurrently without running the same job twice.

Example configuration:

Configure<AbpBackgroundJobWorkerOptions>(options =>
{
    options.StoreSuccessfulJobs = true;
    options.SuccessfulJobRetentionTime = TimeSpan.FromDays(30);

    options.AddDedicatedWorker<EmailJobArgs, SmsJobArgs>("NotificationWorkerLock");
    options.AddDedicatedWorker<ReportJobArgs>("ReportWorkerLock");

    options.MaxParallelJobExecutionCount = 4;
});

These options are useful when you need better isolation between job types, higher throughput in clustered deployments, or an audit trail of successfully completed jobs.

See the Background Jobs documentation and #25742 for details.

API Definition and Proxy Improvements for Content Types and Multipart Uploads

ABP v10.6 improves API definition generation and client proxies for file upload scenarios and non-JSON response types.

The API definition now exposes response ContentTypes and an IsRemoteStream flag. C#, jQuery, and Angular proxies can use the declared media type instead of collapsing everything to application/json and text/plain.

For upload DTOs containing IRemoteStreamContent, generated Angular and jQuery proxies now forward FormData as multipart requests instead of silently dropping the file payload or trying to serialize the stream as JSON.

Server-side setup still follows the existing ABP pattern:

Configure<AbpAspNetCoreMvcOptions>(options =>
{
    options.ConventionalControllers.FormBodyBindingIgnoredTypes.Add(typeof(UploadFileDto));
});

Angular client example after proxy regeneration:

const fd = new FormData();
fd.append('Name', 'logo');
fd.append('File', fileInput.files[0], 'logo.png');
this.fileService.uploadFile(fd).subscribe(result => ...);

This closes long-standing gaps in generated proxies for stream-based uploads and improves support for text, blob, and custom response types.

See #25639 for details.

Angular UI: Upgrade to Angular 22

ABP v10.6 upgrades the Angular UI stack to Angular 22.0.x.

This release also improves the locale loading mechanism with a fallback path, so culture resources load more reliably when optional locale files are missing or partially available.

If you maintain a custom Angular UI on top of ABP, plan for the Angular 22 upgrade together with your ABP package update and regenerate proxies after upgrading.

See #25690 and #25734 for details.

Antiforgery and OpenIddict Security Improvements

ABP v10.6 includes several security-focused fixes for mixed authentication scenarios.

Antiforgery claim issuer normalization

When an application serves a token-authenticated SPA and cookie-authenticated MVC pages on the same origin, antiforgery validation could fail because the user id claim issuer differed between JWT and cookie authentication schemes. ABP now normalizes the user id claim issuer while generating and validating antiforgery tokens.

This behavior is enabled by default through AbpAntiForgeryOptions.NormalizeUserIdClaimIssuer. Razor Pages antiforgery validation was also aligned with the same normalization logic, which fixes failures in modules such as Setting Management.

Prevent OpenIddict client_id from leaking into the interactive auth cookie

ABP fixed a case where an OpenIddict authorization request could stamp the requested client_id into the interactive authentication cookie during security-stamp refresh. That could corrupt audit logs and make later cookie-authenticated requests appear to belong to the OAuth client.

The fix strips client_id when the interactive cookie is refreshed. Tokens are unaffected, and cookies that were already corrupted self-heal on the next refresh.

Forward the current access token for authenticated client requests

HttpContextAbpAccessTokenProvider now forwards the incoming access token whenever the request is authenticated, including client_credentials requests. This prevents unnecessary fallback to configured identity clients in machine-to-machine scenarios.

See #25655, #25669, #25711, and #25740 for details.

OpenIddict: Generate Access Token from the UI

ABP Commercial v10.6 RC adds a Generate Access Token action to OpenIddict application management pages across MVC, Blazor, MudBlazor, and Angular UIs.

Administrators can request a token for an OpenIddict application directly from the UI. The backend forwards a client_credentials request to /connect/token and returns the generated access token to the caller.

This is especially useful for testing integrations, validating scopes, and troubleshooting machine-to-machine authentication without leaving the admin UI.

Dependency Updates

ABP v10.6 RC includes several dependency and package updates:

Angular packages upgraded to 22.0.x
Microsoft.* and System.* packages upgraded to 10.0.9
Microsoft.Data.SqlClient upgraded to 7.0.2
Swashbuckle.AspNetCore upgraded to 10.2.3

Check the Package Version Changes document for all updates.

Other Improvements and Enhancements

Permission management : Skip dynamic permission initialization during migration runs to avoid noisy logs when the database is unavailable (#25743).
Security / principal access : ThreadCurrentPrincipalAccessor now returns an anonymous principal instead of null in non-web contexts (#25752).
Angular proxy generation : Array parameters are now generated as readonly in Angular proxies (#25687).
Date/time normalization : Removed misleading warnings when normalizing Unspecified DateTime values near range boundaries (#25703).
AI Management : Indexing is more resilient under memory pressure in the commercial module.

Community News

New ABP Community Articles

As always, exciting articles have been contributed by the ABP community. I will highlight some of them here:

Thanks to the ABP Community for all the content they have published. You can also post your ABP related (text or video) content to the ABP Community.

ABP Summer Campaign: Get Up To 20% Off + $300 in AI Credits

Summer is a great time to start building with ABP. From July 6 to July 20 , we're offering exclusive summer savings on ABP licenses and renewals : 20% off new licenses , 10% off renewals , and up to $300 in AI credits for the ABP AI Agent in ABP Studio. Whether you're starting a new project or upgrading your development workflow, this limited-time offer helps you save on your license while accelerating development with AI.

You can read the announcement here: ABP Summer Campaign: Get Up To 20% Off + $300 in AI Credits.

Conclusion

This version comes with some new features and a lot of enhancements to the existing features. You can see the Road Map documentation to learn about the release schedule and planned features for the next releases. Please try ABP v10.6 RC and provide feedback to help us release a more stable version.

Thanks for being a part of this community!

ABP 10.5.0 Expands Blazor UI Options with MudBlazor Support

ABP.IO — Wed, 01 Jul 2026 08:25:31 +0000

ABP 10.5.0 Expands Blazor UI Options with MudBlazor Support

With ABP 10.5.0, new Blazor projects can now use MudBlazor (Material Design) as an alternative to the long-standing default, Blazorise (Bootstrap 5). Framework, themes (LeptonX / LeptonX Lite / Basic), modules, solution templates, ABP Studio, and ABP Suite all support both libraries side by side. The 10.5.0 packages are live on nuget.org.

Why add another Blazor UI library?

Blazorise has been ABP's default Blazor UI library for years and remains the default and is fully supported — existing Blazorise projects can keep moving at their own pace, and upgrading to 10.5.0 does not change anything for them.

We added MudBlazor because one Blazor UI choice cannot fit every team:

Design language — Bootstrap and Material Design serve different audiences, and forcing a single choice does not fit every team
Open-source preference — MudBlazor is MIT-licensed, which works well for teams that want an open-source frontend component stack without extra component-library licensing or compliance overhead
Ecosystem fit — Material Design third-party components (charts, rich text editors, data visualization, and so on) tend to integrate more naturally with a MudBlazor project

For new projects you can start with MudBlazor right away. Existing Blazorise projects do not need to be rewritten just to switch UI libraries.

Who should consider MudBlazor?

Teams that want the frontend component stack fully open source with no licensing to manage (individual developers, open-source community projects, education / learning settings)
Organizations with internal third-party dependency or supply-chain compliance requirements that prefer MIT-licensed components
New Blazor projects that want to start with Material Design
Teams already comfortable with the MudBlazor ecosystem (charts, rich text, rich UI components)

What the MudBlazor option covers

Framework core

Volo.Abp.MudBlazorUI provides the MudBlazor implementation of ABP's UI service abstractions, so code written against IUiMessageService / IUiNotificationService / IUiPageProgressService runs unchanged in a MudBlazor project. Key building blocks:

MudBlazorUiMessageService — Info / Success / Warn / Error / Confirm rendered through MudDialog
MudBlazorUiNotificationService — toast notifications via MudSnackbar
MudBlazorUiPageProgressService — top progress bar via MudProgressLinear
AbpMudCrudPageBase<...> — the MudBlazor counterpart to Blazorise's AbpCrudPageBase
AbpMudExtensibleDataGrid<TItem> — a MudDataGrid wrapper integrated with Object Extension and time-zone conversion
UiMessageAlert / UiNotificationAlert / PageAlert — page-level alert and notification containers

Theming is split across three hosts — Blazor Server, WebAssembly, and MauiBlazor — each shipped with matching bundling contributors and modules that wire MudBlazor's JS and CSS into the ABP bundle system.

Three themes

LeptonX MudBlazor
LeptonX Lite MudBlazor
Basic Theme MudBlazor

Each theme's layout adopts MudBlazor components such as MudAppBar, MudDrawer, MudNavLink, and MudMenu, while keeping the theme's original color palette, dim / light / system modes, and RTL support.

LeptonX rendered with MudBlazor

LeptonX Lite rendered with MudBlazor

Basic Theme rendered with MudBlazor

The LeptonX themes reuse the same lpx-* CSS classes across both UI libraries, so the overall information architecture, page layout, and theme experience stay consistent with the Blazorise version. Individual controls follow each UI library's own conventions.

The same LeptonX theme — MudBlazor on the left, Blazorise on the right

Module coverage

Open-source modules in abpframework/abp that ship with a MudBlazor implementation:

Account
Identity — Users / Roles / OUs / ClaimTypes
Permission Management — parent/child permissions with MudTreeView and tri-state MudCheckBox
Setting Management — grouped settings with MudTabs (including theme switching)
Tenant Management
Feature Management

Additional MudBlazor implementations available on the Pro side, for example:

Identity Pro — extra management around Sessions, SecurityLogs, and more
OpenIddict Pro — Application / Scope management
Saas — Tenant / Edition management with a connection-string dialog
Audit Logging — MudDataGrid with a detail MudDialog
Language Management / Text Template Management
File Management / Chat / CMS Kit Pro
AI Management / GDPR / Payment , and more

Identity user management built on AbpMudExtensibleDataGrid

Permission Management uses MudTreeView and tri-state MudCheckBox for parent/child permissions

Saas module: tenant list with a "New tenant" dialog that includes connection-string editing

Component mapping at a glance

If you already know Blazorise, here are the most common mappings:

| Blazorise | MudBlazor | |-----------|-----------| | TextEdit @bind-Text | MudTextField @bind-Value | | Select / SelectItem | MudSelect / MudSelectItem | | DataGrid | MudDataGrid (wrapped by ABP as AbpMudExtensibleDataGrid) | | Modal Show()/Hide() | MudDialog ShowAsync()/CloseAsync() | | Validations | MudForm + built-in validation | | Row / Column ColumnSize.Is6 | MudGrid / MudItem xs="12" sm="6" | | Bootstrap Icons bi-* | Icons.Material.Filled.* |

A full mapping table with razor examples lives in the ABP Blazor UI documentation.

Supported Blazor project types

ABP's MudBlazor support covers the Blazor project types you can create and run directly:

Blazor Server (-u blazor-server)
Blazor WebAssembly (-u blazor)
Blazor WebApp (-u blazor-webapp, including InteractiveAuto)

ABP Suite

ABP Suite detects the solution's UI library and generates the matching CRUD page automatically:

public partial class Books : AbpMudCrudPageBase<IBookAppService, BookDto, Guid, GetBookListInput, CreateUpdateBookDto>
{
    private MudDialog _createDialog;
    private MudForm _createFormRef;
}

The razor templates also split by UI library — Blazorise uses <DataGrid> + <Modal> + <Validations>, MudBlazor uses <MudDataGrid> + <MudDialog> + <MudForm>.

Choosing between Blazorise and MudBlazor

Both UI libraries are production-ready and neither is strictly better. Common factors:

Familiarity — teams comfortable with Bootstrap tend to stay on Blazorise; teams comfortable with Material Design pick MudBlazor
Design system — Bootstrap-style products lean toward Blazorise, Material Design products lean toward MudBlazor
Ecosystem — existing Bootstrap component libraries or design assets fit Blazorise; Material Design third-party components fit MudBlazor more naturally
Existing projects — keep maintaining live Blazorise projects as they are; if you want to try MudBlazor, start a new project with it
Licensing — the two UI libraries have different license terms, so check each library's official license page before making a choice (Blazorise / MudBlazor)

Do not mix the two libraries within a single project — the choice is per solution, not per file.

Creating a MudBlazor project in ABP Studio

ABP Studio (recommended)

Open ABP Studio → New Solution → pick a template → in the UI configuration step, select Blazor UI library = MudBlazor. Everything else works the same as a Blazorise project. After Build & Run you land on a MudBlazor-styled application.

New Solution wizard: pick MudBlazor for the Blazor UI library

Studio Build & Run brings up a MudBlazor + LeptonX dashboard in the embedded browser

CLI

# Blazorise (default; --blazor-ui-library can be omitted)
abp new MyApp -u blazor

# MudBlazor
abp new MyApp -u blazor --blazor-ui-library mudblazor

# Tiered + WebApp + LeptonX + MudBlazor
abp new MyApp -t app --tiered -u blazor-webapp --blazor-ui-library mudblazor --theme leptonx

# Microservice + MudBlazor + Blazor Server
abp new MyApp -t microservice -u blazor-server --blazor-ui-library mudblazor

# Reusable Module + MudBlazor
abp new My.Module -t module -u blazor --blazor-ui-library mudblazor

Run abp new --help for the full option list.

Suite-generated MudBlazor CRUD pages are covered in the ABP Suite section above.

Try it out

abp new MyMudApp -u blazor-server --blazor-ui-library mudblazor --theme leptonx

Documentation:

FAQ

I'm already using Blazorise — will upgrading to 10.5.0 break my project? No. Blazorise stays the default, and package paths, type names, and namespaces are fully compatible. Follow the standard ABP upgrade flow.

Can I use Blazorise and MudBlazor in the same project? We don't recommend it. The UI library is a project-level choice — themes, bundling, and module dependencies all switch with it. Mixing both within a single solution leads to bundle conflicts, duplicated layouts, and similar issues.

What about my custom razor pages? Your custom Razor pages are tied to the UI library they were built with, so switching libraries means rewriting those pages using the component mapping above. Template-generated pages and module-provided pages don't need to be touched.

Wrapping up

MudBlazor is now a first-class Blazor UI library in ABP. With 10.5.0 released, every related package, theme, template, Studio integration, and Suite generator is in place — you can try it out with a single abp new command.

If you hit a bug, have a suggestion, or want a particular module's MudBlazor UX prioritized, let us know via GitHub Issues or abp.io support.

References

ABP.IO Platform 10.5 Final Has Been Released!

ABP.IO — Tue, 30 Jun 2026 11:45:46 +0000

ABP.IO Platform 10.5 Final Has Been Released!

We are glad to announce that ABP 10.5 stable version has been released.

What's New With Version 10.5?

All the new features were explained in detail in the 10.5 RC Announcement Post, so there is no need to review them again. You can check it out for more details.

Getting Started with 10.5

How to Upgrade an Existing Solution

You can upgrade your existing solutions with either ABP Studio or ABP CLI. In the following sections, both approaches are explained:

Upgrading via ABP Studio

After upgrading the ABP Studio, then you can open your solution in the application, and simply click the Upgrade ABP Packages action button to instantly upgrade your solution:

Upgrading via ABP CLI

Alternatively, you can upgrade your existing solution via ABP CLI. First, you need to install the ABP CLI or upgrade it to the latest version.

If you haven't installed it yet, you can run the following command:

dotnet tool install -g Volo.Abp.Studio.Cli

Or to update the existing CLI, you can run the following command:

dotnet tool update -g Volo.Abp.Studio.Cli

After installing/updating the ABP CLI, you can use the update command to update all the ABP related NuGet and NPM packages in your solution as follows:

abp update

You can run this command in the root folder of your solution to update all ABP related packages.

Migration Guides

There are no explicitly marked breaking changes in this version. However, there are still some important migration notes for specific scenarios. Please read the migration guide carefully, if you are upgrading from v10.4 or earlier versions: ABP Version 10.5 Migration Guide

Community News

New ABP Community Articles

As always, exciting articles have been contributed by the ABP community. I will highlight some of them here:

Sumeyye Kurtulus has published 2 new articles:
- Angular 22 State Management: Signals, SignalStore, or NgRx?
- Customizing the ABP Framework: A Developer's Guide to LeptonX Theme Overrides in Angular and the Transition to React UI
Working with Dapr Workflows in the ABP Framework by Engincan Veske
Alper Ebicoglu has published 2 new articles:
- My Speaker's View of CONVEX Summit 2026
- AI Isn't Replacing Developers - It's Changing What Good Developers Spend Time On
Deep Dive on ABP AI Agent: The Complete Series by Berkan Sasmaz
- We have created a deep-dive series for ABP Studio's AI Coding Agent. You can read this series to learn the main features of the AI Coding Agent and how it can help you while developing ABP-based solutions.

Thanks to the ABP Community for all the content they have published. You can also post your ABP related (text or video) content to the ABP Community.

About the Next Version

The next feature version will be 10.6. You can follow the release planning here. Please submit an issue if you have any problems with this version.

Angular 22 State Management: Signals, SignalStore, or NgRx?

ABP.IO — Tue, 30 Jun 2026 07:38:01 +0000

Angular 22 State Management: Signals, SignalStore, or NgRx?

Angular has been steadily moving toward a signal-first architecture since the introduction of Signals in Angular 16. With Angular 22, that transition reaches another milestone. Signals are now at the center of Angular's reactive programming model, while APIs such as Resource and Signal Forms have matured into production-ready solutions. Combined with the framework's continued investment in zoneless change detection, these improvements significantly influence how Angular applications should manage state.

This shift also changes the role of NgRx. While the classic NgRx Store remains a powerful solution for large, event-driven applications, many scenarios that previously required reducers, selectors, and effects can now be implemented with much simpler, feature-scoped signal stores. Rather than replacing NgRx, Angular 22 encourages developers to choose the right state management strategy based on the scope and complexity of the problem.

In this article, we'll explore how Angular 22 changes the state management landscape, compare the classic NgRx Store with NgRx SignalStore, and demonstrate best practices for building modern Angular applications. We'll also discuss how Angular's new reactive APIs fit into enterprise applications and what these changes mean for projects built with the ABP Framework.

Why Angular 22 Changes State Management

Angular Signals introduced a fundamentally different approach by providing fine-grained reactivity built directly into the framework. Instead of propagating changes through Observable streams, Signals allow Angular to track exactly which pieces of state are consumed and update only the affected parts of the UI. This results in more predictable rendering, less boilerplate, and improved runtime performance.

Angular 22 builds on this foundation by making Signals the preferred reactive primitive throughout the framework. New APIs such as Resource for asynchronous data loading and Signal Forms for reactive forms integrate naturally with Signals, reducing the need for custom RxJS pipelines in many common scenarios.

For developers using NgRx, this doesn't mean abandoning existing applications or rewriting every store. Instead, it changes how state management should be approached. Component-local state can often be managed with plain Signals, feature-level state fits naturally into SignalStore, and the classic NgRx Store continues to excel for large-scale applications that benefit from centralized event streams, auditing, and global state synchronization.

Understanding these changing responsibilities is the key to designing maintainable Angular applications in the Angular 22 era. A practical way to think about state management is to start with the simplest solution and introduce additional abstractions only when the application's complexity requires them.

Use Signals for Local Component State

Plain Angular Signals are ideal for state that belongs exclusively to a single component. Examples include dialog visibility, selected tabs, loading indicators, filter values, or temporary form data.

Signals provide a straightforward API with minimal overhead and integrate seamlessly with Angular's change detection. For state that never needs to be shared outside a component or its immediate children, introducing a dedicated store often adds unnecessary complexity.

A settings page often contains UI state that doesn't need to be shared with the rest of the application. Using a dedicated store for this would introduce unnecessary complexity.

@Component({...})
export class UserListComponent {
  readonly search = signal('');
  readonly showInactive = signal(false);

  readonly filteredUsers = computed(() =>
    this.users().filter(user =>
      user.name.includes(this.search()) &&
      (this.showInactive() || user.active)
    )
  );
}

This state is entirely local to the component and doesn't justify introducing a SignalStore.

Use NgRx SignalStore for Feature State

As applications grow, state often needs to be shared across multiple components within the same feature. Examples include user profiles, shopping carts, administration screens, dashboards, or settings pages.

NgRx SignalStore is designed specifically for these scenarios. It combines Angular Signals with a lightweight, feature-oriented architecture where state, computed values, and business logic are defined together. Instead of scattering logic across reducers, selectors, effects, and services, developers can keep everything related to a feature inside a single store.

SignalStore also integrates naturally with Angular's signal-based APIs, making it an excellent choice for modern Angular applications built around Resources and Signal Forms.

A User Management module is shared by multiple pages. The selected user, filters, and loaded entities should remain synchronized across those pages.

export const UserStore = signalStore(
  withState({
    users: [] as User[],
    selectedUserId: null as number | null,
    loading: false,
  }),

  withComputed(({ users, selectedUserId }) => ({
    selectedUser: computed(() =>
      users().find(x => x.id === selectedUserId())
    ),
  })),

  withMethods((store) => ({
    selectUser(id: number) {
      patchState(store, { selectedUserId: id });
    },
  })),
);

Everything related to the feature lives in one place: state, derived values, and business operations.

NgRx Store vs. NgRx SignalStore

Although both solutions belong to the NgRx ecosystem, they are designed to solve different architectural problems.

The classic NgRx Store follows the Redux pattern, where every state change is represented by an action that flows through reducers before producing a new immutable state. This explicit, event-driven architecture provides excellent traceability and scales well for applications with extensive global interactions.

SignalStore takes a different approach. Instead of centering the application around dispatched actions, it treats state as a reactive service built with Angular Signals. A SignalStore typically contains three core building blocks:

State , which represents the application's reactive data.
Computed signals , which derive values from existing state.
Methods , which encapsulate business logic and state updates.

This functional model significantly reduces boilerplate while remaining predictable and testable. Since it builds directly on Angular Signals, it also integrates naturally with Angular's fine-grained change detection without requiring selectors or async pipes for many common scenarios.

The following comparison summarizes the strengths of each approach.

| Feature | Classic NgRx Store | NgRx SignalStore | | ---------------- | ------------------------------- | --------------------------------- | | Architecture | Redux-based global store | Feature-oriented reactive store | | Reactivity | RxJS Observables | Angular Signals | | Boilerplate | Higher | Lower | | State Scope | Global application state | Feature or route state | | Side Effects | Effects | Store methods or rxMethod | | Change Detection | Observable subscriptions | Native signal reactivity | | Best For | Large event-driven applications | Modern feature-based applications |

For most new Angular 22 applications, SignalStore is an excellent default choice for feature-level state management because it embraces the framework's signal-first architecture while keeping code concise and maintainable. The classic NgRx Store remains indispensable for applications that rely heavily on centralized event processing, global synchronization, or advanced debugging capabilities.

Instead of asking "Which one should I use?", the better question is "Which scope of state am I trying to manage?" The answer usually determines the appropriate solution.

Angular 22 Features That Improve State Management

Angular 22 introduces several framework APIs that naturally complement modern state management patterns. Rather than replacing NgRx, these APIs reduce the amount of custom infrastructure developers previously had to build around it.

Resource API

One of the most significant additions is the Resource API , which provides a signal-based approach to asynchronous data loading.

Historically, fetching remote data in Angular involved coordinating HttpClient, RxJS operators, subscriptions, loading flags, and error handling. While these patterns remain valid, they often require considerable boilerplate even for straightforward scenarios.

Resources encapsulate these concerns into a single reactive abstraction. A Resource automatically tracks the signals it depends on, performs requests when those dependencies change, cancels obsolete requests, and exposes its lifecycle through reactive state such as the current value, loading status, and errors.

This makes Resources particularly well suited for read-oriented operations where data should stay synchronized with application state.

For example, changing a selected user ID can automatically trigger a new request without manually wiring switchMap or managing subscription lifecycles.

const userResource = httpResource(() => ({
  url: `/api/users/${selectedUserId()}`
}));

Signal Forms

Another major improvement is the stabilization of Signal Forms.

Traditional Reactive Forms expose their state through FormControl and FormGroup instances, requiring developers to query validation status, dirty state, touched state, and values through an imperative API.

Signal Forms expose these properties as signals instead. Every field becomes reactive by default, making templates easier to read while eliminating much of the manual state synchronization commonly found in form-heavy applications.

@if (profileForm.email.invalid() && profileForm.email.touched()) {
  <span>Please enter a valid email.</span>
}

Because field state is already reactive, components rarely need additional subscriptions or helper observables to keep the UI synchronized.

It's important to note that Signal Forms are responsible for UI state , while business operations such as saving data, loading entities, or handling server responses still belong in a dedicated service or SignalStore. Keeping these responsibilities separate results in components that remain focused on presentation while stores continue to own application logic.

Best Practices for Building Modern SignalStores

SignalStore significantly reduces the ceremony traditionally associated with state management, but the same architectural principles still apply. A well-designed store should encapsulate business logic without becoming responsible for concerns that belong elsewhere.

Keep Stores Focused on a Single Feature A SignalStore should represent a cohesive business feature rather than becoming a global container for unrelated state. For example, an administration module might expose separate stores for users, roles, and permissions instead of combining all administrative functionality into a single, monolithic store. Smaller stores are easier to test, understand, and maintain over time.
Store Business State, Not UI State Not every piece of state belongs in a store. Transient UI concerns such as dialog visibility, selected tabs, expanded panels, or temporary input values are usually better managed with plain Signals inside the component. Stores should own state that represents the application's business domain—entities, filters, permissions, settings, or data shared across multiple components.
Derive State Instead of Duplicating It Whenever possible, compute values instead of storing them. SignalStore's withComputed() feature makes it easy to derive reactive values from existing state, reducing the likelihood of inconsistent or stale data. Instead of storing both a list of users and an active user count, derive the count directly from the collection.

withComputed(({ users }) => ({
  activeUsers: computed(() =>
    users().filter(user => user.active).length
  ),
}))

Keeping a single source of truth simplifies updates and reduces maintenance. 4. Prefer Immutable State Updates Although SignalStore simplifies updates through patchState(), state should still be treated as immutable. Updating only the affected portions of state makes changes predictable and allows Angular's signal system to efficiently notify dependent computations.

patchState(store, {
  users: [...store.users(), newUser]
});

Integrating Resources with SignalStore

Resources and SignalStore solve different problems, and understanding their responsibilities leads to a cleaner architecture.

A Resource is responsible for synchronizing data with a remote source. It knows how to load data, react to parameter changes, expose loading and error states, and keep requests up to date.

A SignalStore , on the other hand, owns the application's business state. It coordinates operations, exposes domain-specific methods, derives computed values, and serves as the single source of truth for a feature.

Rather than replacing one another, they work best together.

A common pattern is to use a Resource for loading entities while allowing the store to expose business operations that modify those entities.

export const UserStore = signalStore(
  withState({
    selectedUserId: undefined as number | undefined,
  }),

  withComputed(({ selectedUserId }) => ({
    userResource: httpResource<User>(() => {
      const id = selectedUserId();

      return id
        ? {
            url: `/api/users/${id}`,
          }
        : undefined;
    }),
  })),

  withMethods((store) => ({
    selectUser(id: number) {
      patchState(store, {
        selectedUserId: id,
      });
    },
  })),
);

In this example, changing the selected user automatically causes the Resource to fetch new data. The store doesn't need to manage subscriptions or manually coordinate loading indicators because the Resource already exposes this information through signals.

This separation keeps data synchronization declarative while allowing the store to remain focused on business behavior.

Integrating Signal Forms with SignalStore

Signal Forms and SignalStore naturally complement one another because both are built on Angular Signals. However, they should not be treated as interchangeable.

Signal Forms are responsible for managing user input and validation, while SignalStore coordinates business operations such as loading, updating, and persisting data.

A common workflow consists of four steps:

Load the entity through the store.
Populate the Signal Form.
Allow the user to edit the data.
Submit the updated values back to the store.

The component remains responsible only for orchestrating the interaction between the form and the store.

@Component({
  // ...
})
export class UserEditorComponent {
  readonly store = inject(UserStore);

  readonly form = form({
    name: '',
    email: '',
  });

  async save() {
    if (this.form.invalid()) {
      return;
    }

    await this.store.updateUser(this.form.value());
  }
}

This approach keeps presentation concerns inside the component while allowing business rules to remain centralized in the store.

Handling Asynchronous Operations

One challenge when combining Signal Forms with SignalStore is coordinating asynchronous operations.

A form submission typically expects an asynchronous operation to complete before updating its own state. Meanwhile, the store is responsible for managing loading indicators, server errors, and successful updates.

Instead of placing HTTP requests directly inside components, expose descriptive methods such as createUser(), updateProfile(), or changePassword() from the store. Components simply invoke these methods and react to the outcome.

This keeps components lightweight while making business logic reusable across multiple views.

A Clear Separation of Responsibilities

A useful guideline is to divide responsibilities as follows:

| Concern | Recommended Owner | | ------------------- | ------------------------------------------ | | User input | Signal Forms | | Validation | Signal Forms | | Loading remote data | Resource | | Business rules | SignalStore | | State mutations | SignalStore | | HTTP persistence | Service or repository invoked by the store |

Following these boundaries results in components that focus on presentation, stores that encapsulate business logic, and Resources that handle server synchronization. Each part has a single responsibility, making the application easier to understand, test, and maintain as it grows.

Migrating from Classic NgRx to SignalStore

Migrating to SignalStore doesn't require replacing an entire application's state management strategy overnight. In fact, most enterprise applications can adopt SignalStore incrementally while continuing to use the classic NgRx Store where it provides the greatest value.

A practical migration strategy is to start with isolated features rather than the application's global state.

Keep the Classic Store for Global State

Global concerns such as authentication, user sessions, application configuration, notifications, and cross-feature communication often continue to benefit from the centralized architecture of the classic NgRx Store.

These areas typically rely on dispatched actions and event-driven workflows that remain well suited to Redux patterns.

Introduce SignalStore for New Features

New feature modules are excellent candidates for SignalStore.

Instead of creating actions, reducers, selectors, and effects, developers can define state, computed values, and business methods in a single store. This reduces boilerplate while aligning the feature with Angular's signal-first architecture.

Existing features can also be migrated gradually as they evolve, avoiding large-scale refactoring efforts.

Move Component State First

The easiest migration is often replacing component-local Observables and BehaviorSubjects with Signals.

Many components don't require a dedicated store at all. Converting temporary UI state to Signals simplifies the codebase immediately and familiarizes teams with Angular's reactive model before introducing SignalStore.

Incremental adoption minimizes risk while allowing teams to modernize applications at a sustainable pace.

What This Means for ABP Applications

Angular 22's signal-first architecture aligns well with ABP's modular application model.

Most ABP applications consist of independent feature modules such as Identity, Tenant Management, SaaS, or CMS. These modules naturally map to feature-scoped SignalStores, allowing state and business logic to remain encapsulated within each module. However, the full support will be introduced in the next version.

As Angular continues investing in Signals, Resources, and Signal Forms, future ABP applications can increasingly rely on the framework's native reactive APIs instead of custom state management patterns.

This doesn't diminish the importance of RxJS or the classic NgRx Store. RxJS remains an essential foundation of Angular's HTTP infrastructure and many third-party libraries, while the traditional Store continues to provide an excellent solution for complex global state management.

Instead, Angular 22 encourages developers to use each reactive tool where it provides the greatest value.

Whether you're upgrading an existing ABP application or starting a new project, adopting SignalStore for feature-level state can simplify development while remaining fully compatible with Angular's evolving ecosystem.

Conclusion

Angular's evolution toward a signal-first architecture represents more than a new reactive API—it changes how applications should be designed.

Rather than treating every piece of state as part of a centralized store, Angular now encourages developers to choose the appropriate abstraction for each responsibility. Plain Signals excel at local component state, SignalStore provides a lightweight solution for feature-level business logic, Resources simplify server synchronization, and Signal Forms modernize user input management.

The classic NgRx Store continues to play an important role in large, event-driven applications, but it no longer needs to be the default choice for every state management scenario.

By embracing these complementary tools, developers can build Angular applications that are simpler to maintain, require less boilerplate, and integrate naturally with the framework's latest capabilities.

As Angular continues to evolve around Signals and fine-grained reactivity, adopting these patterns today will help applications remain aligned with the framework's direction while providing a solid foundation for future improvements.

Working with Dapr Workflows in the ABP Framework

ABP.IO — Mon, 29 Jun 2026 17:39:42 +0000

Working with Dapr Workflows in the ABP Framework

Most real business processes don't finish in a single request.

An order gets placed, inventory gets checked, a payment gets charged, and the customer gets notified. Each step can fail, time out, or need a retry. And the whole thing has to survive a process restart without losing its place or charging someone twice.

We usually solve this with a pile of queues, a state table, and a lot of defensive code to track where each process is. It works, but the business logic ends up scattered across handlers and database rows, and nobody can read the flow top to bottom anymore.

I covered Elsa in two earlier articles as one way to handle workflows in ABP. Dapr Workflow takes a different path: instead of an in-app engine, the workflow engine runs in the Dapr sidecar, and you write the process as ordinary C# code that Dapr makes durable. If the host crashes halfway through, the workflow picks up right where it left off.

In this article, we'll build a small Dapr Workflow inside a fresh ABP project and run it end to end. By the time you reach the bottom, you should be able to copy the code, run it, and watch a workflow march through its steps.

Note: Versions matter here, because both ABP and Dapr move fast. This article is written in June 2026 against ABP 10.4 (.NET 10), Dapr 1.18 , and the Dapr.Workflow 1.18.x package. The Dapr.Workflow package was rewritten in Dapr 1.17, so older tutorials you find online may use a different API.

What Dapr Workflow Actually Is?

You define a workflow that orchestrates a process, and activities that do the actual work (call a database, hit an API, send an email).

This is orchestration rather than choreography: one place drives the process, instead of services reacting to each other's events. The definitions live in your app, but the engine that executes them runs in the Dapr sidecar next to it.

flowchart LR
    subgraph App["Your ABP App"]
        WF["OrderProcessingWorkflow"]
        ACT["Activities<br/>CheckInventory, ProcessPayment, NotifyCustomer"]
    end
    subgraph Sidecar["Dapr Sidecar"]
        ENGINE["Workflow Engine<br/>(durable execution)"]
    end
    STORE[("State Store<br/>Redis")]

    App -->|gRPC| Sidecar
    Sidecar -->|reads / writes history| STORE

The key idea is durable execution. Dapr records every step to a state store, so the workflow can be replayed from history at any time. A crash, a deployment, or a scale-out event doesn't lose progress, and a workflow can run for seconds or for months.

⚠️ One rule follows from this: workflow code must be deterministic. No DateTime.Now, no random values, no direct I/O. Anything non-deterministic goes into an activity. Even logging is affected, so inside a workflow you use context.CreateReplaySafeLogger<T>() instead of a normal logger, otherwise every replay repeats your log lines.

Under the hood, this all runs on Dapr actors, which is why the state store has to support actors. The good news is that the default local setup already handles this, as you'll see in a moment.

A Quick Note on ABP and Dapr

ABP already ships a set of Dapr integration packages: Volo.Abp.Dapr (the core package), Volo.Abp.EventBus.Dapr and Volo.Abp.AspNetCore.Mvc.Dapr.EventBus (distributed event bus over Dapr pub/sub), Volo.Abp.Http.Client.Dapr (service invocation), and Volo.Abp.DistributedLocking.Dapr (distributed locking). You can read all about them in the ABP Dapr integration documentation.

These cover pub/sub, service-to-service calls, and locking. Workflows are not part of ABP's Dapr integration , and that's fine. Dapr Workflow has its own first-class .NET SDK (Dapr.Workflow), and you plug it straight into your ABP app like any other .NET library. So in this article we use the Dapr SDK directly, inside an ABP startup template.

Note: If you'd like to see deeper Dapr integration in ABP, or you'd like us to build a dedicated piece around Dapr Workflow, feel free to open a new issue on the ABP GitHub repository. Telling us what you need is the best way to help us prioritize it.

What We'll Build

To keep this concrete, we'll build a small order processing workflow, the classic example for this kind of thing.

The workflow takes an order, checks inventory, charges the customer, then notifies them. If the item is out of stock, it stops early and returns a rejected result. Nothing fancy on the business side, but it's enough to show the parts that matter: how a workflow chains activities, how state survives across steps, and how you start and track an instance.

Here's the flow we're aiming for:

An order comes in with a product, a quantity, and a price
Check inventory : if there isn't enough stock, reject the order and stop
Process payment : charge the customer
Notify the customer : let them know the order went through
Return a final result

Each of those steps will be an activity , and the workflow is the code that orchestrates them. Let's set up the project and build it.

Prerequisites

Before we start, make sure you have these installed:

.NET 10 SDK
ABP CLI (the current Studio CLI). Install it with dotnet tool install -g Volo.Abp.Studio.Cli (or update with dotnet tool update -g Volo.Abp.Studio.Cli)
Docker , running on your machine
Dapr CLI , initialized once with dapr init

That last step matters. When you run dapr init in self-hosted mode, Dapr pulls a few containers (including Redis) and writes a default statestore.yaml component. That default state store already has actorStateStore: "true" set, which is exactly what Dapr Workflow needs. So once dapr init finishes, you can run workflows locally with zero extra configuration.

Pro Tip: If you ever swap the default Redis store for your own component, double-check that it sets actorStateStore: "true". Without it, workflows silently fail to start, and it's the line people forget most often.

Create the Project

In this article I'll create a new layered solution with EF Core as the database provider, using the ABP CLI.

If you already have an ABP project, you don't need a new one. You can apply the following steps to your existing solution and skip this section.

Create a new solution named DaprWorkflowDemo (or whatever you want):

abp new DaprWorkflowDemo

Once the download finishes, your project boilerplate is ready. Open the solution in your IDE and run the DaprWorkflowDemo.Web project once to confirm the app starts and the UI works.

Since, we have created the solution via ABP Studio CLI, it automatically runs the initial-tasks, which init database, seed initial data and run abp install-libs command, so, no need run the *DbMigrator project.

Default admin username is admin and the password is 1q2w3E *. You can use these credentials to login...

We'll do all the workflow work inside the DaprWorkflowDemo.Web project, since that's the running host where the workflow engine connects to the sidecar.

Install the Dapr.Workflow Package

Open a terminal in the DaprWorkflowDemo.Web project folder and add the package:

dotnet add package Dapr.Workflow

-> This single package gives you everything: the base Workflow<TInput, TOutput> and WorkflowActivity<TInput, TOutput> types, the AddDaprWorkflow registration helper, and the DaprWorkflowClient you use to start and query workflows from code.

Define the Workflow and Its Activities

Now let's write the order processing flow we sketched out earlier.

First, create a Workflows folder in the DaprWorkflowDemo.Web project. We'll keep everything there for simplicity.

Every input and output in a workflow gets serialized to the state store, so the types you pass around should be simple, JSON-friendly records ( ensure they are serializable! ). Let's define them:

namespace DaprWorkflowDemo.Web.Workflows;

public record OrderPayload(string OrderId, string ProductName, int Quantity, decimal TotalPrice);

public record InventoryResult(bool InStock);

public record OrderResult(string OrderId, string Status);

Now the workflow itself. A workflow derives from Workflow<TInput, TOutput> and reads top to bottom like a normal method, even though every step is durably persisted:

using Dapr.Workflow;
using Microsoft.Extensions.Logging;
using System.Threading.Tasks;

namespace DaprWorkflowDemo.Web.Workflows;

public class OrderProcessingWorkflow : Workflow<OrderPayload, OrderResult>
{
    public override async Task<OrderResult> RunAsync(WorkflowContext context, OrderPayload order)
    {
        var logger = context.CreateReplaySafeLogger<OrderProcessingWorkflow>();
        logger.LogInformation("Starting order {OrderId}: {Quantity} x {ProductName}",
            order.OrderId, order.Quantity, order.ProductName);

        // 1. Check inventory
        var inventory = await context.CallActivityAsync<InventoryResult>(
            nameof(CheckInventoryActivity), order);

        if (!inventory.InStock)
        {
            logger.LogWarning("Order {OrderId} rejected: out of stock", order.OrderId);
            return new OrderResult(order.OrderId, "Rejected: out of stock");
        }

        // 2. Process the payment
        await context.CallActivityAsync(nameof(ProcessPaymentActivity), order);

        // 3. Notify the customer
        await context.CallActivityAsync(nameof(NotifyCustomerActivity), order);

        logger.LogInformation("Order {OrderId} completed", order.OrderId);
        return new OrderResult(order.OrderId, "Completed");
    }
}

A couple of things worth pointing out here.

CallActivityAsync does not invoke the activity directly. It schedules the work with the workflow engine, which records the result once the activity completes. If the process dies right after the payment step, Dapr replays the workflow, feeds it the already-recorded results for the completed steps, and resumes at the notification step. The customer never gets charged twice. This is the task chaining pattern.
Notice the replay-safe logger too. Because the engine replays the workflow to rebuild its state, a normal logger would print the same lines over and over. context.CreateReplaySafeLogger<T>() logs only on the first real pass.
Now the activities. An activity is where the real work happens, and the only place you're allowed to be non-deterministic. It derives from WorkflowActivity<TInput, TOutput> and supports constructor injection, so you can pull in your ABP services, repositories, or any registered dependency:

using Dapr.Workflow;
using Microsoft.Extensions.Logging;
using System.Threading.Tasks;

namespace DaprWorkflowDemo.Web.Workflows;

public class CheckInventoryActivity : WorkflowActivity<OrderPayload, InventoryResult>
{
    private readonly ILogger<CheckInventoryActivity> _logger;

    public CheckInventoryActivity(ILogger<CheckInventoryActivity> logger)
    {
        _logger = logger;
    }

    public override Task<InventoryResult> RunAsync(WorkflowActivityContext context, OrderPayload order)
    {
        _logger.LogInformation("Checking inventory for {ProductName}", order.ProductName);

        // Pretend we queried a stock service or a repository here.
        var inStock = order.Quantity <= 100;

        return Task.FromResult(new InventoryResult(inStock));
    }
}

public class ProcessPaymentActivity : WorkflowActivity<OrderPayload, object?>
{
    private readonly ILogger<ProcessPaymentActivity> _logger;

    public ProcessPaymentActivity(ILogger<ProcessPaymentActivity> logger)
    {
        _logger = logger;
    }

    public override Task<object?> RunAsync(WorkflowActivityContext context, OrderPayload order)
    {
        _logger.LogInformation("Charging {TotalPrice:C} for order {OrderId}",
            order.TotalPrice, order.OrderId);

        // Call your real payment provider here.
        return Task.FromResult<object?>(null);
    }
}

public class NotifyCustomerActivity : WorkflowActivity<OrderPayload, object?>
{
    private readonly ILogger<NotifyCustomerActivity> _logger;

    public NotifyCustomerActivity(ILogger<NotifyCustomerActivity> logger)
    {
        _logger = logger;
    }

    public override Task<object?> RunAsync(WorkflowActivityContext context, OrderPayload order)
    {
        _logger.LogInformation("Notifying customer about order {OrderId}", order.OrderId);

        // Send an email, push a notification, publish an event, etc.
        return Task.FromResult<object?>(null);
    }
}

Each activity is isolated, so Dapr can retry a failed one without re-running the whole workflow. The two activities that don't return anything useful use object? as their output type and return null. That's why the workflow calls them with the non-generic CallActivityAsync, which ignores the result.

Here's the shape of the process we just wrote:

flowchart TD
    A["Start workflow<br/>(OrderPayload)"] --> B["CheckInventoryActivity"]
    B -->|In stock| C["ProcessPaymentActivity"]
    B -->|Out of stock| R["Return: Rejected"]
    C --> D["NotifyCustomerActivity"]
    D --> E["Return: Completed"]

Register the Workflow

Workflows and activities need to be registered so the engine knows about them. Open your DaprWorkflowDemoWebModule class and register them in ConfigureServices. Most of the existing code is abbreviated for simplicity:

using DaprWorkflowDemo.Web.Workflows;
using Dapr.Workflow;

public override void ConfigureServices(ServiceConfigurationContext context)
{
    var hostingEnvironment = context.Services.GetHostingEnvironment();
    var configuration = context.Services.GetConfiguration();

    // ... existing ABP configuration ...

    //Configure Dapr Workflows...
    context.Services.AddDaprWorkflow(options =>
    {
        options.RegisterWorkflow<OrderProcessingWorkflow>();

        options.RegisterActivity<CheckInventoryActivity>();
        options.RegisterActivity<ProcessPaymentActivity>();
        options.RegisterActivity<NotifyCustomerActivity>();
    });
}

AddDaprWorkflow does two things for us. It registers a background worker that connects to the sidecar's workflow engine and hosts your workflow definitions, and it registers a DaprWorkflowClient in the dependency injection container so you can start and query workflows from your own code later.

That's all the wiring. There's no component YAML to write, because Dapr ships a built-in workflow component named dapr that runs on top of the actor state store we already have.

Run It With the Dapr Sidecar

Here's the part that's different from a normal dotnet run. The workflow engine lives in the Dapr sidecar, so the app has to run alongside a sidecar. The Dapr CLI handles that for us.

In this section, I assume that you already run dapr init command before, as explained above. If you haven't run it yet, please first run it and then follow the instructions/commands below.

First, make sure your database is migrated (run DaprWorkflowDemo.DbMigrator if you haven't). Then, from the DaprWorkflowDemo.Web project folder, start the app with Dapr:

dapr run --app-id dapr-workflow-demo --dapr-http-port 3500 -- dotnet run

A few notes on this command:

--app-id is the identity of your app within Dapr. We'll use it nowhere else in this example, but Dapr needs it.
--dapr-http-port 3500 pins the sidecar's HTTP port so we know where to send requests. You can leave it out and let Dapr pick one, but pinning it keeps the next step simple.
Everything after -- is the command Dapr runs for your app. dapr run injects the sidecar's connection details (like the gRPC port) as environment variables, and the Dapr.Workflow worker reads them automatically to connect to the engine.

Notice we don't pass --app-port here. That flag is only needed when Dapr has to call into your app (for pub/sub or service invocation). For workflows, your app connects out to the sidecar over gRPC, so we don't need it for this scenario.

Once it's running, you'll see both the ABP app logs and the Dapr sidecar logs in the same terminal.

Does It Actually Work?

The quickest way to test is to talk to the sidecar's Workflow management HTTP API directly. This hits Dapr, not your app, which makes it a clean smoke test with no extra endpoint code.

Start a workflow instance. The component name is dapr (the built-in one), the workflow name is the class name, and we pass our own instance ID so it's easy to query:

curl -i -X POST "http://localhost:3500/v1.0/workflows/dapr/OrderProcessingWorkflow/start?instanceID=order-001" \
  -H "Content-Type: application/json" \
  -d '{"OrderId":"order-001","ProductName":"Mechanical Keyboard","Quantity":2,"TotalPrice":59.90}'

The request body is the workflow input, and Dapr passes it straight through to your OrderPayload. You should get a 202 Accepted back with the instance ID:

{ "instanceID": "order-001" }

Now query the status of that instance:

curl "http://localhost:3500/v1.0/workflows/dapr/order-001"

After the workflow finishes, you'll see a COMPLETED status along with the serialized output:

{
  "instanceID": "order-001",
  "workflowName": "OrderProcessingWorkflow",
  "createdAt": "2026-06-29T15:30:15.038490Z",
  "lastUpdatedAt": "2026-06-29T15:30:15.360885500Z",
  "runtimeStatus": "COMPLETED",
  "properties": {
    "dapr.workflow.input": "{\"ProductName\":\"Mechanical Keyboard\",\"Quantity\":2,\"OrderId\":\"order-001\",\"TotalPrice\":59.9}",
    "dapr.workflow.output": "{\"orderId\":\"order-001\",\"status\":\"Completed\"}"
  }
}

If you check the terminal, you'll also see the log lines from the workflow and each activity in order:

The same management API also lets you terminate, pause, resume, and purge instances, and raiseEvent to send external events into a waiting workflow. For example:

# Permanently delete a finished workflow's state
curl -X POST "http://localhost:3500/v1.0/workflows/dapr/order-001/purge"

The DaprWorkflowClient exposes the same operations in code (terminating, suspending and resuming, purging, and raising external events on an instance), which is the way to go for anything beyond a quick manual test.

Triggering Workflows From Your ABP Code

Hitting the sidecar API by hand is great for a quick check, but in a real app you'll start workflows from your own code, and this is the recommended path. That's what the DaprWorkflowClient is for, and AddDaprWorkflow already registered it for you.

You can inject it anywhere, for example into a controller or an application service. Here's a minimal controller in the DaprWorkflowDemo.Web project that starts an order and reads its status:

using System.Threading.Tasks;
using DaprWorkflowDemo.Web.Workflows;
using Dapr.Workflow;
using Microsoft.AspNetCore.Mvc;

namespace DaprWorkflowDemo.Web.Controllers;

[ApiController]
[Route("api/orders")]
public class OrderController : ControllerBase
{
    private readonly DaprWorkflowClient _workflowClient;

    public OrderController(DaprWorkflowClient workflowClient)
    {
        _workflowClient = workflowClient;
    }

    [HttpPost]
    public async Task<IActionResult> StartAsync(OrderPayload order)
    {
        var instanceId = await _workflowClient.ScheduleNewWorkflowAsync(
            name: nameof(OrderProcessingWorkflow),
            instanceId: order.OrderId,
            input: order);

        return Accepted($"/api/orders/{instanceId}", new { instanceId });
    }

    [HttpGet("{instanceId}")]
    public async Task<IActionResult> GetStatusAsync(string instanceId)
    {
        var state = await _workflowClient.GetWorkflowStateAsync(instanceId);

        if (state is null || !state.Exists)
        {
            return NotFound();
        }

        return Ok(new
        {
            RuntimeStatus = state.RuntimeStatus.ToString(),
            Output = state.ReadOutputAs<OrderResult>()
        });
    }
}

ScheduleNewWorkflowAsync returns immediately and the workflow runs in the background, so this fits the asynchronous request pattern nicely: return 202 Accepted and let the client poll the status endpoint.

One ABP-specific thing to keep in mind: ABP enforces antiforgery validation for unsafe HTTP methods on cookie-authenticated requests. Server-to-server or curl calls without an auth cookie usually pass straight through, but if you call the POST endpoint from a logged-in browser session and get a 400 antiforgery error, you can relax the auto validation for this controller through AbpAntiForgeryOptions, the same way the Elsa articles did for the Elsa endpoints.

Going Further

We built a simple linear flow, but Dapr Workflow supports the patterns you'll actually need in production, all in plain C#:

Fan-out / fan-in : schedule many activities in parallel and aggregate the results (it's just Select plus Task.WhenAll).
External events : pause a workflow until a human approves something or another system calls back. This is great for approval flows.
Timers : durably wait for minutes, days, or months without holding a thread.
Child workflows : break a big process into smaller workflows with their own history and status.
Retry policies : give an activity an exponential backoff policy so transient failures recover on their own.

Conclusion

Dapr Workflow gives you durable execution for long-running processes without bolting a heavy orchestration engine into your code. The process is plain C# that reads top to bottom, Dapr makes it fault-tolerant by replaying from the state store, and the orchestration stays deterministic while the side effects live in activities.

The nice part for us is that none of this fights with ABP. You create a normal ABP solution, add the Dapr.Workflow package, register your workflows in a module, and run with dapr run. ABP's own Dapr packages still cover pub/sub, service invocation, and locking, so you can mix all of these in the same solution when you need them.

All the code in this article is self-contained, so you can copy it into a fresh ABP project and follow along from top to bottom.

Thanks for reading, see you in the next one!

Customizing the ABP Framework: A Developer's Guide to LeptonX Theme Overrides in Angular and the Transition to React UI

ABP.IO — Mon, 29 Jun 2026 05:59:05 +0000

Customizing the ABP Framework: A Developer's Guide to LeptonX Theme Overrides in Angular and the Transition to React UI

Enterprise ASP.NET Boilerplate (ABP) projects rarely stay with default theme behavior for long. At some point, teams need stricter brand alignment, user experience (UX) consistency across modules, or product-specific shell behavior that goes beyond palette and typography tweaks.

This article explains a practical way to customize the LeptonX theme in Angular projects through two primary layers :

Style Overriding: Utilizing design tokens, global CSS custom properties (variables), and component-level styling.
Element Overriding: Replacing or extending UI fragments and layout pieces using ABP's built-in services.

Finally, we connect this customization mindset to ABP’s new React direction, where application development teams own more of the user interface (UI) implementation directly from day one.

Why Overriding Matters in Real ABP Solutions

In enterprise software engineering, frontend customization is not a cosmetic task. Instead, it directly supports core technical and architectural goals :

Brand System Compliance: Enforcing strict color palettes, layouts, and typography across tenant-facing portals and internal back-office administration pages.
Accessibility (a11y) Improvements: Optimizing focus states, color contrast ratios, screen reader compatibility, and keyboard navigation to meet WCAG standards.
Product Differentiation: Structuring distinct top-level layouts, sidebar behavior, and navigation elements to separate multiple products within the same suite.
Operational Usability: Reorganizing application spaces to match domain-specific workflows and simplify intensive data-entry tasks.

To avoid building fragile CSS overrides that break during framework updates, development teams must follow a strict, highly structured hierarchy of customization :

Adhering to this hierarchy reduces "style debt" and ensures that theme upgrades remain manageable throughout the application lifecycle.

Layer 1: Style Overriding in LeptonX (Angular)

Style overriding is the safest and most maintainable way to alter your application's presentation layer. The LeptonX engine relies heavily on CSS custom properties (variables) defined at the :root level.

Customizing Brand Colors and Typography Tokens

To modify the default colors and branding assets, developers can define custom properties within the global src/styles.scss file :

:root {
  /* Set the primary brand color used on active elements, buttons, and focuses */
  --lpx-brand: #1e3a8a;

  /* Set the physical paths for the application logos */
  --lpx-logo: url('/assets/images/logo.png');
  --lpx-logo-icon: url('/assets/images/logo-icon.png'); /* Displayed when sidebar is collapsed */
}

For applications utilizing multi-theme layouts (such as LeptonX Pro's Light, Dark, or Dim modes), variables can be scoped under individual theme classes to dynamically swap brand colors or assets :

/* Scoping theme-specific logos to prevent visibility issues on dark backgrounds */
:root.lpx-theme-dark, :root.lpx-theme-dim {
  --lpx-logo: url('/assets/images/logo-light.png');
  --lpx-logo-icon: url('/assets/images/logo-icon-light.png');
}

Solving the "Visual Branding Blink" on Initial Page Load

A common issue in production occurs when the default LeptonX logo is briefly displayed on screen before the client browser parses the custom stylesheet. This latency creates a noticeable "blink" or flicker.

To eliminate this rendering gap, bypass the CSS variable load phase by replacing the physical logo assets inside the web host project's public directory. Write your custom branding files directly to /images/logo/leptonx/logo-light.png inside the server's public folder. Because the fallback variable defaults directly to this location, the client browser displays the custom logo asset immediately without waiting to parse the custom CSS rules.

Additionally, note that styles registered solely in the application's global styles.scss may fail to apply to the Account Layout (such as the standard login page) because it compiles within an isolated module lifecycle. To ensure your styling overrides apply globally, register the assets and styles in the Virtual File System (VFS) of the.NET backend host, making them universally accessible across all client routing contexts.

Layer 2: Element Overriding in LeptonX (Angular)

When CSS modifications cannot support your required user experience (such as adding search interfaces, custom profile controls, or custom action layouts), teams must override the underlying UI elements.

ABP provides the ReplaceableComponentsService to dynamically replace pre-built layout pieces with custom, project-owned Angular components without breaking core module logic.

Troubleshooting the Mobile User Profile Freeze

In compiled editions of the LeptonX Lite layout library (specifically versions 3.1.x through 4.3.1), developers have identified a rendering bug affecting mobile layouts. When a user logs in via a mobile device and taps the profile dropdown menu, the page freezes. Instead of displaying the profile options, the sidebar area recursively renders a duplicate copy of the active route page. This layout loop completely breaks navigation until the page is refreshed.

The root cause is a layout bug inside the compiled LeptonX library template (mn-user-profile.component.html), where the template markup is wrapped inside an <ng-component> tag instead of a structurally neutral <ng-container> tag.

To resolve this issue, you can implement a custom component replacement :

Generate a custom mobile profile component using the Angular CLI
Implement the component template, ensuring the wrapper elements utilize <ng-container> instead of <ng-component>.
Inject the ReplaceableComponentsService into your root app.component.ts to swap the underlying component keys during application bootstrap :

Template Context: From LeptonX Demo Setup to Real ABP Application Templates

When transitioning customized designs from local prototypes to production environments, development teams must choose between two operating modes :

| Operational Mode | Core Architecture | Rationale & Trade-offs | | --- | --- | --- | | Standard Template Mode | Consumes LeptonX packages as standard dependencies (@abp/ng.theme.lepton-x) from npm registries. All overrides are applied at the application layer. | Highly Recommended. Keeps local project codebases clean, simplifies dependency updates, and avoids style debt. | | Source-Inspection Mode | Utilizes the ABP CLI get-source command to download the raw theme code and configure temporary local path aliases. | Diagnostic Only. Best used for deep debugging, prototyping layout behaviors, or tracing framework-level bugs. |

Resolving Strict MIME Type CSS Loading Exceptions

During local development or initial production deployments of LeptonX Lite Angular applications, browsers may refuse to apply the theme's styles. This issue manifests as a console exception:

Refused to apply style from 'http://localhost:4200/bootstrap-dim.css' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.

This error occurs when the browser requests static layout stylesheets from paths that do not exist, causing the back-end host to return a default 404 HTML fallback page. To resolve this, run the installation command in your client-side workspace :

abp install-libs

This command forces the ABP CLI to parse package dependencies, copy the compiled stylesheets directly into the physical output directories, and make them available to the web server.

Deep Implementation: Integrating Theme Source Code and the Upgrade Trade-Off

For complex enterprise scenarios requiring structural changes that cannot be achieved via standard token configurations or component replacements, developers have the option to bypass compiled packages entirely and integrate the theme’s raw source code.

How to Retrieve the Source Code

ABP Commercial customers have full access to the complete source code of the LeptonX Pro theme. This can be downloaded directly through the ABP Suite user interface or by executing the following command in the ABP CLI within your project directory :

abp get-source Volo.Abp.LeptonXTheme

This command downloads the raw C# and Angular source files directly into your local solution structure. Once downloaded, you can modify the underlying HTML templates, restructure Angular modules, and alter core layout scripts to meet your product requirements.

The Upgrade Warning: Maintenance Overhead and Style Debt

While direct access to the source code provides complete design freedom, it comes with a major warning regarding long-term maintenance :

Bypassing the Update Stream: Once you replace official package references (such as @volosoft/abp.ng.theme.lepton-x or NuGet packages) with local project references, your application is disconnected from the automatic update pipeline.
Manual Merge Burden: When Volosoft releases framework updates, security patches, or compatibility fixes (such as aligning with newer Angular or.NET compiler baselines), these updates will not automatically apply to your customized code. Your team must manually compare, diff, and merge upstream changes, which can introduce regressions and increase technical debt.
VFS and APIs as the First Line of Defense: Before choosing a full source code integration, try using the Virtual File System (VFS) on the backend or standard component replacement APIs in the frontend to override only the specific elements you need to change. This allows you to customize the UI while keeping the rest of your theme packages fully upgradeable.

Connecting the Mindset to ABP’s New React Era

The introduction of the React UI option in ABP 10.4 represents a major architectural shift. While the Angular implementation relies on structured layout packages and runtime component overrides, the React architecture prioritizes direct developer ownership of the presentation layer.

graph TD
    %% Styling
    classDef react fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px,color:#0d47a1;
    classDef dotnet fill:#f3e5f5,stroke:#8e24aa,stroke-width:2px,color:#4a148c;
    classDef proxy fill:#fff3e0,stroke:#fb8c00,stroke-width:2px,color:#e65100;
    classDef tool fill:#f5f5f5,stroke:#757575,color:#333;

    %% React App Box
    subgraph ReactApp ["React App Repository"]
        C1["Custom Business Components<br><small>(Local Source Code)</small>"]:::react
        C2["TanStack Router & Query<br><small>(Type-Safe Client Routes)</small>"]:::react

        T1["Vite Dev Server & Bundling<br><small>(Fast HMR, Vitest)</small>"]:::tool
        T2["Tailwind CSS / shadcn/ui<br><small>(Accessible UI Components)</small>"]:::tool

        C1 --> C2
        T1 --> T2
    end

    %% Backend Box
    subgraph NetCore ["ASP.NET Core Web API Host"]
        P1["Dynamic API Client Proxies<br><small>(Auto-Generated Endpoints)</small>"]:::proxy
        A1["ABP Admin Console<br><small>(Delivered via NuGet)</small>"]:::dotnet

        P1 <==> A1
    end

    %% Inter-Repository Flow
    ReactApp -- "Generates Dynamic Proxies" --> P1

    %% Layout Tweaks
    style ReactApp fill:#fafafa,stroke:#1e88e5,stroke-width:1px,stroke-dasharray: 5 5;
    style NetCore fill:#fafafa,stroke:#8e24aa,stroke-width:1px,stroke-dasharray: 5 5;

What Stays Consistent vs. What Changes

Understanding how patterns transfer between frameworks is key for teams migrating to the React UI:

What Stays Consistent: Core DDD infrastructure, backend integration, dynamic API proxy generation, multi-tenancy models, and permission-aware routing configurations.
What Changes: Direct ownership of page layouts, faster iteration of UI composition, and modern utility-first styling tools.

A New Frontend Philosophy

In the Angular model, developers import pre-built layouts from compiled packages and selectively override elements using classes or replacing components. While structured, this approach can sometimes feel like "fighting" the framework.

The React UI model, by contrast, gives developers direct control over the UI components from day one. Standard administrative pages (such as Identity, Tenants, and Settings) are managed separately by the ABP Admin Console on the back-end host, while all application layouts and views remain locally in your React project.

Built with modern tools like Vite , Tailwind CSS , and shadcn/ui , developers can customize and extend components directly in their local source files without needing complex overriding wrappers.

Additionally, because the layout and page templates reside in local source directories rather than compiled packages, this architecture is highly optimized for AI-driven development. Automated coding agents (such as the ABP Studio AI Agent) can easily inspect and modify local layouts, run API proxy generation, and deploy updates quickly.

Whether your enterprise solution leverages the structured, component-driven architecture of ABP's Angular UI or is stepping into the modern, developer-owned era of the Vite-powered React UI , establishing an intentional, upgrade-safe customization strategy is crucial. By resolving design changes through token-level custom properties first, documenting structural element overrides, and preparing public-facing technical resources to be highly citable by conversational search agents , development teams can insulate their codebases from technical debt. Ultimately, the transition from rigid theme packages to direct frontend ownership not only streamlines day-to-day software delivery but also ensures that your application framework remains flexible, performant, and visible in an AI-driven ecosystem.

AI Isn’t Replacing Developers — It’s Changing What Good Developers Spend Time On

ABP.IO — Thu, 25 Jun 2026 07:37:37 +0000

A lot of the current AI discussion in software development swings between two extremes: either AI will write everything, or it is just autocomplete with better marketing.

Neither view is especially useful.

What the evidence shows is more practical: AI coding tools can improve developer throughput on certain tasks, especially repetitive work, scaffolding, and first drafts. But they do not remove the need for developers. In many teams, they actually create a new category of work around review, verification, security, and long-term maintainability.

That is the real story. AI is not replacing developers. It is changing what developers do, what teams optimize for, and where engineering judgment matters most.

The productivity gains are real, but they are not magic

There is enough data now to move beyond hot takes.

Across multiple studies and industry reports, AI coding assistants show measurable productivity gains, but those gains are usually modest rather than transformational:

A BlueOptima analysis across 30,000 developers in 18 enterprises reported an average productivity uplift of 5.4%, with the most active users seeing gains closer to 20%.
An open source study found roughly a 6.5% project-level productivity increase after Copilot adoption.
GitHub survey data from more than 2,000 developers showed strong perceived benefits: improved flow, less mental drain on repetitive tasks, and greater job satisfaction.
A longitudinal study from a large public-sector engineering organization found that developers using Copilot were already highly active, and while they reported productivity improvements, commit-based metrics did not show a statistically significant post-adoption jump.

That last point matters.

Perceived productivity and actual output are not always the same thing. Developers may feel faster because they spend less time on boilerplate, search, or syntax recall. That feeling is valuable. Less friction often means better focus. But it does not automatically translate into dramatically more shipped business value.

In other words, AI helps, but it does not suspend the usual constraints of software delivery:

unclear requirements still slow teams down
poor architecture still creates drag
bad testing practices still leak defects
messy codebases are still messy codebases

If your delivery bottleneck is typing, AI looks revolutionary. If your bottleneck is product ambiguity, compliance, integration complexity, or production risk, AI helps less than the marketing suggests.

What AI coding tools are actually good at

The strongest use case for AI in development is not autonomous software engineering. It is acceleration of narrow, well-bounded tasks.

AI coding assistants are usually good at:

generating boilerplate
filling in repetitive CRUD patterns
writing simple tests and test skeletons
suggesting refactors
producing documentation drafts
translating between languages or frameworks
helping developers recall APIs and syntax
creating a first pass for routine utility code

This is why many developers genuinely like these tools. They reduce low-value friction.

A practical example:

A developer building an ABP-based application might use AI to:

scaffold DTO mappings
draft validation rules
generate basic unit test cases
create repository query examples
summarize a service class before refactoring

Those are useful accelerators. But the same tool is much less reliable when asked to decide:

whether a module boundary is correct
how to model a permission system
what tradeoff to make between consistency and performance
how multi-tenancy affects data access rules
which abstraction will still be maintainable a year later

That is the dividing line. AI handles local code generation better than system-level reasoning.

Where developers are still irreplaceable

The most valuable parts of software development were never just typing code.

Developers are still responsible for the parts AI consistently struggles with:

Understanding the problem behind the ticket

Business requirements are often incomplete, contradictory, or politically constrained. A human developer can ask the uncomfortable question, spot hidden assumptions, and translate vague intent into a workable implementation.

AI can generate an answer. It cannot reliably challenge the question.

Making architecture tradeoffs

Real systems involve tradeoffs, not ideal answers.

Should this feature live in an existing module or a new service? Is eventual consistency acceptable here? Are we optimizing for onboarding speed, runtime performance, auditability, or cost control?

These decisions depend on context that usually lives outside the prompt window.

Working safely in large, imperfect codebases

Most production systems are not greenfield demos. They include legacy code, weird integrations, undocumented conventions, and historical constraints.

This is where experienced developers earn their keep. They know that the technically correct change is not always the operationally safe change.

Taking responsibility for outcomes

An AI assistant does not get paged at 2 a.m. It does not own the incident review. It does not explain a data leak to legal, security, or customers.

Software engineering is not just generation. It is accountability.

The hidden cost: verification debt

One of the most important ideas in the current AI coding debate is verification debt.

AI can generate code quickly, but that speed often shifts effort downstream. Instead of spending time writing code, teams spend time validating whether the generated code is correct, secure, idiomatic, and maintainable.

That creates a new form of debt:

code is produced faster than it is reviewed properly
weak suggestions slip into the codebase because they look plausible
reviewers must inspect more generated code with lower trust
maintenance costs rise later because low-context code ages badly

Recent survey data points in the same direction:

72% of developers reported using AI tools daily
AI contributes a substantial share of committed code in some teams
96% of developers do not fully trust AI-generated code
less than half consistently review AI-generated code before committing
38% say reviewing AI code can take longer than reviewing human-written code

That combination should worry engineering leaders.

If teams accept more machine-generated code while also trusting it less, the result is not full automation. The result is a fragile review pipeline.

This is why senior engineers are not becoming obsolete. Their work is shifting toward validation, standards, and system integrity.

Security is the clearest reason AI won’t replace developers

If you want one hard reality check, it is security.

AI-generated code often looks polished. That makes insecure output more dangerous, not less dangerous.

Research and industry testing have found recurring problems such as:

flawed input validation
weak authentication or authorization logic
unsafe serialization patterns
insecure defaults
cross-site scripting exposure
log injection issues
dependency and configuration mistakes

A Veracode study covering 100 LLMs across 80 coding tasks found that about 45% of AI-generated code samples contained security flaws. Reported failure rates were especially high in some languages and security-sensitive tasks.

That aligns with what many teams see in practice: AI can produce code that appears complete while quietly missing the exact defensive details that matter in production.

There is a second security problem too: the tools themselves.

Recent research into AI-enabled IDE workflows has highlighted risks such as:

prompt injection through project content
data exfiltration from workspace context
misuse of tool permissions
remote code execution paths via compromised assistant workflows

So the risk surface is now two-layered:

the generated code may be unsafe
the coding assistant environment may itself introduce supply-chain and data exposure risks

That is not a path to replacing developers. It is a path to needing more disciplined developers.

Why junior and senior developers benefit differently

AI does not help every developer in the same way.

Less experienced developers often benefit the most from:

faster onboarding
easier exploration of unfamiliar APIs
reduced time spent on repetitive syntax work
quick examples to unblock momentum

That is a good thing. Used well, AI can shorten the distance between "I know the concept" and "I can build the first version."

But there is a catch.

If juniors over-rely on generated solutions they do not understand, they can ship code without building judgment. That creates a team with higher output but thinner engineering depth.

Senior developers usually get less value from raw generation and more value from targeted acceleration. Their role shifts toward:

architectural direction
code review and design review
defining guardrails
mentoring developers on when not to trust the tool
shaping prompts and workflows around quality

That is not replacement. It is role redistribution.

The best teams treat AI like a power tool, not a developer

The most productive framing is simple: AI is a power tool.

A power tool can make a skilled worker much faster. It can also let an unskilled worker make bigger mistakes faster.

Teams getting real value from AI coding assistants usually do a few things consistently.

They define where AI is allowed to help

For example:

okay for scaffolding and test drafts
okay for documentation summaries
okay for refactoring suggestions in low-risk modules
not okay for auth flows without explicit review
not okay for security-sensitive changes without human design approval
not okay for direct commits to critical paths

They keep human review non-negotiable

AI-generated code should be reviewed like code from a new team member who is fast, confident, and occasionally wrong in subtle ways.

That means checking:

correctness
security
consistency with project conventions
operational impact
maintainability six months from now

They invest in guardrails

Useful guardrails include:

secure coding standards
mandatory tests for generated code
SAST and dependency scanning
branch protection and review policies
secret scanning
documented AI usage rules
prompt hygiene, especially around sensitive data

They optimize for maintainability, not just speed

The wrong metric is lines generated.

Better metrics include:

cycle time without increased incident rate
review burden
escaped defects
time to understand generated code later
security findings per change

When AI helps most — and when it helps least

A balanced view is more useful than either fear or hype.

When to use AI-assisted coding

AI is a strong fit when:

the task is repetitive or pattern-based
the scope is narrow and easy to verify
the code is low-risk and well-tested
you need a first draft, not a final answer
developers understand the output well enough to challenge it
the team has solid review and security practices

Examples:

generating DTOs, mappings, and validation stubs
producing test cases for straightforward services
drafting migration scripts that will be reviewed carefully
summarizing unfamiliar code before manual refactoring

When not to rely on AI-assisted coding

AI is a poor fit when:

business rules are complex or ambiguous
security is central to the change
architecture decisions are still in flux
the code touches compliance-heavy or highly regulated paths
the surrounding codebase has lots of undocumented behavior
the team is unlikely to review the output carefully

Examples:

permission and tenancy boundaries
payment or identity workflows
critical infrastructure automation
cross-service consistency logic
sensitive data handling and audit trails

What this means for the future of software teams

AI is changing software development, but not in the simplistic way people often describe.

The likely outcome is not fewer developers because code writes itself. The more plausible outcome is a different distribution of engineering work:

more generated code
more review and verification work
more emphasis on architecture and systems thinking
more value placed on security awareness
more leverage for developers who can guide tools effectively

There are also organizational effects.

If AI tools can remove some low-level friction, teams may ship faster. Some studies and industry analyses even project large macroeconomic gains from AI-augmented software work. But inside engineering organizations, those gains depend on whether speed is paired with discipline.

Without discipline, AI increases noise.

With discipline, AI increases leverage.

That is the distinction leaders should care about.

The developer job is not disappearing — it is getting more judgment-heavy

The strongest developers in the AI era will not be the ones who generate the most code. They will be the ones who can:

define the problem clearly
evaluate tradeoffs
spot incorrect assumptions
review machine output efficiently
protect quality under delivery pressure
turn generated fragments into coherent systems

That is a more senior version of software engineering, not a smaller one.

Typing code was never the whole profession. It was just the most visible part. AI is making that easier, which means the less visible parts now matter even more.

And those parts are deeply human: judgment, context, responsibility, and taste.

TL;DR

AI coding tools improve productivity on repetitive, bounded tasks, but the gains are usually incremental, not total automation.
Developers are still needed for architecture, business logic, tradeoffs, security, and accountability.
AI-generated code often adds verification debt, increasing review and maintenance work later.
Security remains a major limitation, both in generated code and in AI-assisted development workflows.
The winning teams use AI as a power tool with strong guardrails, not as a replacement for engineering judgment.

Deep Dive on ABP AI Agent: The Complete Series

ABP.IO — Tue, 23 Jun 2026 08:23:28 +0000

Deep Dive on ABP AI Agent: The Complete Series

ABP Studio is a development platform built around ABP Framework. With the introduction of ABP AI Coding Agent , it became something more: a platform where an AI agent works inside the same environment you already use to build, run, monitor, and ship ABP solutions.

General-purpose AI coding tools are excellent for horizontal, file-shaped work. They read source files, edit them, and run shell commands. But ABP solutions are system-shaped , not just file-shaped. A typical ABP solution is split across multiple modules and layers with strict dependency rules, composed of many runnable units (HTTP services, gateways, identity servers, background workers, Docker containers), and built on a strong set of conventions: aggregate roots, repositories, application services, DTOs, permissions, localization, event bus, distributed cache, and background jobs.

A generic agent has none of that vocabulary. It does not know what a module is, which project is the Domain layer, or that an ApplicationService should not depend on a DbContext directly. It cannot start your microservices, gateway, and auth server together. It cannot tell you that the latest edit caused a runtime exception in the Identity service, because it has no concept of a running application.

ABP AI Coding Agent was built to close exactly that gap. The agent is born inside a platform that already understands modules, run profiles, builds, migrations, proxies, Docker containers, monitoring, and Git workflows, and it uses every one of them.

We wrote a nine-part deep dive series to explain how each part of this system works, not as a product tour, but as a practical look at the decisions, controls, and architecture behind the experience.

The Series

Agent, Plan and Ask Modes — The three interaction modes that control how much action the agent is allowed to take: Ask for understanding (read-only), Plan for designing the approach before editing, and Agent for full implementation with builds, tools, and iteration.
Supported AI Models + Usage Recommendations — How ABP Studio separates models by role (main, research, browser, text processor, Git review) and why treating model selection as a practical decision based on the task leads to a better balance of capability, speed, and cost.
Rules, Skills and Lessons — The three mechanisms that give the agent solution-specific memory: Rules (always-on conventions), Skills (on-demand procedures), and Lessons (corrections the agent records and carries forward).
Integrated ABP Studio Tools — The tools that connect the agent to ABP Studio's runtime environment: monitoring (exceptions, logs, requests), applications, containers, tasks, and build actions, with a practical walkthrough showing the difference between debugging with and without tool access.
MCP (Model Context Protocol) — How MCP extends the agent beyond the solution boundary to reach external systems like Prometheus, SEO analyzers, or documentation services, with per-tool enable/disable controls and stdio/HTTP server support.
ABP Studio Git Integration — The full Git loop inside ABP Studio: branching, diffing, AI-generated commit messages, AI code review on staged changes, GitHub issue context for starting tasks, and pull request feedback for addressing reviewer comments.
Scopes — How AI Scopes restrict the agent's working area to specific modules, packages, or solution areas, reducing unrelated exploration, preventing accidental edits, and making diffs easier to review.
Parallel Agent Execution — Running multiple agent sessions at the same time, each with its own mode, model, scope, and workflow, plus read-only research subagents that fan out inside a single session.
Workflows — Repeatable before/after steps that wrap agent runs: start containers, build packages, add migrations, generate proxies, restart applications, and run validation tasks, so the agent focuses on the code change while the platform handles the deterministic parts.

The Bigger Picture

Each article focuses on one feature, but the real value comes from how they work together.

Modes decide how much action the agent takes. Models decide which brain handles the work. Rules, Skills, and Lessons shape what the agent knows. Tools and MCP extend what it can reach. Scopes define where it can work. Workflows define what happens around the work. Git Integration makes the result reviewable and recoverable. Parallel Execution lets multiple tasks move forward at the same time.

That is the ABP AI Coding Agent experience: not a single AI button, but a set of controls built into a platform that already understands how ABP solutions are developed, run, and maintained.

DEV Community: ABP.IO

ABP.IO Platform 10.6 Final Has Been Released!

ABP.IO Platform 10.6 Final Has Been Released!

What's New With Version 10.6?

Getting Started with 10.6

How to Upgrade an Existing Solution

Upgrading via ABP Studio

Upgrading via ABP CLI

Migration Guides

Community News

New ABP Community Articles

About the Next Version

Event Recap - WeAreDevelopers World Congress 2026

Great Conversations and Product Demos

Sharing Our Experience on Stage

More Than Just a Conference

Meeting The Developer Community

Until Next Time

Building a Vendor Onboarding Workflow with ABP Low-Code

Building a Vendor Onboarding Workflow with ABP Low-Code

What We Are Building

A Quick Note on How Low-Code Fits Together

Add a Code-Defined Review Template

Create the Vendor Enums

Create the VendorApplication Entity

Generate a Grid Page

Build the Create/Edit Form

Apply the Migration Before Opening the Runtime

Try It in the React Runtime

Add a Custom Summary Endpoint

Add One Runtime Model

Read the Same Data from ABP Code

Going Further

Conclusion

Further Reading

Introducing ABP Low-Code: Build Real ABP Apps in Minutes

Introducing ABP Low-Code: Build Real ABP Apps in Minutes

ABP Low-Code at a glance

Built into the ABP Platform

Edit at runtime. See it in the app.

CRUD is table stakes

One model, multiple operational screens

When low-code needs code

From code-first entity to generated page

Low-code data stays reachable from C

Why ABP Low-Code matters

Try it yourself

Further reading

ABP Platform 10.6 RC Has Been Released

ABP Platform 10.6 RC Has Been Released

Get Started with the 10.6 RC

Migration Guide

What's New with ABP v10.6?

Background Jobs: Dedicated Workers, Parallel Execution, and Successful Job Retention

API Definition and Proxy Improvements for Content Types and Multipart Uploads

Angular UI: Upgrade to Angular 22

Antiforgery and OpenIddict Security Improvements

OpenIddict: Generate Access Token from the UI

Dependency Updates

Other Improvements and Enhancements

Community News

New ABP Community Articles

ABP Summer Campaign: Get Up To 20% Off + $300 in AI Credits

Conclusion

ABP 10.5.0 Expands Blazor UI Options with MudBlazor Support

ABP 10.5.0 Expands Blazor UI Options with MudBlazor Support

Why add another Blazor UI library?

Who should consider MudBlazor?

What the MudBlazor option covers

Framework core

Three themes

Module coverage

Component mapping at a glance

Supported Blazor project types

ABP Suite

Choosing between Blazorise and MudBlazor

Creating a MudBlazor project in ABP Studio

ABP Studio (recommended)

CLI

Try it out