Vários locais

Visão geral

O Ziptask não tem um objeto “local” dedicado — e, para a maioria das operações com vários locais, ele não precisa de um. As equipes são a fronteira de local. Uma equipe isola quem pode ver e trabalhar em um conjunto de listas, então modelar cada local (ou cada local + departamento) como sua própria equipe mantém o trabalho de cada local claramente separado dentro de uma única conta, com um login compartilhado, um conjunto de modelos e relatórios em toda a conta para os donos.

Este guia cobre o padrão recomendado, quando usá-lo e os limites a conhecer antes de escalar.

Requer: feature flag teams_enabled ativada. As funções personalizadas (referenciadas abaixo) exigem o plano Starter ou acima. Veja teams.md, permissions.md e feature-flags.md.

Primeiro decida: isolar ou apenas rotular?

Há duas necessidades diferentes que parecem semelhantes. Escolha a que corresponde a como sua equipe realmente trabalha — isso determina toda a configuração.

Você quer…	Use	Por quê
Que a equipe de cada local veja e trabalhe apenas nas listas do próprio local	Equipes	As equipes impõem o acesso. Um membro de equipe não consegue ver as listas de outra equipe.
Uma equipe compartilhada que circula entre locais, e você só quer filtrar/relatar por local	Etiquetas	As etiquetas rotulam e filtram listas, mas não restringem o acesso — todos ainda veem tudo. Veja tags.md.

Um Cliente também pode fazer as vezes de um local quando o “local” é, na verdade, uma propriedade de cliente que você atende (comum para limpeza, jardinagem e administração de imóveis) — vincule cada lista ao cliente e use o histórico do cliente como o registro de cada local.

O restante deste guia pressupõe que você queira isolamento — equipe separada por local — que é o caso usual para filiais, unidades e franquias.

O modelo recomendado: equipes como local × departamento

Para uma operação de dois locais com uma cozinha e um salão em cada local, crie quatro equipes:

Local A — Cozinha
Local A — Salão
Local B — Cozinha
Local B — Salão

Depois atribua funções de acordo com o quão longe a responsabilidade de cada pessoa alcança:

Pessoa	Função	Participação em equipe
Equipe de linha em um local + depto	Team User	A sua única equipe (ex.: `Local A — Cozinha`)
Líder de departamento sobre uma equipe	Team Admin	Aquela única equipe
Gerente de local sobre um local inteiro	Team Admin	Ambas as equipes daquele local (Cozinha + Salão)
Dono / gerente regional (todos os locais)	Admin ou Root	Nenhuma participação em equipe necessária

Duas coisas fazem isso funcionar:

Os membros podem pertencer a várias equipes. É assim que um gerente de local obtém admin sobre os dois departamentos do seu local — adicione-o às duas equipes como Team Admin. Veja teams.md.
Root e Admin veem tudo em toda a conta, independentemente da equipe. O dono não precisa ser adicionado a toda equipe — o escopo de conta já cobre todos os locais. Reserve a participação em várias equipes para os gerentes de local que precisam dela.

Se você só precisa de separação por local (não de local × departamento), simplifique: uma equipe por local (Local A, Local B).

Configurando

Ative teams_enabled (Root, nas configurações da conta) se ainda não estiver.
Crie as equipes — uma por local, ou uma por local × departamento (página Equipes → Criar equipe). Veja teams.md.
Adicione os membros à(s) sua(s) equipe(s) e defina a função de cada pessoa (Team User para a equipe de linha, Team Admin para gerentes). Uma pessoa em várias equipes ganha um seletor de equipe ao criar listas.
Monte as listas de cada local a partir dos seus modelos. Crie a lista a partir de um modelo e depois defina sua equipe como a equipe do local correto. Os modelos são compartilhados em toda a conta, então você monta a lista de verificação uma vez e a carimba por local. Veja tasks.md.
Para rotinas recorrentes, defina a equipe na lista mestre. Toda instância que o cronograma gera herda aquela equipe automaticamente — veja abaixo.

Como as listas recorrentes se comportam entre locais

Uma lista mestre recorrente pertence a uma equipe, e toda instância que ela gera herda aquela equipe. Então uma rotina que roda nos dois locais precisa de uma mestre por equipe de local (ex.: uma mestre de fechamento noturno em Local A — Cozinha e outra em Local B — Cozinha). Monte cada uma a partir do mesmo modelo para mantê-las idênticas.

O mesmo vale para as atribuições: quem estiver atribuído à mestre é copiado para cada instância gerada automaticamente, então você define a equipe fixa de um local na mestre uma vez e toda instância futura a carrega. Veja tasks.md e reminders.md.

Limites a conhecer

Uma pessoa tem uma função por conta, aplicada em todas as suas equipes. Você não pode tornar alguém Team Admin em uma equipe e Team User em outra — se for Team Admin, gerencia todas as equipes às quais pertence. Para a hierarquia usual (gerentes administram seus locais, a equipe trabalha em seu departamento), isso é exatamente o certo; só incomoda se você precisar que alguém gerencie um local, mas apenas trabalhe em outro.
Nenhuma consolidação entre locais além de Root/Admin. Um Team Admin vê apenas suas equipes. A visibilidade e os relatórios em toda a conta são uma visão de Root/Admin (dono). Veja reporting.md e activity-log.md.
As equipes são a unidade de isolamento — não uma fronteira de cobrança ou de dados. Todos os locais compartilham uma assinatura, um diretório de membros, uma biblioteca de modelos/etiquetas/clientes e um histórico de atividades. Se você precisa de cobrança ou dados totalmente separados por local, use contas separadas em vez disso.

Notas de suporte

Se um gerente de local não consegue ver as listas de um local, verifique (a) se ele é membro da(s) equipe(s) daquele local e (b) se as listas realmente têm a equipe correta definida (visível na barra lateral de detalhe da lista). Listas sem equipe só são visíveis para o criador e para o Root. Veja teams.md.
Se as instâncias recorrentes em um novo local não estão carregando a equipe certa, verifique a equipe e as atribuições da lista mestre — as instâncias herdam ambas da mestre ao serem geradas, então as correções vão na mestre (e se aplicam a instâncias futuras; as já geradas são editadas individualmente).
Renomeando um local: renomeie a equipe (página Equipes). As listas existentes mantêm sua associação automaticamente.
Fechando um local: excluir sua equipe remove a equipe e suas participações, mas não as listas ou tarefas — reatribua ou arquive essas listas primeiro se quiser tirá-las do rol ativo.
Donos que “não encontram o recurso de Locais”: não existe um — este padrão baseado em equipes é a configuração de vários locais. Aponte-os para este guia.