Articles territories

What a territory version has to record to be worth having

Versioning a territory map is not saving a copy. Here is what has to be in a version for it to answer a question about last March.

Most systems that claim to version territories are saving a copy of the shapes. That is better than nothing and it is not enough, because the questions people ask about the past are not questions about shapes.

The test

A version is worth having if it can answer this, months later, without anybody reconstructing anything:

On 14 March, an enquiry came in for 2 East Main Street. What did the system say, and why?

Work backwards from that sentence and the contents of a version stop being a design decision.

What has to be in it

The boundaries, obviously, as geometry rather than as a list of codes. A list of postal codes is a description of a boundary that depends on somebody else’s data to become a shape, and that data changes underneath you. See why ZIP codes are not shapes.

What each territory was assigned to. A boundary with no owner answers half the question. Ownership changes more often than geometry does, and a version that keeps the shapes and not the assignments will confidently give you the wrong branch.

The rules. Exclusions, priorities, capability requirements, fallbacks. This is the part most often left out, and it is the part that explains the answers people query. A version with boundaries and no rules tells you which territories contained the address and cannot tell you which one won.

The dates it was live. Not just when it was created. A version created in February and published in April answers for April, and the created date will send somebody looking in the wrong place.

Who published it. One name. It is the person to ask, and asking is usually faster than reading.

Draft, published, and why the distinction is load-bearing

Territory work is not atomic. Redrawing a region means changing several boundaries, moving assignments, and adjusting a rule, over hours or days. If every save is live, then for those hours the map is in a state nobody designed: gaps between the shape you have moved and the one you have not, two territories briefly overlapping, a rule referring to a territory that has been renamed.

Every request answered during that window gets an answer from a half-finished map, and those answers do not announce themselves. The customer who got told nobody serves them at 11:40 on Tuesday is not going to call back.

So changes go into a draft, and publishing is one atomic step from one coherent state to another. This is the whole reason to have versions at all, and the dispute-settling comes second.

Publishing should be boring, and checkable

Before a version goes live there are a small number of things worth knowing, because each one is invisible in a list of shapes and obvious on a map:

  • Gaps that appeared. Addresses that were covered and now are not.
  • New overlaps, which may be intended and should be a decision rather than a surprise.
  • Territories with no owner, usually left over from a rename.
  • Rules pointing at things that no longer exist.

None of these has to block a publish. Somebody has to see them.

Rollback is choosing, not editing

When a published version turns out to be wrong, the recovery is to make an older version live again. Not to edit today’s map back towards what it used to be from memory, which is how a map ends up in a third state that matches neither.

This only works if the old version is complete in the sense above. A rollback that restores the boundaries and not the rules puts you somewhere new.

What it does not need

Every keystroke. Draft edits are working state. Versioning the draft history is a large amount of storage for a question nobody asks.

A branching model. Territory maps are not code and there is no merge. Two people editing the same region need to talk to each other, and a tool that lets them avoid it produces a conflict resolved by whoever saved last.

Approval workflow, at first. Useful in a large network, unnecessary in a small one, and a system that requires it before anybody has published anything will be worked around within a week.

The parts that earn their place are the ones the dispute conversation needs, and the atomic publish that stops a customer being answered from a half-finished map.