Gerenciamento de Tenants

Nível de acesso requerido

Criação e gerenciamento global: Super Admin.
Gerenciamento do próprio tenant: Admin.

O que é um tenant?

Um tenant representa uma empresa ou organização no Flowi Agentic. Cada tenant tem seus dados completamente isolados: processos, tarefas, usuários vinculados e configurações são exclusivos daquele tenant.

Listagem de tenants (Super Admin)

Acesse Global (Super Admin) → Tenants para ver todas as empresas cadastradas, com status, data de criação e ações disponíveis. Esse grupo da barra lateral só aparece para quem é Super Admin.

Status de um tenant

Status	Descrição
CREATING	Provisionamento em andamento (automático, leva alguns segundos)
ACTIVE	Operacional — aceita usuários e dados
SUSPENDED	Bloqueado temporariamente — dados preservados
DEACTIVATED	Desativado — sem acesso, dados preservados
FAILED	Falha no provisionamento — verifique os logs

Criando um tenant (Super Admin)

1. Acesse Global (Super Admin) → Tenants
2. Clique em Novo tenant
3. Preencha:
   • Slug — identificador único da empresa: 3 a 63 caracteres, apenas letras minúsculas, números e _ (ex.: empresa_abc). Hífen é recusado. Não pode ser alterado após a criação.
   • Nome — nome de exibição da empresa
4. Clique em Criar

O tenant é criado com status CREATING. O provisionamento é assíncrono — aguarde o status mudar para ACTIVE (geralmente alguns segundos).

Tenant que nasce sem os processos fica FAILED

O provisionamento instala automaticamente os Templates Globais marcados como auto-provisionamento. Se algum deles não puder ser implantado, o tenant termina em FAILED e a mensagem de erro nomeia os templates que ficaram de fora — em vez de virar um tenant ACTIVE sem os processos que deveria ter. Corrija o template global e crie o tenant de novo.

Vale igual para as tabelas de decisão (DMN) marcadas como auto-provisionamento: uma tabela que o motor recusar leva o tenant a FAILED, com a chave dela na mensagem. Um tenant ACTIVE sem a decisão que um processo usa só aparece bem depois, quando a primeira instância chega na regra de negócio e falha longe de quem criou o tenant.

Slug imutável

O slug é usado como nome do schema no banco de dados e não pode ser alterado após a criação. Escolha com cuidado.

Suspendendo e reativando

• Suspender: bloqueia o acesso dos usuários do tenant. Os dados são preservados.
• Reativar: restaura o acesso normalmente.

Use a opção correspondente no menu de ações do tenant.

Exportação e restauração (Super Admin)

O detalhe do tenant tem duas ações no fim do ciclo de vida, reunidas no painel Exportação de conteúdo do tenant e restauração (Avançado): gerar o arquivo do schema da empresa e restaurar um arquivo gerado antes. Esse arquivo não é um backup do tenant — o que ele leva e o que fica de fora está em Exportação de conteúdo do tenant, mais abaixo.

Baixar export de conteúdo (.sql) roda pg_dump limitado ao schema tenant_<slug> e devolve um .sql em texto puro, sem dono e sem privilégios (--no-owner --no-privileges). É o arquivo que Fazer Upload e Restaurar (.sql) espera receber de volta.

Fazer Upload e Restaurar (.sql) não executa o arquivo enviado como veio. Antes de qualquer coisa o dump é lido inteiro e recusado se contiver uma construção que escreva fora do tenant. A recusa nomeia a construção e a linha, para o erro ser corrigido e não investigado:

Restore recusado: o dump contém alteração de search_path na linha 12 — SET search_path TO public

O que é recusado:

Construção	Por quê
SET search_path, ou set_config('search_path', …) que não seja o reset para vazio que o próprio pg_dump escreve	Redireciona escrita sem schema para fora da empresa
CREATE SCHEMA de qualquer schema que não seja o do tenant restaurado	Cria dados fora da empresa
DROP SCHEMA, ALTER SCHEMA	Apaga ou renomeia schema — inclusive o public
CREATE/ALTER/DROP ROLE, USER ou GROUP, SET ROLE, SET SESSION AUTHORIZATION e GRANT de papel	Deixa acesso ao banco que sobrevive ao restore
COPY … FROM PROGRAM / COPY … TO PROGRAM	Executa comando no servidor do banco
CREATE EXTENSION	Extensão é do cluster inteiro, não é dado da empresa
Metacomandos do psql (\!, \i, \connect, …)	\! é um shell e \i inclui outro arquivo

O que continua passando sem problema: todo arquivo que o próprio botão Baixar export de conteúdo (.sql) gerou. Os dados de um COPY não são inspecionados — uma página, um prompt ou um campo cujo texto seja DROP SCHEMA public CASCADE; é conteúdo da empresa, não comando, e o restore não se confunde com isso. O corpo de uma função ($$ … $$) também não é inspecionado, porque definir a função não é executá-la.

O comando roda amarrado ao schema do tenant (SET search_path TO "tenant_<slug>" passado por fora do arquivo), com ON_ERROR_STOP=1 e em uma transação só: ou o dump inteiro entrou, ou nada entrou. Um restore que morre no meio volta como erro, com o trecho da saída do psql que explica a falha — nunca como sucesso.

Restaure um dump que este produto gerou

