Design NetSuite Automatic Location Assignment by deciding which warehouses are eligible before deciding which eligible warehouse is preferred. Geography, product handling, subsidiary relationships, and inventory conditions are constraints. Distance, ranking, and workload preferences operate within that permitted set.
Write the intended result for representative orders before creating rules. Then test rule sequence, exclusions, split-location behavior, and the no-stock fallback. A location appearing on every line can look successful while routing an order to a facility that cannot actually serve it.
List fulfillment locations and the business conditions under which each may ship. Include service regions, supported item classes, handling capabilities, operating restrictions, and any subsidiary relationship required by the account. Identify inactive or non-fulfillment locations that must never be selected.
For each condition, decide where it is maintained. A warehouse capability may be represented through a location set and a line-item filter. A geographic rule may use supported region or radius settings. Avoid encoding the same fact in several unrelated searches without an owner.
Review the location's ALA setup itself. Automatic assignment is disallowed by default until configured. A carefully designed rule cannot select a location that is not permitted to participate. Keep feature availability, automation capacity, and role permissions in the implementation checklist.
ALA evaluates rules in sequence. If an earlier rule assigns all lines, later rules are skipped. This makes ordering a business decision: a broad first rule can consume cases that a later specialist rule was supposed to handle.
Write rules in plain language before configuring them. For example, temperature-controlled items may need an eligible specialist warehouse, while ordinary stock may follow a wider geographic rule. A saved-search filter can identify the relevant line population, but its returned rows need testing.
Give each rule a documented reason and expected fallback. If a specialist warehouse has no stock, should the line remain unresolved, move to another qualified location, or enter an approved backorder route? Do not allow a general fallback to bypass a mandatory handling requirement.
Minimizing fulfillment locations, selecting a closer location, choosing a ranked location, and distributing workload solve different problems. A single preferred strategy cannot automatically balance every commercial objective.
Consider a customer order with two products. One warehouse holds both but is farther away; two closer warehouses can supply one product each. The correct decision depends on shipment cost, delivery promise, split-shipment policy, and operational capacity. Establish the business preference before testing how the configured rules implement it.
Use real address-quality cases. Radius and distance calculations require appropriate postal or coordinate data. A test with only clean domestic addresses will not reveal what happens when a customer address is incomplete or outside the usual regions.
Assume a retailer has North Warehouse, Central Warehouse, and a store location. North can handle oversized products. Central and the store cannot. All three hold some ordinary accessories.
An order contains an oversized stand and two accessories. A broad “closest location” rule placed first could prevent the intended specialist rule from being evaluated if it assigns the lines under its configured criteria. The design should establish specialist eligibility before allowing a general location preference.
The test expectation is explicit: the stand must be assigned only to an approved oversized-capable warehouse. Accessories may join that shipment if the chosen policy and stock allow it, or use another permitted location if splitting is approved.
A second test removes stock from North. The pass condition is a visible unresolved or appropriately backordered stand, rather than an assignment to an incapable facility. A third test restores stock but changes the customer's region, proving that handling capability alone does not override shipping eligibility.
Inspect sales-order lines that should retain a manually selected location. The Do Not Auto Assign Location setting can prevent the engine from changing those lines. Preferred item-location behavior can also influence the line before automation runs.
Test both intended and accidental exclusions. A legacy import might populate a preferred location or flag that causes ALA to skip an otherwise eligible line. Conversely, an integration may overwrite a protected location after assignment. Trace which process last changed the relevant field.
In cross-subsidiary fulfillment accounts, confirm the appropriate inventory-location field and required relationships. A location being visible to an administrator does not prove it is a valid cross-subsidiary fulfillment source. Include the actual transaction subsidiary and operating role in the test evidence.
Backorder rules run after ordinary rules and do not check inventory at the candidate locations. They can assign a location to a line even when stock is unavailable. That gives the line an intended future fulfillment source; it does not make the order ready to pick.
Decide whether the fallback is desirable for each order class. Some businesses want an accountable warehouse on every line. Others prefer a visible unresolved line when routing requires a human decision. Keep that choice distinct from the customer's promised date.
If Supply Allocation is integrated with ALA, review future supply and availability dates as well as current stock. Confirm the actual allocation strategy and location result. An assigned source supported by future supply requires different communication from a source with immediately usable units.
ALA can run through configured business events or a supported macro, and those methods have different timing characteristics. Record which route the business uses and what users should expect after saving an order.
Test an order created through each approved entry channel. A successful UI test does not prove that an imported or integrated order triggers the same sequence. Include downstream workflows that depend on a location being present, particularly when processing is asynchronous.
Inspect automation logs and resulting line fields before rerunning an order repeatedly. Multiple attempts can obscure whether the issue is missing configuration, a filtered-out location, timing, or a later customization changing the result. Test reruns and manual overrides deliberately in a sandbox.
Use a compact set of orders that covers the important choices:
For each, record expected location, reason, acceptable alternatives, expected timing, and any required manual decision. Include the rule that should win and those that should not apply. This makes a failed test explainable.
Review shared configurations carefully. Changing a configuration used by multiple subsidiaries can affect more than the immediate project. Capture the affected population, obtain process-owner approval, and retain a rollback plan before production change.
A review through CuriousRubik's NetSuite support services can use the eligibility map and acceptance matrix to identify account-specific gaps. Avoid judging success solely by the percentage of lines with a populated location.
No. The selected location depends on eligibility, rule sequence, and configured strategy. Distance is one supported preference, and earlier rules can assign lines before later distance-based rules are evaluated.
Check whether ALA is allowed for the location, whether region and item criteria exclude it, and whether an earlier rule already assigned the line. Also inspect line exclusions, location data, and any applicable subsidiary restrictions.
No. Backorder rules are evaluated after ordinary rules and do not check location inventory. Their result identifies a future fulfillment source; it should not be interpreted as shipment readiness.
Preferred-location behavior can populate a location and set the line to avoid automatic reassignment. Inspect the relevant line fields and account configuration. Test intentional manual exceptions separately from ordinary automatically routed orders.
Test all affected subsidiaries and order classes, restrictive-rule precedence, splits, exclusions, no-stock fallbacks, and automation timing. Keep expected outcomes and a rollback plan, because one shared configuration change can alter multiple operational flows.