Configuração herdada num SaaS: como definir valores predefinidos e exceções

Num SaaS B2B, uma definição pode afetar toda a plataforma, uma organização ou apenas uma pessoa. Se cada nível tiver valores diferentes e a interface não explicar qual deles se aplica, surgem surpresas: utilizadores com comportamentos diferentes, administradores sem controlo sobre uma política e equipas de suporte obrigadas a investigar configurações ambíguas.

A configuração herdada resolve este problema quando as decisões têm uma hierarquia real. O objetivo não é acrescentar níveis antecipadamente, mas determinar quem deve decidir cada definição, que exceções fazem sentido e como comunicar o valor efetivo. Um modelo explícito evita que a flexibilidade se transforme num conjunto difícil de manter de regras especiais.

Quando faz sentido introduzir herança

A herança é útil quando existe uma relação estável entre os níveis de decisão. Por exemplo, o produto pode disponibilizar um valor predefinido; o administrador de uma organização pode adaptá-lo às suas políticas; e cada utilizador pode personalizá-lo para o seu trabalho, desde que essas escolhas não contrariem uma obrigação organizacional.

Não é necessário criar uma hierarquia para todas as definições. Se um valor for individual e não depender de uma política comum, uma preferência do utilizador pode ser suficiente. Se tiver de ser igual para todos por motivos de segurança, talvez só deva poder ser configurado por uma pessoa autorizada na organização. Acrescentar níveis desnecessários aumenta o trabalho de conceção, gestão de permissões, testes e suporte.

Antes de implementar, identifique a decisão associada a cada campo. Pergunte quem é responsável, quem precisa de uma exceção e quais são as consequências de uma alteração. Se não conseguir responder com clareza, mantenha a definição simples até existir um caso que justifique a herança.

Escolher os níveis com base em quem toma cada decisão

Um modelo comum distingue três níveis:

• Predefinição do produto: oferece um comportamento inicial coerente, aplicável às organizações que não escolheram outro valor.
• Organização: permite ao administrador adaptar a configuração a processos, políticas ou necessidades partilhadas.
• Utilizador: permite personalização individual quando esta não entra em conflito com a decisão da organização.

Estes níveis não são obrigatórios. Acrescente um nível apenas se existir alguém que precise de tomar essa decisão e tenha as permissões adequadas. Nas organizações de maior dimensão, pode haver diferentes funções administrativas, mas isso não significa necessariamente que devam tornar-se novos níveis de configuração: muitas vezes, basta definir quem pode editar as definições da organização.

Também convém separar preferências de políticas. Uma preferência costuma permitir uma escolha individual, como uma opção de visualização. Uma política exprime uma regra que a organização pretende impor. Confundir as duas leva a permitir que uma preferência pessoal substitua uma decisão que deveria ser obrigatória.

Definir explicitamente a precedência e as exceções

Uma regra fácil de explicar é a de que prevalece o valor aplicável mais específico: primeiro o do utilizador, depois o da organização e, por fim, a predefinição do produto. Mas esta regra só funciona se a definição puder ser substituída em todos esses níveis. Restrições de segurança ou conformidade podem exigir outra lógica: a organização fixa um valor obrigatório e o utilizador não o pode alterar.

Por isso, defina a precedência para cada tipo de definição, em vez de a apresentar como uma promessa universal. Para cada campo, documente o valor base, os níveis que podem ser editados, quem pode substituí-lo e se uma política pode impedir a edição. A interface e a lógica do servidor devem aplicar a mesma regra; ocultar um controlo no ecrã não substitui a validação de permissões no servidor.

É útil distinguir entre «sem valor próprio» e «valor igual à predefinição». No primeiro caso, a definição é herdada e pode mudar quando o nível superior se alterar. No segundo, existe uma escolha explícita que deve ser preservada. Se o sistema tratar estas situações como equivalentes, não conseguirá explicar corretamente a origem do valor nem preservar a intenção do utilizador.

Mostrar o valor efetivo e a sua origem

