# Règles métier pour les tickets Les règles métier vous permettent de modifier automatiquement les attributs d'un ticket lorsqu'il est **créé** ou **mis à jour**. Chaque règle possède un ensemble de **critères** (conditions à satisfaire) et d'**actions** (modifications à appliquer). Les règles sont évaluées dans l'ordre ; lorsqu'une règle correspond, ses actions sont appliquées et l'évaluation continue avec les règles restantes -- sauf si la règle inclut l'action **Arrêter le traitement des règles**, qui interrompt immédiatement l'évaluation. *** ### Quand les règles sont déclenchées Chaque règle est configurée pour se déclencher à la création, à la mise à jour, ou aux deux. **À la création** -- tous les critères de la règle sont évalués par rapport aux valeurs soumises. **À la mise à jour** -- seules les règles qui ont au moins un critère correspondant à un **champ qui a réellement changé** sont évaluées. Cela évite des réapplications involontaires lors de la sauvegarde de modifications non liées. Trois exceptions rendent toujours une règle éligible à la mise à jour, même si le champ n'a pas littéralement changé : * Un **utilisateur demandeur** a été ajouté ou supprimé -- les règles utilisant `Emplacement du demandeur`, `Groupe du demandeur` ou `Profil` sont réévaluées. * Un **champ de date de création de calendrier** (`_date_creation_calendars_id`) est présent -- il n'a pas de valeur stockée à comparer, il est donc toujours considéré comme modifié. * Le **groupe d'actifs** (`_groups_id_of_item`) ou l'**emplacement du demandeur** (`_locations_id_of_requester`) sont des champs dérivés sans valeur stockée ; même comportement. Les champs suivants sont **toujours disponibles** dans les critères lors de la mise à jour (en tant que filtres secondaires) même s'ils n'ont pas été modifiés -- ils sont injectés avec leur valeur stockée actuelle afin que vous puissiez définir la portée des règles par entité, priorité ou statut de validation : * `entities_id` * `priority` * `global_validation` (lorsque les approbations sont activées) Si aucun des critères de la règle ne correspond à un champ modifié, la règle est **entièrement ignorée**. *** ### Configuration multi-entités Les règles sont organisées par entité. Dans une configuration multi-entités, lorsqu'un ticket est traité, GLPI évalue d'abord les règles des entités parentes, puis l'entité propre du ticket. La permission **Règles métier (parent)** contrôle si un utilisateur peut voir les règles héritées des entités parentes. Dans la liste des règles d'une entité, trois sections sont affichées : * **Règles appliquées (nom de l'entité)** -- règles des entités parentes qui s'appliquent ici (visibles uniquement avec la permission *Règles métier (parent)*). * **Règles locales** -- règles définies directement sur l'entité actuelle. * **Règles applicables dans les sous-entités** -- règles de l'entité actuelle qui s'appliqueront également aux entités enfants. *** {% hint style="warning" %} **Urgence, impact et priorité** Si une règle définit l'Urgence ou l'Impact, ajoutez une action **Recalculer la priorité** dans la même règle afin que la Priorité soit mise à jour de manière cohérente. Sans cela, la Priorité conserve sa valeur précédente. {% endhint %} {% hint style="info" %} **À la mise à jour : seuls les champs modifiés déclenchent les règles** Une règle configurée pour "à la mise à jour" n'est évaluée que lorsqu'au moins un de ses critères correspond à un champ qui a réellement changé lors de la sauvegarde actuelle. Les champs qui n'ont pas changé sont ignorés par le moteur, même si la règle les liste comme critères. Exception : `entities_id`, `priority` et `global_validation` sont toujours disponibles en tant que **critères secondaires** pour affiner la portée d'une règle, mais ils ne déclencheront jamais une règle à la mise à jour à eux seuls. {% endhint %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://help.glpi-project.org/documentation/fr/modules/administration/rules/ticketbusinessrules.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.