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 Plataforma → 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 Plataforma → 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.

Minerando padrões agora

As sugestões de autopreenchimento vêm da contagem diária do histórico, que roda de madrugada. Quem acabou de carregar casos num tenant (uma demonstração, um piloto com histórico importado) ou quem quer conferir o aprendizado não precisa esperar o dia seguinte. Na listagem, a ação Minerar padrões de um tenant ativo refaz essa contagem na hora.

• A contagem roda em segundo plano. A resposta só confirma que ela começou, e as sugestões mudam em alguns minutos.
• Só existe uma mineração por vez na plataforma. Se a noturna ou outra pedida agora estiver rodando, a tela avisa que já há uma em andamento. Tente de novo quando ela terminar.
• Não chama IA nem consome cota de tokens: são contagens sobre decisões reais.
• A ação só aparece para tenants ativos e só para o Super Admin.

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 Plataforma → 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.

Retenção de dados

Em Administração → Retenção de dados, o Admin do tenant (ou o Super Admin com o tenant escolhido) decide por quanto tempo a empresa guarda três coisas que a plataforma apaga sozinha, toda noite:

Tabela	O que sai	O que nunca sai
Histórico de processos e casos	instâncias encerradas há mais que a janela, com atividades, tarefas, variáveis e comentários	instância em andamento
Reservas de etapa de IA	o registro de cada tentativa de uma etapa de IA, depois de terminada	a reserva de uma instância que ainda roda; a cobrança do consumo de IA não muda
Execuções de robô	execuções terminadas, com o log	a última execução de cada robô

Apagar é definitivo

Nada é arquivado antes. O que sai não volta — nem pela tela, nem pelo suporte. Se uma obrigação de auditoria pede mais tempo, escolha uma janela maior ou desligue a tabela.

Para cada tabela há três escolhas:

• Padrão da instalação — vale o que o operador configurou (por padrão, desligado: nada é apagado). Se o operador mudar o padrão depois, a empresa acompanha.
• Desligado — guardar tudo — nada daquela tabela é apagado para esta empresa. Quando a instalação define um máximo, a opção continua no cartão, mas desabilitada: a tabela não pode ser guardada para sempre.
• Apagar depois de N dias — o que for mais antigo que N dias sai na próxima noite.

O número de dias fica entre o mínimo e o máximo da instalação, mostrados no cartão de cada tabela (por padrão, mínimo de 90 dias para o histórico, 7 para as reservas e 30 para as execuções, sem máximo). Um valor fora disso não é aceito. Se o operador mudar os limites depois, a noite ajusta a janela salva ao limite novo e o cartão avisa que a escolha está fora dos limites — salve de novo para deixar explícito.

Enquanto você edita, o cartão mostra a prévia: quantas linhas a próxima noite removeria com aquela janela. É uma estimativa — cada noite remove até um teto por tabela, e o que sobra sai nas noites seguintes. Sem edição em curso, a prévia mostra a janela que a noite usa de fato: uma escolha salva que ficou fora dos limites aparece já ajustada ao limite, e Desligado sob um máximo aparece com o máximo — o cartão só diz que nada é apagado quando nada é apagado mesmo.

Cada mudança fica registrada em Últimas mudanças: quem mudou, qual tabela, de quê para quê e quando. Modelador, gerente e usuário não veem a tela nem conseguem mudar a janela.

O operador da instalação pode desligar a escolha por empresa (RETENTION_ALLOW_TENANT_CHOICES=false). Nesse caso a tela avisa no topo, as opções ficam travadas e vale a janela da instalação para todas as empresas — uma escolha salva antes fica guardada, mas é ignorada até o operador religar.

Visão do Admin do tenant

Se você é Admin (mas não Super Admin), você não vê a lista de todos os tenants: os grupos Plataforma e Catálogo global nem aparecem na sua barra lateral, e as telas deles não abrem pelo endereço. 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 da empresa 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 de Processo, Tipos Documentais, Robôs, API Keys, Webhooks e a Retenção de dados. Alterar membros do seu tenant é pedido ao Super Admin.