Quem administra precisa de saber tanto qual é o valor ativo como quem o determina. Mostrar apenas o valor final oculta se este foi herdado ou escolhido explicitamente. Em contrapartida, uma etiqueta como «Herdado do produto» ou «Definido pela organização» torna a origem visível e reduz as dúvidas sobre o que acontecerá se o valor for editado.

Disponibilize ações adequadas ao nível de permissões: alterar o valor, repô-lo para voltar a herdar ou consultar por que motivo não pode ser editado. Se a organização tiver definido uma política, explique que a definição está bloqueada e indique o nível ou a função que a pode alterar. Evite mensagens que sugiram que existe uma opção disponível quando o utilizador não tem autorização para a aplicar.

Quando o utilizador repõe uma definição, confirme o efeito de forma concreta: o valor deixará de ser uma exceção e passará a seguir a configuração superior. Se a herança puder mudar mais tarde, explique-o. Assim, evita-se que «repor» seja interpretado como fixar para sempre o valor atualmente apresentado.

Gerir alterações sem apagar exceções

Alterar a predefinição do produto deve afetar quem herda esse valor, não quem escolheu uma exceção explícita. O mesmo se aplica quando uma organização altera a sua configuração: os utilizadores que herdam dessa organização devem acompanhar o novo valor; quem tiver uma escolha própria só deverá ser afetado se essa exceção for permitida e a ação estiver claramente definida.

Antes de implementar uma alteração, identifique os registos que representam valores herdados e os que representam decisões explícitas. Não deduza a intenção apenas porque o valor armazenado coincide com a predefinição atual. Preserve o estado de herança para que o sistema possa recalcular o valor efetivo após uma atualização.

Se o produto precisar de alterar o comportamento predefinido, comunique que grupos serão afetados e o que acontecerá às exceções. Quando for adequado, permita que a organização reveja a alteração antes de esta ser aplicada. Para operações administrativas importantes, registe quem alterou a definição e quando, de acordo com as necessidades de suporte e auditoria do produto.

Testar combinações, permissões e casos-limite

Os testes devem abranger mais do que o valor habitual. Verifique cada combinação de níveis: todos herdam, a organização escolhe uma opção, o utilizador cria uma exceção e uma política organizacional bloqueia essa exceção. Confirme também o que acontece quando um valor é eliminado ou reposto e quando a predefinição superior é alterada.

• Permissões: confirme que cada função pode ver e editar apenas o que lhe compete.
• Consistência: verifique se a interface, as API e os processos internos obtêm o mesmo valor efetivo.
• Atualizações: assegure-se de que a alteração de um nível afeta quem herda esse valor sem substituir escolhas explícitas.
• Dados em falta: defina o resultado quando um valor não existe ou uma configuração antiga não contém o campo.
• Explicabilidade: confirme que a aplicação consegue mostrar a origem do valor e o motivo de um bloqueio.

Um sinal de conceção deficiente é a equipa de suporte não conseguir responder a «porque é que esta pessoa vê este valor?» sem inspecionar manualmente várias tabelas. Outro é os administradores não saberem se uma alteração afetará utilizadores específicos. Se estes sintomas surgirem, reveja o modelo e a apresentação da origem antes de acrescentar mais exceções.

Lista de verificação para uma hierarquia sustentável

1. Atribua um responsável e uma finalidade a cada definição.
2. Defina os níveis necessários e elimine os que não tenham um caso claro.
3. Especifique a precedência, as permissões, os bloqueios e as regras de exceção para cada campo.
4. Represente separadamente o valor efetivo e o estado de herança.
5. Explique a origem do valor e o que implica repô-lo.
6. Teste alterações nos níveis superiores, as permissões e as configurações incompletas.
7. Documente que exceções o sistema preserva e como são auditadas as alterações relevantes.

Uma boa configuração herdada não oferece o maior número possível de opções: torna claro quem decide, o que é herdado e quando uma exceção é válida. Se cada definição tiver uma regra compreensível e verificável, o produto poderá evoluir sem transformar as suas preferências numa fonte constante de conflitos.