Sedi multiple

Panoramica

Ziptask non ha un oggetto “sede” dedicato — e per la maggior parte delle operazioni multi-sede non ne ha bisogno. I team sono il confine della sede. Un team isola chi può vedere e lavorare su un insieme di liste, quindi modellare ogni sede (o ogni sede + reparto) come il proprio team mantiene il lavoro di ogni sede nettamente separato all’interno di un unico account, con un unico login condiviso, un unico insieme di modelli e report a livello di account per i proprietari.

Questa guida copre il modello consigliato, quando usarlo e i limiti da conoscere prima di scalare.

Richiede: feature flag teams_enabled attivo. I ruoli personalizzati (citati sotto) richiedono il piano Starter o superiore. Vedi teams.md, permissions.md e feature-flags.md.

Prima decidi: isolare, o solo etichettare?

Ci sono due esigenze diverse che sembrano simili. Scegli quella che corrisponde a come il tuo personale lavora davvero — determina l’intera configurazione.

Vuoi…	Usa	Perché
Che il personale di ogni sede veda e lavori solo sulle liste della propria sede	Team	I team applicano l’accesso. Un membro di un team non può vedere le liste di un altro team.
Un’unica squadra condivisa che si sposta tra le sedi, e vuoi solo filtrare/fare report per sede	Tag	I tag etichettano e filtrano le liste ma non limitano l’accesso — tutti vedono comunque tutto. Vedi tags.md.

Un Cliente può anche fare le veci di una sede quando la “sede” è in realtà un immobile di un cliente che servi (comune per pulizie, giardinaggio e amministrazione di immobili) — collega ogni lista al cliente e usa la storia del cliente come registro per sede.

Il resto di questa guida presume che tu voglia l’isolamento — personale separato per sede — che è il caso usuale per filiali, locali e franchising.

Il modello consigliato: team come sede × reparto

Per un’operazione con due sedi con una cucina e una sala per ogni sede, crea quattro team:

Sede A — Cucina
Sede A — Sala
Sede B — Cucina
Sede B — Sala

Poi assegna i ruoli in base a quanto arriva la responsabilità di una persona:

Persona	Ruolo	Appartenenza al team
Personale operativo / squadra in una sede + reparto	Team User	Il loro unico team (ad es. `Sede A — Cucina`)
Responsabile di reparto su un team	Team Admin	Quell’unico team
Responsabile di sede su un’intera sede	Team Admin	Entrambi i team di quella sede (Cucina + Sala)
Proprietario / responsabile regionale (tutte le sedi)	Admin o Root	Nessuna appartenenza al team necessaria

Due cose fanno funzionare tutto questo:

I membri possono appartenere a più team. È così che un responsabile di sede ottiene i permessi di admin su entrambi i reparti della sua sede — aggiungilo a entrambi i team come Team Admin. Vedi teams.md.
Root e Admin vedono tutto a livello di account, indipendentemente dal team. Il proprietario non ha bisogno di essere aggiunto a ogni team — l’ambito account copre già tutte le sedi. Riserva l’appartenenza a più team ai responsabili di sede che ne hanno bisogno.

Se ti serve solo la separazione per sede (non sede × reparto), semplificala: un team per sede (Sede A, Sede B).

Configurarlo

Attiva teams_enabled (Root, dalle impostazioni account) se non lo è già.
Crea i team — uno per sede, o uno per sede × reparto (pagina Team → Crea team). Vedi teams.md.
Aggiungi i membri al/ai loro team e imposta il ruolo di ogni persona (Team User per la squadra, Team Admin per i responsabili). Una persona in più team ottiene un selettore di team quando crea le liste.
Costruisci le liste di ogni sede dai tuoi modelli. Crea la lista da un modello, poi imposta il suo team sul team della sede corretta. I modelli sono condivisi a livello di account, quindi costruisci la checklist una volta e la contrassegni per sede. Vedi tasks.md.
Per le routine ricorrenti, imposta il team sulla lista master. Ogni istanza che la pianificazione genera eredita automaticamente quel team — vedi sotto.

Come si comportano le liste ricorrenti tra le sedi

Una lista master ricorrente appartiene a un team, e ogni istanza che genera eredita quel team. Quindi una routine che gira in entrambe le sedi ha bisogno di una master per team di sede (ad es. una master di chiusura serale su Sede A — Cucina e un’altra su Sede B — Cucina). Costruisci ciascuna dallo stesso modello per mantenerle identiche.

Lo stesso vale per le assegnazioni: chiunque sia assegnato alla master viene copiato automaticamente su ogni istanza generata, così imposti la squadra fissa di una sede sulla master una volta e ogni istanza futura la porta con sé. Vedi tasks.md e reminders.md.

Limiti da conoscere

Una persona ha un ruolo per account, applicato a tutti i suoi team. Non puoi rendere qualcuno Team Admin su un team e Team User su un altro — se è Team Admin, gestisce ogni team a cui appartiene. Per la solita gerarchia (i responsabili amministrano le loro sedi, il personale lavora nel proprio reparto) questo è esattamente corretto; è un problema solo se hai bisogno che qualcuno gestisca una sede ma lavori semplicemente in un’altra.
Nessun consolidamento tra sedi oltre a Root/Admin. Un Team Admin vede solo i suoi team. La visibilità e i report a livello di account sono una vista Root/Admin (proprietario). Vedi reporting.md e activity-log.md.
I team sono l’unità di isolamento — non un confine di fatturazione o di dati. Tutte le sedi condividono un abbonamento, un elenco di membri, una libreria di modelli/tag/clienti e una cronologia delle attività. Se hai bisogno di fatturazione o dati completamente separati per sede, usa invece account separati.

Note per l’assistenza

Se un responsabile di sede non riesce a vedere le liste di una sede, verifica (a) che sia membro del/dei team di quella sede, e (b) che le liste abbiano effettivamente il team giusto impostato (visibile nella barra laterale di dettaglio della lista). Le liste senza team sono visibili solo al loro creatore e a Root. Vedi teams.md.
Se le istanze ricorrenti in una nuova sede non portano la squadra giusta, controlla il team e le assegnazioni della lista master — le istanze ereditano entrambi dalla master alla generazione, quindi le correzioni vanno sulla master (e si applicano alle istanze future; quelle già generate si modificano singolarmente).
Rinominare una sede: rinomina il team (pagina Team). Le liste esistenti mantengono automaticamente la loro associazione.
Chiudere una sede: eliminare il suo team rimuove il team e le sue appartenenze ma non le liste o le attività — riassegna o archivia prima quelle liste se le vuoi fuori dall’elenco attivo.
Proprietari che “non trovano la funzionalità Sedi”: non ce n’è una — questo modello basato sui team è la configurazione multi-sede. Indirizzali a questa guida.