Esta questão ocorre frequentemente após atualizações, quando a plataforma reforça de forma mais rigorosa as relações entre tabelas de escolhas (choices) e os dictionary overrides. Como o campo u_rd_origem está definido no nível da tabela Task [task], o sistema espera um comportamento consistente em todas as tabelas estendidas, a menos que sejam definidas escolhas específicas para cada tabela ou um override adequado no dicionário.
Para resolver isso e garantir que as opções corretas apareçam em cada módulo, recomenda-se a seguinte abordagem:
1. Utilizar Escolhas Específicas por Tabela (O Caminho Recomendado) Em vez de depender apenas do campo 'Dependent value' no nível da Task, a melhor prática é definir as escolhas especificamente para as tabelas estendidas:
-
Acesse o registro de Dictionary do campo u_rd_origem.
-
Verifique a lista relacionada de Choices.
-
Certifique-se de que a coluna 'Table' para cada escolha corresponda exatamente à tabela de destino: problem para as escolhas de Problema e change_request para as escolhas de Mudança.
-
Isso respeita o 'DNA do ITIL' ao manter as tabelas estendidas distintas, embora compartilhem uma estrutura pai comum.
2. Configurar Dictionary Overrides Se definir as escolhas por tabela não for suficiente, deve-se utilizar um Dictionary Override:
-
No registro de dicionário do campo u_rd_origem, vá para a lista relacionada de Dictionary Overrides.
-
Crie uma entrada para a tabela problem e outra para a tabela change_request.
-
Marque a caixa 'Override dependent' ou 'Override attributes' se estiver usando dependências ou atributos específicos para filtrar a lista.
3. Visão Estratégica de Governança Do ponto de vista de Arquitetura Empresarial, esta situação reforça a importância da Governança de Dados (Pilar 5). Quando um campo customizado é criado no nível da Task, ele gera uma dependência 'concreta' em todo o ecossistema de ITSM.
-
O Objetivo: Migrar do conceito de 'corrigir o erro' para o 'design focado na sustentabilidade'. Usar escolhas específicas por tabela é uma solução muito mais segura para futuras atualizações (upgrade-safe).
-
Como enfatizado na metodologia Now Create, as implementações devem ser Orientadas ao Valor. Uma classificação de dados limpa garante que os relatórios e análises de Mudança e Problema permaneçam precisos e confiáveis.
Resumo: Certifique-se de que suas escolhas estejam mapeadas diretamente para as tabelas problem e change_request na tabela sys_choice, em vez de apenas usar a tabela task com um valor dependente. Este é o estado 'TO-BE' mais resiliente para a saúde da sua plataforma.
Para mais orientações arquiteturais sobre gestão de tabelas estendidas e dictionary overrides, a metodologia Now Create oferece excelentes estruturas de trabalho: ServiceNow Now Create: Practical Methodology
