InfoWorks WS Pro: demand allocation you can audit

The task and the evidence trail

The worked task is to prepare an auditable customer-demand allocation and understand what must be revisited after a water-supply-zone boundary changes. Begin in a separate editable model or scenario, with a preserved baseline. The software can allocate demand efficiently, but only the engineer can establish whether the customer, connection and supply-zone relationships are physically correct.

This guide names operations from Autodesk’s WS Pro 2026 help. Earlier releases, including 5.1.x, can use different dialogs or data arrangements. Apply the same evidence checks and confirm field definitions in your installed version before changing a production model. The download is an audit worksheet, not a native WS Pro database import template.

Build a demand ledger first

Separate raw customer consumption, approved corrections, customer demand assigned to the model and modelled non-revenue-water components. Record the period and units of every total. A customer billing volume for one month cannot be directly compared with a model’s peak-day demand without conversion and an explicit scaling basis.

Before allocation, record the number of raw rows, unique customer IDs, accepted parent groups, excluded records and total consumption. After allocation, reconcile both customer count and volume. A small number of unallocated customers can still represent a large demand, while many child records may represent one physical connection.

Use mutually exclusive categories and a common reporting period. A record must not contribute to two categories.

Retain the network revision, scenario, customer dataset revision and allocation settings alongside the ledger. This makes a later comparison meaningful when someone opens a different network or reruns the wizard.

Resolve identity and parent–child relationships

1. Check that every customer ID is unique in the intended dataset. Investigate duplicates rather than deleting them based only on coordinates.
2. Check that each non-empty parent key identifies an existing parent in the same relevant dataset.
3. Trace the relationships for cycles, self-parenting and records used in incompatible parent and child roles.
4. Confirm where the physical connection belongs and how the parent represents its children. Review group demand and property count.
5. Separate genuine stand-alone customers from records with a missing or broken relationship. Repair against source evidence and keep the change log.

In Autodesk’s documented allocation behaviour, children are allocated with their parent, with specific exceptions such as the maximum-properties condition. Therefore, increasing a search distance will not repair a missing parent or a contradictory hierarchy. Treat the hierarchy as a data model, not merely a collection of nearby points.

Work the audit exercise

The six records total 4,000 L/day. The exercise does not imply that a custom run_id column is a universal WS Pro field; it is an audit device. Only 1,500 L/day has an internally consistent current group in this worksheet. Another 1,700 L/day has hierarchy problems and 800 L/day needs run-context verification. Closing the ledger requires resolving these categories, not suppressing warnings.

Use the allocation wizard deliberately

1. Open the editable target network and confirm the intended customer dataset and selection. Start the Static Demand Allocation wizard through the command available in your version.
2. At the review stage, inspect the actual population included in this allocation run. Establish whether existing assignments are retained or being reconsidered.
3. At Allocate to Network, set justified pipe, node, polygon and distance rules. Save the settings in the audit record.
4. Run allocation, inspect the summary and review the unallocated set. Look at a spatial sample of successful assignments as well as failures.
5. Change one justified rule or repair one data issue at a time, rerun and compare the ledger. Preserve manual connection decisions unless a reviewed change requires replacing them.

Rules can exclude a nearby pipe because of its size, exclude one or both nodes, or require membership in the same polygons. Parent groups can exceed a property limit as a group. The nearest visible pipe is therefore not necessarily an eligible allocation target. A very large radius can conceal a wrong connection without addressing the real cause.

Interpret blank fields and mismatched counts

A wizard’s reported unallocated count refers to its processed set and allocation logic. A grid selection may cover a different set, different scenario or records whose relationships require another interpretation. Before declaring a contradiction, compare the exact record IDs from both views. Count common IDs and IDs unique to each set.

Select a handful of representative records and inspect their parent, connection, pipe and node context. Confirm whether a blank value is truly stored as null, an empty string, a default flag or a value shown through another relationship. Do not build a universal QA query from a field label without checking what it means in your release.

When a warning says a customer cannot be found in the network, establish which operation produced it and which identifier was requested. Trace that ID through the source dataset and active network. The message alone does not establish that distance is the problem.

After a water-supply-zone polygon changes

A polygon boundary edit changes spatial membership. It does not, by itself, prove that physical service connections or every demand definition should change. Compare old and new membership for customer points and demand nodes. Create a change list for records crossing the boundary, overlapping polygons or sitting exactly on an edge.

If allocation uses polygon-based rules, review the affected assignments against the revised boundary and real supply arrangements. Reallocation may be necessary for some records, but a blanket rerun can undo valid manual connections. Document the scope and compare before-and-after customer volumes, nodal demand, zone totals and unresolved items.

Also inspect demand scaling, alternate demand sets, patterns and any calculated UFW or residual component. An unchanged customer file does not guarantee an unchanged model demand if category definitions, zone membership or scaling have changed. Removing a category because it appears blank can alter a calculation elsewhere. Establish the dependency before deleting it.

Finish with hydraulic and operational checks

• Reconcile customer and node totals on the same base-demand and time basis.
• Compare zone inflows and storage changes with the adopted water balance.
• Inspect large nodal demand changes and every material cross-zone reassignment.
• Run the baseline and relevant peak or outage cases using the intended demand set.
• Retain warnings, unresolved records, manual decisions and model revision information.

Read-only scaling or editing controls should be traced to the object state, scenario, permissions or workflow that owns the data. Do not bypass the protection by modifying unrelated objects. Connect the accepted model to the demand framework and use the GIS exercise for independent spatial reconciliation.

Sources & further reading

• Static Demand Allocation: allocation rules ↗Autodesk · InfoWorks WS Pro 2026 help
  External source · Checked 25 September 2026
• Parent and child customer points ↗Autodesk · InfoWorks WS Pro 2026 help
  External source · Checked 25 September 2026
• Static Demand Allocation wizard: overview ↗Autodesk · InfoWorks WS Pro 2026 help
  External source · Checked 25 September 2026
• Best Practice Modelling Guidelines ↗eWater · 2011
  External source · Checked 24 September 2026

Source findings are distinguished from editorial interpretation. Apply current local criteria and project evidence when making engineering decisions.