Cada empresa é um tenant isolado: catálogo, configuração, configurações regionais, módulos e relações são administrados nesse contexto. Este guia aborda o que configurar e como revisar o impacto de uma alteração, respeitando os limites documentados.
Antes de começar
- Função: use uma autorização de plataforma para administrar empresas e as configurações globais permitidas. O Superadministrador pode selecionar uma empresa ativa; o Administrador opera com escopo global somente dentro da empresa em que tem vínculo de associação. Essas camadas não são intercambiáveis.
- Módulo: Administração da empresa. Os módulos habilitados ou desabilitados pertencem à configuração de cada empresa.
- Pré-condições: identifique a empresa de destino e confirme que a ação corresponde ao seu contexto. Para a operação normal, a empresa deve estar no estado
active. Os estados documentados para uma empresa são exclusivamenteprovisioning,active,suspended,disablededeprovisioned.
A empresa efetiva não é escolhida livremente no navegador de um usuário comum: ela é determinada pela sessão, pelo vínculo de associação e pelo contexto da empresa. Alterar identificadores ou parâmetros do cliente não permite mudar de tenant.
O que é configurado no contexto da empresa
A configuração do tenant reúne nome, estado operacional, modo de implantação, parâmetros, configurações regionais, módulos habilitados e nomes de host associados. Essas propriedades delimitam a operação; os dados de negócio e de administração continuam associados ao tenant.
As configurações regionais afetam a interface disponível e o idioma padrão da empresa. Elas não traduzem nem alteram automaticamente nomes, definições ou descrições que a organização tenha registrado como conteúdo de negócio.
Os módulos determinam quais áreas podem operar. A aplicação oculta rotas e acessos de um módulo desativado, e o backend rejeita suas consultas e alterações. Portanto, habilitar uma opção na navegação não substitui a validação de permissões, e ocultar uma opção não deve ser interpretado como exclusão de dados. Os dados existentes de um módulo desativado são preservados; ficam fora da operação visível até uma eventual reativação, sujeitos às funções, ao escopo e ao estado dos dados.
Exemplo sintético: uma empresa pode manter ativo o módulo de Repositórios de dados e deixar temporariamente desativado o de Regras de qualidade. O repositório e seus metadados continuam sendo objetos da empresa; não se deve presumir que as regras são excluídas nem que podem ser operadas enquanto o módulo estiver desativado.
Percurso recomendado
- Delimite a decisão. Defina se configurará a empresa, as configurações regionais ou os módulos. Para ações de plataforma, confirme a empresa ativa; para uma ação de tenant, verifique o vínculo de associação e a autorização.
- Revise o estado e o impacto. Uma empresa inativa não é usada para a operação normal. Antes de modificar módulos, identifique os objetos e percursos dependentes. A administração apresenta os registros que ficarão ocultos antes da confirmação.
- Configure com uma sequência coerente. Uma adoção progressiva começa pela taxonomia e pelo acesso, continua com os repositórios e o Dicionário técnico e, depois, incorpora termos, qualidade, ativos, produtos, contratos, workflows, KPI, políticas e exploração. É um percurso funcional, não um formulário nem uma lista de estados.
- Valide as dependências. O Dicionário técnico depende dos Repositórios; as Regras de qualidade exigem ambos para a operação completa. Produtos e Contratos exigem objetos relacionados. Uma dependência desativada pode ocultar, limitar ou rejeitar a função dependente.
- Verifique o efeito autorizado. Revise acessos, rotas, capacidades e escopo. Uma verificação visual não substitui os controles do backend.
Limites que convém confirmar
Uma regra de qualidade pode existir sem SQL gerado. Para gerar SQL, é necessária uma associação válida com um campo físico e um dialeto configurado; essa condição não implica a execução automática do SQL. Da mesma forma, a sincronização de metadados registra uma agenda manual, diária, semanal ou mensal e snapshots versionados, mas a agenda efetiva depende da configuração da empresa. A presença dessas opções não permite presumir que existam tarefas produtivas habilitadas ou scans em execução.
Riscos e controles tampouco são módulos de catálogo independentes no estado atual. Um controle pode ser documentado por meio de uma regra de qualidade, uma política ou procedimento, um workflow, uma aprovação, uma classificação, uma certificação ou uma tarefa; não se deve criar a expectativa de inventários autônomos de “Riscos” ou “Controles”.
Resultado esperado
A empresa fica configurada em seu próprio contexto, com configurações regionais e módulos coerentes com seu escopo operacional. Os módulos desativados não podem ser usados nem por acesso direto à rota; seus dados anteriores não são excluídos automaticamente, e as operações continuam sujeitas ao estado da empresa, ao vínculo de associação, à capacidade e ao escopo. A configuração, por si só, não concede acesso entre empresas.