Selo de estado:
GA-candidato· Atualizado em 2026-09-06. Fonte de estado: matriz de estados do produto (Organization → N Workspaces; portfólio multi-CNPJ). Limite atual do produto = Preview.
A Organização é uma camada administrativa acima do workspace, para agências, BPOs e grupos multi-CNPJ que gerenciam vários clientes/empresas.
Conceitos#
- Organização: agrupa N workspaces. É puramente estrutural — administra quais workspaces existem e quem os administra, sem nunca conceder acesso aos dados de nenhum deles.
- Workspace: unidade de isolamento real (datalake dedicado, pessoas, plano, cobrança). O acesso a dados sempre exige membership no workspace.
- Portfólio multi-CNPJ: dentro do modelo, é possível organizar múltiplos CNPJs, apps e audiências.
Disponibilidade#
- Planos: todos. A camada de organização é núcleo.
- Estado:
GA-candidato(modelo e migração provados por testes).
Permissões#
org_admin(papel de organização): administra a estrutura — cria/vincula workspaces, gere membros da org, ajusta configurações da org (açõesorg.*).org_adminNÃO tem acesso automático a dados de nenhum workspace. Para ver dados, precisa ser membro/owner daquele workspace específico.- A verificação de organização é fail-closed: contexto de org ausente → negado; organização divergente do recurso alvo → negado (isolamento entre orgs).
Configuração (passo a passo)#
- Crie a organização (nome; slug e dono opcionais).
- Vincule workspaces existentes à organização (apenas associa; não move dados).
- Atribua o papel
org_admina quem vai administrar a estrutura. - Para dar acesso a dados de um workspace, adicione a pessoa como membro daquele workspace (ver Usuários e permissões).
Vincular/desvincular workspace é auditado e nunca apaga o workspace nem seus
dados — desvincular só solta o vínculo (organizationId = null).
Validação#
- A visão administrativa da org lista todos os workspaces da org.
- A visão "somente com acesso" lista apenas os workspaces onde a pessoa é owner ou membro ativo/convidado — comprovando o anti-cross-access.
- Vínculos aparecem no log de auditoria (
organization.attach/organization.detach).
Exemplo#
O Grupo Aurora (organização) tem dois workspaces: Aurora Varejo e
Aurora Atacado. João é org_admin: ele cria e vincula workspaces e gere quem os
administra, mas não vê os dados de vendas de nenhum dos dois — para isso,
precisaria ser membro do workspace. Maria é membro só de Aurora Varejo: ao listar
a org, ela recebe apenas Aurora Varejo.
Custo#
- Criar/gerir organização e vínculos: R$ 0 (não consome processamento).
Segurança#
- Isolamento entre organizações e entre workspaces é fail-closed.
- A org não é um atalho para dados: separação estrita entre "administrar a estrutura" e "acessar dados".
- Toda mudança estrutural é auditada e escopada pelo workspace afetado.
Limites#
- A organização não compartilha datasets entre workspaces.
- Isolamento entre clientes "provado em produção" ainda é pendente (validação IAM em nuvem — claim #13). O desenho é fail-closed; a certificação de nuvem não ocorreu hoje.
Troubleshooting#
| Sintoma | Causa provável | O que fazer |
|---|---|---|
org_admin não vê dados de um workspace | comportamento esperado | adicione a pessoa como membro do workspace |
| "Organização divergente — ação negada" | recurso pertence a outra org | opere dentro da org correta (isolamento) |
| Workspace não aparece na lista | pessoa sem membership | confirme membership ativo naquele workspace |
| "Contexto de organização ausente" | ação org.* sem org no contexto | acesse pela org correta |
Próximos passos: Usuários, grupos e permissões.
Estado & evidência: e = GA-candidato; isolamento em produção =
pendente (claim #13). Fonte: matriz de estados do produto.