Como decisões de processo, responsabilidade e arquitetura foram transformadas em uma solução real sem depender de um pacote de funcionalidades pré-definido.
O cenário
Um grupo de usuários externos precisava consultar informações da plataforma sem receber a mesma visão de um usuário interno. Além disso, cada pessoa estava vinculada a unidades específicas e não deveria enxergar dados de contextos aos quais não pertencia.
Por que um login não era suficiente
Autenticação responde quem é o usuário. O problema real era autorização: depois de entrar, quais módulos, unidades e informações aquele perfil poderia acessar? Resolver apenas o login deixaria a regra mais importante fora do sistema.
A solução construída
Foi estruturado um portal com perfil específico, departamento/contexto próprio e acesso segmentado por unidade. A experiência foi desenhada para apresentar somente os módulos aplicáveis e as informações correspondentes aos vínculos daquele usuário.
Provisionamento como parte do processo
A criação de contas passou a ser tratada como operação controlada. Usuários foram provisionados com os vínculos corretos e depois ativados em um fluxo separado. Essa separação reduz o risco de liberar acesso antes de todas as permissões estarem configuradas.
Experiência e governança
A visão do portal foi ajustada para desktop e mobile, mantendo navegação simples e capacidade de consolidar informações quando o perfil tinha acesso a mais de uma unidade. A regra de autorização permanece independente da interface: esconder um item do menu não substitui controle de acesso no backend.
O aprendizado do case
Portais externos exigem mais do que uma tela bonita. Identidade, vínculo, autorização, escopo de dados e experiência precisam representar a relação real entre aquele usuário e a organização. Esse é um exemplo de como regra de negócio se transforma diretamente em arquitetura.