Customer onboarding workflows share the master-data shape of vendor approval — no natural document total to gate on — but the actual checklist is different enough, and usually spans more than one screen, that it deserves separate treatment. Onboarding a customer well in Acumatica typically means credit review, tax setup verification, and often a CRM-to-AR handoff, all before the customer record should be usable on a sales order.
The CRM-to-AR handoff is the real workflow boundary
A new customer frequently starts life as a CRM Business Account (screen CR303000) created by a salesperson, then needs to become a full Customer (AR303000) with credit terms, tax zones, and a AR account before it's usable on transactions. That's technically a conversion action, not just a status change, and the workflow needs to gate the conversion itself — not just add approval friction after the customer already exists in AR, which is too late to prevent an unvetted account from being used.
public static void Configure(WorkflowContext<BusinessAccountMaint, BAccount> context)
{
var graph = context.Graph;
graph.WithStates(states => states
.Add<BAccount.status.PendingCreditReview>(state => state
.IsSpecific()
.Menu(m => m.DisplayName("Pending Credit Review"))));
graph.WithTransitions(transitions => transitions
.AddGroupFrom<BAccount.status.Active>(g => g
.Add(t => t
.To<BAccount.status.PendingCreditReview>()
.IsTriggeredOn(a => a.Actions.ConvertToCustomer) // custom action
.When(BAccount.type.IsEqual(BAccountType.ProspectType)))));
}
Credit review as a real external check, not a rubber stamp
For clients doing business across multiple East African markets, "credit review" is often a genuine external check — a credit bureau lookup, a trade reference call — not just an internal sign-off. I model this as a required field (CreditCheckCompleted, CreditCheckDate, CreditLimit populated from the result) gating the transition out of PendingCreditReview, populated either manually by the credit team or via an integration that calls out to a bureau API and writes the result back through the contract-based REST API before the internal approver ever sees the record. The workflow's job is just to hold the customer un-transactable until those fields are populated — the actual credit decision logic lives outside the workflow entirely.
Status alone doesn't stop a determined user from selecting a pending customer on a sales order if the selector's underlying view doesn't filter on status. Explicitly restrict the customer selector on SO301000 (and any other transaction entry screen) to exclude non-Active customers, in addition to the workflow gate — the workflow controls the record's lifecycle, but transaction screens need their own filter to actually enforce the restriction where it's used.
Tax zone and currency: the checklist item people forget to gate on
Beyond credit, I've had onboarding workflows fail quietly because a customer was approved and activated before its Tax Zone or Currency ID was set — perfectly legal from the workflow's point of view since those aren't required fields on the base DAC, but the first invoice against that customer then either fails or, worse, posts with a default tax zone that's wrong for the customer's actual jurisdiction. Add explicit completeness conditions for these fields to the pre-approval transition, the same way vendor onboarding gates on tax registration and bank details — treat "fields that don't block a save but do break the first transaction" as first-class onboarding requirements.
Credit and tax review can run in parallel, but conversion needs both
Credit review and tax/compliance setup are usually independent workstreams handled by different people, and there's no reason to force them sequential — this is the same "all of" parallel approval pattern covered elsewhere in this series, just applied to two different completeness checks rather than two human approvers. Model both as conditions ANDed together on the single transition out of PendingCreditReview (or split into two intermediate states if the client wants visibility into which specific workstream is still outstanding — worth asking, since "why is this customer still pending" is a question someone will ask within the first month of go-live).
Wrapping up
Customer onboarding workflows center on the CRM-to-AR conversion boundary, need a real completeness gate (credit, tax, currency) rather than a rubber-stamp status flip, and should restrict transaction-entry screens directly rather than relying on workflow status alone to keep an unvetted customer off a sales order. Treat the conversion action itself, not just the resulting status, as the thing the workflow governs.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.