This is where infrastructure from your map file becomes real objects your crews can work on. Cloneable calls it importing utility infrastructure data from KML, KMZ or GeoJSON files. You do not need to be an administrator to run an import, as long as a configuration already exists.

The import needs somewhere to put things. A configuration defines the pole, span and line types your job's data maps onto, so without one there is nothing to map onto.

If you have just built a configuration from a file, Cloneable brings you here with it already selected.

Drop in your file. Cloneable unpacks a KMZ for you.

When it parses, Cloneable tells you how many points and lines it found. Read that. It is the cheapest check in the whole process: if you expected two hundred poles and it found twenty, stop here rather than importing and unpicking it afterwards.

If the file cannot be read at all, Cloneable says it failed to parse it.

Two options: use an existing job, or create a new one.

If you create one, it needs a name and a configuration, and the wizard will not let you past without both. It tells you exactly which is missing.

Cloneable lists every kind of feature it found in your file, with how many objects each one holds, and you say which template each should become.

In Cloneable's own words:

On screen: "Map KML types to templates or leave them unmapped to skip. Only mapped types will be imported."

Read that second sentence twice. Anything you leave unmapped is skipped, and there is a skip control on each row making that an explicit choice. It is stated clearly on screen and it is still the easiest thing in this flow to miss, because skipping does not feel like deleting.

Each row shows you what you would give up, in the form of a count. A row reading seven objects means seven things will not exist if you leave it unmapped. Work down the whole list before moving on.

The wizard will stop you if you have mapped nothing at all, but it will happily proceed if you have mapped only some.

There is a step about linking, and Cloneable explains the mechanism plainly:

On screen: "Lines will automatically link to point objects based on matching endpoint coordinates. Make sure your KML data has properly aligned coordinates for accurate relationships."

That is the whole thing in one sentence: a line finds a pole because its end is where the pole is. Full detail, and what to do when they do not line up, in How spans connect to poles.

Look over the preview, then start the import.

When it finishes, Cloneable confirms it completed and tells you how many data objects it created. Check that number against the points and lines it found at the start. In a clean import they reconcile: twenty points and twelve lines gives you thirty-two objects. If your total is short, either something was left unmapped or an individual object did not save, and the import log lists anything Cloneable failed to create.

Cloneable then offers to take you straight to the map to look at what arrived, which is the fastest way to confirm your spans attached to your poles rather than floating on their own.

Cloneable tells you when the whole import could not run. It does not stop for a single object it could not create, so a run can finish, report success, and still have made fewer objects than you expected. That is why the count is worth checking every time.

If the whole run failed, go back through the steps and check that the file parsed, that the job and configuration are set, and that your types are mapped, rather than starting again with a new file.