Clients and Locations

ZenPrint’s data hierarchy:

Organization (your MSP tenant)
└── Client (your customer)
    └── Location (a physical site for that customer)
        ├── Printer device
        ├── Endpoint (Windows machine)
        └── Endpoint group

You’ll see this hierarchy reflected in the scope filters on the Fleet page and in the way permissions cascade.

How clients and locations get created

You don’t create clients or locations by hand. They appear automatically, and how depends on what your RMM exposes:

• RMMs with a fixed organization/site structure (e.g. NinjaOne): the customer and site come straight from the RMM. As endpoints check in, ZenPrint creates the matching client and location on its own. Nothing for you to set up.
• RMMs that organize endpoints by groups, folders, or tags (e.g. Level.io): there’s no site structure to read, so you map each group path to a client and location once, under Settings → Group Mapping (see below). That mapping page is the one place clients and locations are created by hand.

Either way, there’s no “Add Location” button in the Fleet view.

Statuses

Both clients and locations carry one of four statuses. The effective status of anything beneath them (endpoint, printer, queue) is the more restrictive of the client’s and the location’s, in the order offboarding > suspended > paused > active. So a paused client with an active location is paused overall.

What each status does to the scripts:

Status	Scan	Reconcile	Capture	Poll
active	runs	installs, updates, and removes queues to match ZenPrint	works	runs
paused	runs	makes no changes (queues are left exactly as they are)	works	runs
suspended	skipped	makes no changes	blocked	skipped
offboarding	skipped	removes every ZenPrint-managed queue from the endpoints	blocked	skipped

In plain terms:

• paused — “keep watching this site, but don’t change anything.” Discovery and capture still work; reconcile won’t touch a queue. Use it when you’re not actively making changes but want the fleet kept current.
• suspended — a billing or contractual hold. ZenPrint stops observing the site (no scan, no capture) and freezes its queues, but leaves them installed and working.
• offboarding — the customer is leaving. The next reconcile on each endpoint strips ZenPrint’s queues off the machines. This is the status to set before deleting if you want a clean removal (see Offboarding a customer).

(Supply polling follows the same active/paused vs suspended/offboarding split as the rest: a mapped endpoint polls its printers while the site is active or paused, and stops once it’s suspended or offboarding, so supply-low alerts don’t keep firing for a customer you’ve put on hold or are letting go.)

Edit a client or location

1. Fleet → Client card → Edit (or open a client, then Location card → Edit)
2. Change the name, status, address, or notes
3. Save

The name you set here is a ZenPrint display name only. It’s a local override: it never writes back to your RMM, and a later RMM report won’t overwrite it (ZenPrint tracks the RMM’s own name separately, behind the scenes). So renaming a client in ZenPrint is safe and permanent.

Every status transition is allowed, at any time, in any direction: push a customer straight to offboarding if a relationship ends abruptly, or pull them back to active if they renew. Status changes are audited. The badge colours: active (green), paused (blue), suspended (amber), offboarding (red).

Deleting a client or location

Deletion is only allowed when the resource is suspended or offboarding. You can’t delete an active client. This is a guardrail against bulk-removing real customer data with one misclick: there’s always a deliberate “set the status first” step. The Delete button only appears in the edit form once status is suspended or offboarding.

Delete cascades through everything beneath it. Every queue assignment, queue, printer, endpoint group, and endpoint belonging to the target is removed together. Audit logs survive, so your record of who did what to this customer is preserved even after the customer is gone.

Deleting only removes ZenPrint’s records, though. It does not remove the queues already installed on the endpoints, and on an RMM that reports a fixed org/site (like NinjaOne) the client and location are recreated on the next check-in if the bootstrap is still attached. To offboard cleanly, follow the sequence below.

Offboarding a customer

Offboarding is a sequence, not a single delete. Pick the recipe that matches what you want to happen to the printers.

Offboarding and removing ZenPrint’s queues from the machines:

1. Set the client (or location) to offboarding.
2. Let reconcile run on every endpoint, or trigger it ad-hoc. On offboarding, reconcile removes every ZenPrint-managed queue.
3. Optionally run -Mode Cleanup on each endpoint to wipe ZenPrint’s local state (see Bootstrap → Cleanup).
4. Remove the ZenPrint bootstrap automation from your RMM so it stops checking the endpoints in. Skip this and the records come back on the next run.
5. Delete the client in ZenPrint.

Offboarding but leaving the printers working (you’re handing the account off and don’t want to disrupt printing):

1. Set the client to suspended. This freezes reconcile, so the installed queues are left exactly as they are.
2. Remove the bootstrap automation from your RMM.
3. Delete the client in ZenPrint.

In both cases the audit log survives the delete, so your record of what happened to the customer is preserved.

When a printer or endpoint moves

ZenPrint handles two kinds of move on its own:

• A printer moves to another site within the same customer. A scan finds the same physical printer (matched by MAC) at a different location under the same client. ZenPrint moves the printer record to follow, and the move is audited. Its queues and assignments move with the record, so nothing is lost; if the printer came up on a new IP, that’s handled by the normal IP-change flow.
• An endpoint moves to another customer. Your RMM reports the machine under a different customer, and ZenPrint updates its location to match. Queues that were pinned directly to that endpoint are marked stale, since they were set up for the old customer and shouldn’t follow; you’ll see them under Stale Queue Assignments on the dashboard to rebind or drop. Queues assigned to the endpoint’s group or location aren’t affected.

A printer that matches by MAC across different customers is not moved automatically. That’s more often hardware reuse or a misread than a real move, and a silent cross-customer move would leak one customer’s data into another’s view. Instead ZenPrint creates a fresh printer record at the new customer and leaves the call to you.

Group mapping (Level.io and similar RMMs)

Some RMMs don’t have a built-in “organization to site” structure ZenPrint can read automatically. Level.io, for example, organizes endpoints into groups (which can be nested folders). For these, you map each group path to a client and location under Settings → Group Mapping.

An endpoint that reports a group path with no mapping stays unassigned until you map it. It won’t lose data, it just has nowhere to live yet. While unassigned it checks in but does not sweep the network for printers (there’s nowhere to attach them); the first real discovery happens on the next scan after you map it. See Scripts → scan.

To create a mapping:

1. Go to Settings → Group Mapping and click Add Mapping.
2. Group Path: pick from the list of paths ZenPrint has already seen from unmapped endpoints, or choose Enter manually and type the path (use a slash between levels for nested groups, e.g. Acme / Head Office).
3. Client: pick an existing client, or choose New and type a name to create one.
4. Location: pick an existing location, or choose New to create one (a brand-new client always needs a new location). Optionally add scan networks (CIDR) for the location.
5. Create.

When you save, any endpoints already waiting with that exact group path are moved into the location immediately; you don’t have to wait for the next scan. New endpoints reporting the same path are routed automatically from then on.

Deleting a mapping leaves already-assigned endpoints where they are. It only means future endpoints reporting that path go unassigned again until you remap them.

The Group Mapping tab is available to roles that can create locations. To create a new client from this page as well, the role also needs permission to create clients.