Acumatica Workflow — New Vendor Approval

Vendor approval is a different animal from the document-approval workflows I usually write about, because the entity being approved — a Vendor record on screen AP303000, graph VendorMaint — has no natural transaction total to gate on. There's no dollar amount on a new vendor record itself; the risk being controlled is "did anyone vet this vendor before we can cut them a check," which means the workflow has to key off completeness and verification state rather than a number.

A status model built for master data, not documents

Vendor uses BAccount.Status conceptually similar to customer status — Active, Inactive, Hold — but out of the box there isn't a "PendingApproval" status in the stock vendor workflow the way there is on transactional documents. Adding one means extending the state set, not just adding transitions to existing states:

public static void Configure(WorkflowContext<VendorMaint, Vendor> context)
{
    var graph = context.Graph;
    graph.WithStates(states => states
        .Add<Vendor.status.PendingApproval>(state => state
            .IsSpecific()
            .Menu(m => m.DisplayName("Pending Approval"))
            .UpdateSettingsFrom(g => g.FirstIn<Vendor.status.Hold>())));

    graph.WithTransitions(transitions => transitions
        .AddGroupFrom<Vendor.status.Hold>(g => g
            .Add(t => t
                .To<Vendor.status.PendingApproval>()
                .IsTriggeredOn(a => a.Actions.Save)
                .When(Vendor.taxRegistrationID.IsNotNull()
                      & Vendor.bankAccountID.IsNotNull()   // completeness gate
                      & Vendor.status.IsNotEqual(VendorStatus.Active)))));
}

Completeness fields as the practical trigger

Because there's no amount to threshold on, the trigger condition for "this vendor needs approval" is almost always a completeness check: tax registration present, bank details captured, a W-9 or equivalent document attached, a duplicate-vendor check passed. I compute these into a single unbound IsReadyForApproval field via a RowSelected handler that checks each requirement, and condition the transition on that flag rather than replicating the same multi-field AND clause across every transition that needs it — one place to update when the completeness checklist changes, instead of hunting through several .When() expressions.

The transition target is often "Active," and that has side effects

Approving a vendor typically means moving it to Active status, which is the same status that makes the vendor selectable on new POs and bills across the system. That means the approval transition is also, functionally, a "go live" event — any downstream automation that fires on vendor activation (a welcome email, a sync to an external procurement portal, a GL default account assignment) needs to hang off this same transition, and I wire those as workflow actions on the transition itself (.WithActions at the transition level, distinct from graph-level actions) so they're guaranteed to run exactly once, at approval time, rather than duplicated across every place in the codebase that happens to set status to Active.

Segregation of duties: the requester can't be the approver

This is the control clients care about most for vendor approval specifically — the person who entered the vendor (often a requester with limited screen access) must not be the person who approves it, otherwise the whole workflow is theater. The approval map assignment rule needs an explicit exclusion of CreatedByID from the eligible approver set; the stock "By role" assignment rule doesn't exclude the creator automatically, so if your approver role is broad (e.g. any AP Manager, and the person who created the vendor happens to hold that role), you need a custom assignment rule or a graph-level validation blocking self-approval outright.

Wrapping up

Vendor approval workflows are gated by completeness, not amount — build a single computed readiness flag rather than repeating field checks across conditions, treat the approval transition as the natural hook for activation side effects, and always verify segregation of duties is actually enforced rather than assumed from role names. The lack of a dollar figure to threshold on is the tell that this workflow needs a different mental model than document approval.