Icons are how a crew reads a job without tapping anything. Done right, a fielder can look at a screen and see which poles are finished, which are started, and which have not been touched. Done badly, every pole looks the same and they have to open each one to find out.

This is one step of the Katapult import, and you can come back to it later through your configuration.

The field names in the examples below come from real configurations. Yours will differ. See Why your screens may not match this guide.

Your templates are listed with a count of how many icons each one has. That count is the fastest way to spot a type you have not styled yet: anything sitting at one icon has only its default and will look identical in every state.

Pick a template and you work on that type's icons.

Each type has a base icon, which is the one shown when no rule matches. Think of it as the resting state, an untouched pole. It is what your crews see at the start of a job.

A point icon has four parts: a label you write for yourself, a shape, a stroke color and a fill color, with a live preview so you can see what you make. You can set the fill to none. You cannot set the stroke that way. Line types, spans and guy runs, are simpler: a label, one color and a line style, with the same preview.

The label is only ever seen by you and whoever edits this next, so make it say what the icon means rather than what color it is. Measured will still make sense in a year; red circle will not.

On top of the base you add rule icons. Each one has its own look, and a condition that decides when it takes over.

A condition is a field and a test. The tests available:

has a value and is empty are the two that do most of the work, because most of what a crew wants to see is simply whether a thing has been done yet.

You can stack conditions, and choose whether they all have to be true or any one of them. Cloneable writes the result back to you in plain language, so a two-part rule reads like Done has a value AND Pole Class is "3". Read that sentence before you move on. If it does not describe what you meant, the rule is wrong.

You can move rules up and down, and the base icon only shows when none of them match. So put your most specific rule above your broader ones. A rule for "measured and exported" placed below a rule for "measured" will never fire, and it will look exactly like a rule you forgot to write.

There is a simulator on this step that shows which icon will display. Use it on every rule you build. This is not optional care, it is the only way to tell a working rule from a silent one, because both look identical in the editor.

If a rule gets too fiddly for the builder, there is an option to edit it directly as JSON. If you do that and it goes wrong, the rule will tell you it is invalid rather than failing quietly.

That check confirms the rule is well formed. It does not confirm the rule is right. A rule can be perfectly valid and still never fire on a phone, for example because it tests a field that object does not carry. When that happens the app does not report anything: it simply moves on to the next rule, exactly as if the condition had been tested and not met. There is no error, on the phone or in the office.

So a rule that is silently wrong and a rule that correctly does not match look the same from every direction. The simulator is the only place the difference shows.

The simplest useful scheme is progress. One real configuration set up its poles like this:

Three icons, and a crew lead can see the state of a whole job from the map. That is the bar worth aiming at: not pretty icons, but a screen that answers "what is left" without anyone opening a single pole.