Building Blocks
Champs personnalisés
Ajoutez des champs supplémentaires aux tickets, CI, emplacements, utilisateurs et organisations — sans code sur mesure, pour que la structure reste dans la plateforme et non dans un Excel.
Mis à jour le 23 janv. 2026
Configuration · Building Blocks · 3.2
Les champs personnalisés (aussi appelés « champs configurables » ou « champs libres ») vous permettent de capturer des informations propres à votre organisation sur les tickets, configuration items, emplacements, utilisateurs et organisations — sans code sur mesure. Bien les configurer une fois vous offre des années de données cohérentes et de reporting.
Pourquoi cela compte pour le métier
« Je veux reporter sur X qui n'existe pas dans les champs standard »
Les données sectorielles (classe amiante, zone ATEX, classification RGPD) appartiennent à la fiche, pas à un Excel parallèle.
« Différents types de tickets, différentes questions »
Un incident demande la « gravité », une demande d'accès demande la « date de fin ». Des champs personnalisés par modèle.
« Infos obligatoires à la création »
Marquez un champ obligatoire et vous évitez les tickets incomplets qui reviennent de toute façon plus tard.
« Lien vers un autre objet »
Un champ de recherche pointe directement vers une autre entité (projet, fournisseur, actif) — pas de texte libre.
Les deux types de champs
Champ standard
Texte, nombre, date, liste déroulante, case à cocher. Pour des valeurs autonomes capturées sur une fiche. Fonctionne partout : rapports, filtres, exports.
Champ de recherche
Référence un autre objet dans Gfacility (par ex. un projet, un actif, un utilisateur). Évite les doublons et les fautes de frappe.
Le mécanisme
Un champ est toujours délimité par module. Vous le définissez de façon centrale puis vous l’activez par module :
- Helpdesk et Configuration items : également par modèle — un formulaire d’incident peut comporter des champs différents d’une demande d’accès.
- Emplacements · Utilisateurs · Organisations : un seul ensemble de champs par entité — pas par modèle.
- Obligatoire/facultatif et actif/inactif : configurables pour pouvoir retirer des champs sans perdre de données.
Quelles décisions allez-vous prendre ?
Quels modules reçoivent quels champs ?
Tous les champs n'ont pas leur place partout. Des choix délibérés évitent l'inflation des formulaires.
Standard ou recherche ?
Référence à des données existantes → recherche. Texte libre → standard.
Obligatoire ou facultatif ?
Obligatoire = qualité de donnée mais ajoute de la friction. En cas de doute, demandez-vous : pourrai-je quand même reporter si ce champ est vide ?
Spécifique à un modèle ?
Pour le helpdesk/CI : délimitez les champs à des modèles précis plutôt qu'à l'ensemble du module.