A verificação recusa as construções que transformam um restore de dados em administração do banco. Ela não é uma caixa de areia: um dump que nomeia outro schema explicitamente (INSERT INTO public.…) é uma instrução comum de SQL, indistinguível dos dados da própria empresa. Por isso a restauração continua sendo exclusiva do Super Admin e a orientação é restaurar o arquivo que saiu do botão Baixar export de conteúdo (.sql), não um .sql de origem desconhecida.

Consumo de IA

A aba Consumo de IA do tenant mostra, para o período escolhido, quem gastou dentro daquele cliente e em qual etapa de processo. As duas tabelas exportam para CSV.

O período é filtrado por atalho (7, 30 ou 90 dias, mês atual, mês anterior) ou por intervalo livre. Atenção a uma diferença que parece erro e não é: a cota do tenant conta o ciclo de faturamento e não acompanha esse filtro — ela responde quanto já foi faturado neste ciclo, enquanto as tabelas respondem quanto foi gasto no período escolhido.

O detalhe de cada coluna, e o que significa uma linha sem pessoa atribuída, está em Governança de Inteligência Artificial.

Membros

A seção Membros do tenant controla quais usuários têm acesso à empresa e com qual papel.

Adicionando um membro

1. Abra o detalhe do tenant (clique no nome do tenant)
2. Na seção Membros, clique em Adicionar membro
3. Busque o usuário pelo nome ou e-mail
4. Selecione o papel (role):
   • Admin — administra a empresa: catálogo de processos, papéis, tipos documentais, robôs, chaves de API e webhooks
   • Gerente — enxerga todas as instâncias e tarefas da empresa, acompanha o processo por etapa, escreve no CMS e na documentação dos processos. Nos demais módulos se comporta como Usuário
   • Modelador — desenha, configura e publica processo: modelador BPMN/CMMN e versões, formulários, tabelas de decisão, papéis de processo, variáveis do processo, tipos documentais, bases de conhecimento e agentes de IA, e a regra de e-mail que inicia o processo. Usa o copiloto do modelador. Não administra a empresa — pessoas, robôs, chaves de API, webhooks e caixas de entrada de e-mail continuam só com o Admin —, e em execução enxerga o mesmo que um Usuário
   • Usuário — executa tarefas, e só enxerga as instâncias em que entra
5. Clique em Adicionar

O Modelador gasta a cota de IA da empresa

O copiloto do modelador e a validação por IA consomem os tokens da empresa, então dar esse papel a alguém é autorizar um gasto sem que a pessoa seja administradora. O relatório de governança mostra o consumo por usuário, e existe teto por pessoa — hoje ele é configurado pelo Super Admin, em Administração → Usuários.

Removendo um membro

Na lista de membros, clique em Remover na linha do usuário. O usuário perde o acesso ao tenant imediatamente.

Papéis de processo

Além do papel geral, cada membro pode ter papéis de processo — papéis específicos de um determinado processo que determinam quais tarefas ele recebe.

Para atribuir:

1. Na linha do membro, clique em Papéis de Processo
2. Em Atribuir Novo Papel, escolha o papel e o processo em que ele vale
3. Clique em Atribuir

Exportação de conteúdo do tenant

Na tela de detalhe do tenant há Exportação de conteúdo do tenant e restauração (Avançado). O botão Baixar export de conteúdo (.sql) gera um arquivo SQL com o conteúdo do schema daquele tenant.

Isto não é um backup

O arquivo não restaura o tenant a um estado anterior. Ele leva só o que mora no schema do tenant; tudo o que é operacional mora no schema compartilhado e fica de fora.

O que entra no arquivo:

Conteúdo	Tabelas
CMS — coleções, campos e registros	cms_collections, cms_collection_fields, cms_records
Formulários — definições, versões e fontes de dados	form_definitions, form_versions, form_data_sources
Anexos e documentos	attachments
Variáveis do tenant	tenant_variables
Falhas de tarefas de IA	ai_task_failures
Instâncias de teste	test_instances
Base vetorial (RAG)	vector_store

O que não entra:

• processos em andamento, tarefas, jobs, temporizadores e todo o histórico — as tabelas ACT_* do motor ficam no schema compartilhado, um único conjunto para todos os tenants;
• agentes de IA, robôs, runners, chaves de API, webhooks, notificações, definições publicadas, tipos documentais, configurações do tenant, cotas de IA e o log de uso de IA — todas também no schema compartilhado, separadas apenas por uma coluna tenant_id.

O próprio arquivo começa com um cabeçalho que repete essa lista, para que ele continue se explicando mesmo depois de sair da tela que o gerou. Um backup completo da plataforma continua sendo o backup do banco inteiro, feito pela infraestrutura — não por esta tela.

Visão do Admin do tenant

Se você é Admin (mas não Super Admin), você não vê a lista de todos os tenants: o grupo Global (Super Admin) nem aparece na sua barra lateral. A tela de detalhe do tenant — membros, papéis de processo, exportação de conteúdo — também não: ela é atendida por endpoints que exigem Super Admin, então o item Configurações não aparece para você e a URL redireciona para o Dashboard.

O que o Admin do tenant administra hoje é o que tem tela própria: Catálogo de Processos, Papéis (Roles), Tipos Documentais, Robôs, API Keys e Webhooks. Alterar membros do seu tenant é pedido ao Super Admin.