Most approval-map examples I've written about assume a static approver — a role, a fixed employee. Conditional assignment is the harder, more common real-world requirement: the approver depends on data in the document itself, resolved at the moment the document enters the approval state, not hardcoded at design time. This post is about the assignment-rule mechanics that make that work, distinct from the transition conditions covered elsewhere in this series.
Two different condition systems, easy to conflate
It's worth being precise about a distinction that trips up developers new to the Workflow engine: transition conditions (.When() in Configure) decide whether a document moves into a pending-approval state at all. Assignment rules on the Assignment and Approval Maps screen decide who gets the resulting task once it's in that state. They are configured in entirely different places, evaluated at different times, and confusing them is the single most common reason "the workflow routes to the wrong person" tickets take longer to diagnose than they should — the fix is very often on EP503010, not in a C# file at all.
The assignment rule types available on the map
On a map step, the assignment rule dropdown gives you a handful of resolution strategies: a fixed workgroup, a fixed employee, "by role," and — the one this post is about — a condition-based rule that resolves off a field on the document. For a PO, that's commonly the requesting employee's manager (resolved via the Employee's Report To hierarchy); for an expense claim, the claimant's manager; for a case, the case owner's team lead.
Map Step: Manager Approval
Assignment Rule: By condition
Source Field: POOrder.EmployeeID (requester)
Resolution: Report-To manager of Source Field's linked EPEmployee
Fallback: Workgroup "Procurement" if manager lookup fails
(e.g. requester has no manager assigned — always
configure a fallback, don't let this be a dead end)
When the stock rule types aren't enough
The stock condition-based rule handles direct-manager lookups well but doesn't natively handle "second-level manager if the amount is large" or "the department head from a lookup table keyed on cost center" — those need a graph extension that resolves the actual approver into a field the assignment rule can read, following the same pattern as computing flags for .When() conditions elsewhere in this series, just applied to the assignment side instead of the transition side:
protected virtual void POOrder_RowPersisting(PXCache cache, PXRowPersistingEventArgs e)
{
var order = (POOrder)e.Row;
if (order == null || order.OrderTotal == null) return;
// Escalate to the requester's manager's manager above a threshold
if (order.OrderTotal >= 50000m)
{
var requester = EPEmployee.PK.Find(Base, order.EmployeeID);
var manager = requester?.ReportsToID != null
? EPEmployee.PK.Find(Base, requester.ReportsToID) : null;
order.ApprovalEmployeeID = manager?.ReportsToID ?? requester?.ReportsToID;
}
else
{
order.ApprovalEmployeeID = null; // fall back to direct-manager rule
}
}
The failure mode nobody tests for: stale org hierarchy data
Conditional assignment is only as good as the Employee master's Report To field, and that field drifts — people change managers, leave, get promoted — far more often than clients update it in Acumatica. I've debugged more "wrong person got the approval task" tickets that traced back to an outdated ReportsToID than to any workflow misconfiguration. Before blaming the assignment rule, check the Employees screen (EP203000) for the actual current manager on file; it's usually stale, not broken.
Every condition-based assignment rule needs an explicit fallback for when the lookup resolves to nobody — a terminated employee still listed as a manager, a missing ReportsToID, a department with no head configured. Without a fallback workgroup or role, the document enters pending-approval limbo with literally no one assigned to act on it, and the only way anyone notices is a customer complaint about a stuck order weeks later.
Wrapping up
Conditional assignment lives on the Assignment and Approval Maps screen, separate from the transition conditions that gate whether a document enters approval at all — keep those two systems distinct in your own head and in your documentation. Use the stock condition-based rule for direct-manager lookups, extend into a graph-computed field for anything more elaborate, always configure a fallback, and check for stale ReportsToID data before assuming a routing bug is a code bug.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.