Gfacility

Building Blocks

Campos personalizados

Acrescente campos de dados extra a tickets, CIs, localizações, utilizadores e organizações — sem código personalizado, para que a estrutura fique na plataforma e não no Excel de alguém.

Atualizado em 23/01/2026

Configuração · Building Blocks · 3.2

Os campos personalizados (também chamados “campos configuráveis” ou “campos livres”) permitem capturar informação específica da organização em tickets, configuration items, localizações, utilizadores e organizações — sem código personalizado. Configurados bem uma vez, garantem anos de dados consistentes e relatórios fiáveis.

Porque é que isto importa para o negócio

"Quero reportar sobre X que não está num campo padrão"

Dados específicos do setor (classe de amianto, zona ATEX, classificação RGPD) pertencem ao registo, não a um Excel sombra.

"Tipos de ticket diferentes precisam de perguntas diferentes"

Um incidente pergunta "severidade", um pedido de acesso "válido até". Campos personalizados por template.

"Informação obrigatória na criação"

Marque um campo como obrigatório e evita tickets incompletos que vão de qualquer forma voltar.

"Ligar a outro objeto"

Um campo lookup aponta diretamente para outra entidade (projeto, fornecedor, ativo) — sem texto livre.

Os dois tipos de campo

Campo padrão

Texto, número, data, dropdown, checkbox. Para valores autónomos que se capturam num registo. Funciona em todo o lado: relatórios, filtros, exportações.

Campo lookup

Referencia outro objeto no Gfacility (por exemplo, um projeto, ativo, utilizador). Evita dados duplicados e gralhas.

O mecanismo

Um campo tem sempre âmbito por módulo. Define-se centralmente e ativa-se por módulo:

  • Helpdesk e Configuration items: também por template — um formulário de incidente pode ter campos diferentes de um pedido de acesso.
  • Localizações · Utilizadores · Organizações: um conjunto de campos por entidade — não por template.
  • Obrigatório/opcional e ativo/inativo: configurável para poder descontinuar campos sem perder dados.

Que decisões irá tomar?

Que módulos recebem que campos?

Nem todos os campos pertencem em todo o lado. Escolhas deliberadas evitam formulários inchados.

Padrão ou lookup?

Referenciar dados existentes → lookup. Texto livre → padrão.

Obrigatório ou opcional?

Obrigatório = qualidade de dados, mas adiciona fricção. Em caso de dúvida, pergunte: ainda consigo reportar mais tarde se for deixado em branco?

Específico do template?

Para helpdesk/CI: limite o âmbito dos campos a templates específicos em vez de todo o módulo.