Multiple Locations

Overview

Ziptask has no dedicated “location” object — and for most multi-site operations it doesn’t need one. Teams are the location boundary. A team isolates who can see and work on a set of lists, so modelling each location (or each location + department) as its own team keeps every site’s work cleanly separated inside a single account, with one shared login, one set of templates, and account-wide reporting for owners.

This guide covers the recommended pattern, when to use it, and the limits to know before you scale.

Requires: teams_enabled feature flag on. Custom roles (referenced below) require the Starter plan or above. See teams.md, permissions.md, and feature-flags.md.

First decide: isolate, or just label?

There are two different needs that look similar. Pick the one that matches how your staff actually work — it determines the whole setup.

You want…	Use	Why
Each location’s staff to only see and work on their own site’s lists	Teams	Teams enforce access. A team member can’t see another team’s lists.
One shared crew that floats between sites, and you just want to filter/report by site	Tags	Tags label and filter lists but don’t restrict access — everyone still sees everything. See tags.md.

A Customer can also stand in for a site when the “location” is really a client property you service (common for cleaning, landscaping, and property management) — attach each list to the customer and use the customer’s history as the per-site record.

The rest of this guide assumes you want isolation — separate staff per location — which is the usual case for branches, venues, and franchises.

The recommended model: teams as location × department

For a two-location operation with a kitchen and a front-of-house at each site, create four teams:

Location A — Kitchen
Location A — Front of House
Location B — Kitchen
Location B — Front of House

Then assign roles by how far a person’s responsibility reaches:

Person	Role	Team membership
Line staff / crew at one site + dept	Team User	Their one team (e.g. `Location A — Kitchen`)
Department lead over one team	Team Admin	That one team
Location manager over a whole site	Team Admin	Both of that site’s teams (Kitchen + Front of House)
Owner / regional manager (all sites)	Admin or Root	No team membership needed

Two things make this work:

Members can belong to multiple teams. That’s how a location manager gets admin over both departments at their site — add them to both teams as Team Admin. See teams.md.
Root and Admin see everything account-wide, regardless of team. The owner does not need to be added to every team — account scope already covers all locations. Reserve multi-team membership for the location managers who need it.

If you only need location separation (not location × department), collapse it: one team per location (Location A, Location B).

Setting it up

Turn on teams_enabled (Root, from account settings) if it isn’t already.
Create the teams — one per location, or one per location × department (Teams page → Create team). See teams.md.
Add members to their team(s) and set each person’s role (Team User for crew, Team Admin for managers). A person on multiple teams gets a team picker when creating lists.
Build each location’s lists from your templates. Create the list from a template, then set its team to the correct location team. Templates are shared account-wide, so you build the checklist once and stamp it per location. See tasks.md.
For recurring routines, set the team on the master list. Every instance the schedule spawns inherits that team automatically — see below.

How recurring lists behave across locations

A recurring master list belongs to one team, and every instance it spawns inherits that team. So a routine that runs at both locations needs one master per location team (e.g. a nightly close master on Location A — Kitchen and another on Location B — Kitchen). Build each from the same template to keep them identical.

The same is true of assignments: whoever is assigned to the master is copied onto each spawned instance automatically, so you set a location’s standing crew on the master once and every future instance carries it. See tasks.md and reminders.md.

Limits to know

A person has one role per account, applied across all their teams. You can’t make someone a Team Admin on one team and a Team User on another — if they’re Team Admin, they manage every team they belong to. For the usual hierarchy (managers admin their sites, staff work their department) this is exactly right; it only bites if you need someone to manage one site but merely work at another.
No cross-location roll-up beyond Root/Admin. A Team Admin sees only their teams. Account-wide visibility and reporting is a Root/Admin (owner) view. See reporting.md and activity-log.md.
Teams are the isolation unit — not a billing or data boundary. All locations share one subscription, one member directory, one template/tag/customer library, and one activity history. If you need fully separate billing or data per site, use separate accounts instead.

Support notes

If a location manager can’t see a site’s lists, check (a) they’re a member of that site’s team(s), and (b) the lists actually have the right team set (visible in the list detail sidebar). Lists with no team are visible only to their creator and Root. See teams.md.
If recurring instances at a new location aren’t carrying the right crew, check the master list’s team and assignments — instances inherit both from the master at spawn, so fixes go on the master (and apply to future instances; already-spawned ones are edited individually).
Renaming a location: rename the team (Teams page). Existing lists keep their association automatically.
Closing a location: deleting its team removes the team and its memberships but not the lists or tasks — reassign or archive those lists first if you want them off the active roster.
Owners who “can’t find the Locations feature”: there isn’t one — this teams-based pattern is the multi-location setup. Point them to this guide.