Acumatica Workflow — Parallel Approvals

"Two people need to approve this, in any order, and we're done when both have" is a request that looks like it should be a small variation on single-approver routing and turns out to expose real differences in how the Assignment and Approval Maps screen models multi-approver rules versus how the Workflow engine models states. This post is specifically about getting parallel — not sequential — multi-approver behavior right.

Sequential is the default; parallel is a deliberate map setting

On the Assignment and Approval Maps screen (EP503010), a map step with multiple approver rows defaults to requiring them one after another in row order unless you explicitly configure the step as parallel — the Approve in Parallel (or, on some builds, a rule-level setting distinguishing "one of" versus "all of") flag on the map step. Missing this setting is the most common reason a "parallel approval" request ships as sequential and nobody notices until an approver on vacation blocks the whole chain because they were queued third instead of notified immediately alongside the other two.

// The workflow side only needs ONE transition into the pending-approval
// state — parallelism is entirely a property of the approval map step,
// not something you encode in Configure(). The graph doesn't know or
// care how many people approve; it only cares that the state's approval
// requirement (tracked internally against EPApproval records) is satisfied.

graph.WithTransitions(transitions => transitions
    .AddGroupFrom<APInvoice.status.Balanced>(g => g
        .Add(t => t
            .To<APInvoice.status.PendingApproval>()
            .IsTriggeredOn(a => a.Actions.Release)
            .When(APInvoice.docTotal.IsGreaterEqual(25000m)))));

All-of versus any-of: get this decision explicit in requirements

"Parallel" is ambiguous until you pin down whether the document proceeds once any one approver acts (a race — first responder wins, useful for redundancy across equally-authorized approvers) or only once all approvers have acted (true joint sign-off, useful for segregation of duties like finance-plus-operations both needing to bless a large PO). These map to different settings on the approval step, and I've had to redo this configuration more than once because "parallel" was assumed to mean "all of" by the client and configured as "any of" by the implementer, which quietly let single-approver rubber-stamping through on a control the client thought required two people.

Everyone gets notified at once, not staggered

A side effect of true parallel configuration: all eligible approvers get their assignment and notification simultaneously when the document enters the pending state, rather than the second approver only being notified once the first has acted (which is the sequential behavior). If your email/notification templates were originally written for a sequential flow — "please review, following [Approver 1]'s sign-off" style language — they read as broken once the map is switched to parallel. Audit notification copy whenever you convert an existing sequential map to parallel; it's a content bug, not a configuration bug, but it lands the same way in a support ticket.

Reassignment behavior differs under parallel maps

Delegation (an approver on leave routes their approvals to a backup) interacts differently with parallel maps than sequential ones: in a sequential chain, delegating step 2 doesn't affect step 1's already-completed approval. In an "all of" parallel step, if one of the two required parallel approvers delegates, the delegate's action counts toward the same "all of" requirement — which is usually what you want, but confirm the Employee Preferences delegation settings are configured correctly for everyone in a parallel approval group, because an approver who forgot to set up delegation before going on leave will genuinely block an "all of" step with no automatic escape.

Wrapping up

Parallel approval lives almost entirely in the approval map configuration, not in the workflow's Configure method — the graph only needs one clean transition into the pending state. Get "any of" versus "all of" explicit and tested with a mixed-outcome scenario, audit notification copy after converting from sequential, and confirm delegation is set up for everyone in a parallel group before you rely on it in production.