Configuração de módulos
Configuration items
O registo-base universal para ativos, artigos de conhecimento e serviços reserváveis — orientado por templates que decidem que campos aparecem.
Atualizado em 23/01/2026
Configuração · Módulos · 4.1
Um configuration item (CI) é o registo-base universal para tudo o que regista e que não seja um ticket, reserva ou tarefa: ativos da empresa, artigos de conhecimento, serviços reserváveis. Três mundos diferentes na mesma estrutura de dados — o que os distingue é a classe e o template que escolhe.
Porque é relevante para o negócio
"Utilizador final confrontado com 50 campos"
O template do CI determina a visibilidade dos campos — só aparecem as perguntas certas.
"Ativos, serviços e KB misturados"
A classe (Asset · Service · Knowledgebase) separa o comportamento — fluxos diferentes, mesmo módulo.
"Parceiros externos veem ativos internos"
O template está ligado a um grupo — quem não consegue ver o template não consegue escolher o CI.
"Sem nomenclatura consistente"
Valores por defeito + valores permitidos no template → uniformidade sem o impor à força.
Três classes determinam o comportamento
Asset
Objeto padrão sem funções especiais. Ativo da empresa, viatura, licença de software.
Service
Objeto reservável. Restrições e regras de restrição decidem quando e por quem pode ser reservado.
Knowledgebase
Artigo de conhecimento. Apresentado automaticamente em tickets cujo título/classificação coincide.
Os templates decidem que perguntas aparecem
Ao criar um CI, o utilizador escolhe primeiro um template. Esse template decide: que campos estão visíveis, quais são editáveis, o valor por defeito e os valores permitidos.
| Pergunta padrão | O que determina |
|---|---|
| Nome · Descrição | Identificação do objeto. |
| Organização · Localização | A que pertence o CI — alimenta o encaminhamento e os filtros. |
| Classe | Asset · Service · Knowledgebase. Determina o comportamento. |
| Scope | Apenas Knowledgebase — onde o artigo pode aparecer. |
| Tipo de CI | Decide qual workflow se aplica (ver Building Blocks → Workflows). |
| Classificação | Categorização — alimenta o reporting e o matching da KB. |
| Parent · Child | Hierarquia entre objetos (p. ex. licença sob a aplicação). |
| Tags · Anexos | Pesquisabilidade e documentos relacionados. |
Campos personalizados? Adicione-os através dos custom fields (ver Building Blocks).
Que decisões irá tomar?
De que templates precisa?
Um por tipo de registo: portátil, monitor, licença de software, serviço de reunião, incidente de KB, …
Quem pode usar que template?
Gate por grupo do template — os utilizadores finais veem uma lista mais curta do que os administradores.
Que campos ocultar?
Não relevantes para a classe → torne-os invisíveis em vez de os deixar em branco.
Vale a pena definir valores por defeito?
Reduz erros — p. ex. classificação preenchida automaticamente no template "Portátil".