If you build ISV solutions for Acumatica, there is a new rule in the technical validation for versions 2026 R1 and above:

If your solution ships a workflow change that was built in the Customization Project Editor, expect to see this in your validation report. This article covers what the rule means, the ways to customize workflows, why Acumatica is restricting the UI approach for ISVs, and what to do instead.

A Quick Refresher: How Workflows Can Be Customized

A workflow describes how the state of a record changes as users work on a form. It is a state machine: states, transitions between them, actions that trigger the transitions, conditions, and field and action properties that depend on the current state. Acumatica gives you several ways to customize one.

Workflow editor in the Customization Project Editor (UI). You open a screen's workflow in the customization project, add actions, states, transitions or conditions visually, and save the result. The change is stored as part of the customization project and applied to the screen configuration when the project is published. No C# is required. This is aimed at customizers and VARs tailoring one specific instance.

Workflow API (code). The same building blocks are defined in C# through the Workflow API, usually in a graph extension that overrides Configure and updates the screen configuration. Code can add an action to a predefined workflow, update a composite state, add a workflow for a value of the workflow-identifying field, or define an entirely new workflow for a custom form. The Acumatica T270 Workflow API course walks through each of these.

Automation steps (legacy). The older approach, which Workflow API supersedes. Workflows are easier to modify than automation steps, and customizations of a default workflow can still be applied when it is updated, unless they introduce breaking changes.

A useful detail is that a workflow built in code can still be viewed and tweaked in the Customization Project Editor. Code and UI are designed to layer on top of each other.

What the New Rule Says

For 2026 R1 and above, the technical validation flags UI-based workflow customization inside an ISV solution. The recommendation reads:

Solutions that already contain UI workflow customizations, such as custom actions on a sales order or purchase order screen, may be granted a waiver for the current validation. Treat that as a grace period, not permission.

Why: Collisions

The key phrase is only one such customization per screen would apply.

A workflow customization made through the UI is applied at the screen level, and the system accepts only one UI customization per screen. That works well when one customizer owns one instance. It breaks down when the customization comes from an ISV, because a customer's instance may run several ISV solutions plus the VAR's own changes.

Take two ISV solutions that each add an action to the Sales Orders screen through the UI:

1. Both packages are published to the same instance.
2. Both want to own the workflow customization for that screen.
3. Only one can apply. The other is overwritten or ignored, and the customer sees a missing action or a broken process, often with no obvious cause.

Code-based customization doesn't have this problem. Each solution ships its own graph extension, and each extension contributes its own additions to the screen configuration, so the changes stack. It is also testable, source-controlled, and upgrade-safe in the way the rest of an ISV's code is.

The rule also keeps the UI route for the people it fits: VARs and customizers working on one specific instance, where they control what else is installed.

Wrapping Up

The rule is small but it matters. UI workflow customization allows one customization per screen, ISV solutions share instances, and code-based customizations compose where UI ones collide. If you are targeting 2026 R1 or later, put your workflow changes in code now. The Acumatica Help documentation on customizing workflows in code and the T270 course are good starting points.

Happy coding!