# Business rules for tickets

Business rules let you automatically modify ticket attributes when a ticket is **created** or **updated**.

Each rule has a set of **criteria** (conditions to match) and **actions** (changes to apply). Rules are evaluated in order; when a rule matches, its actions are applied and evaluation continues with the remaining rules -- unless the rule includes the **Stop rules processing** action, which halts evaluation immediately.

***

## When rules are triggered

Each rule is configured to fire on creation, on update, or both.

**On creation** -- all criteria in the rule are evaluated against the submitted values.

**On update** -- only rules that have at least one criterion matching a **field that actually changed** are evaluated. This avoids unintended re-applications when saving unrelated changes.

Three exceptions always make a rule eligible on update, even if the field did not literally change:

* A **requester user** was added or removed -- rules using `Requester location`, `Requester group`, or `Profile` are re-evaluated.
* A **creation-date calendar field** (`_date_creation_calendars_id`) is present -- it has no stored value to compare against, so it is always considered changed.
* The **asset group** (`_groups_id_of_item`) or **requester location** (`_locations_id_of_requester`) are derived fields with no stored value; same behaviour.

The following fields are **always available** in criteria on update (as secondary filters) even if they were not modified -- they are injected with their current stored value so you can scope rules by entity, priority, or validation status:

* `entities_id`
* `priority`
* `global_validation` (when approvals are enabled)

If none of the rule's criteria match any changed field, the rule is **skipped entirely**.

***

## Multi-entity setup

Rules are organised per entity. In a multi-entity setup, when a ticket is processed, GLPI evaluates rules from parent entities first, then the ticket's own entity.

The **Business rules (parent)** permission controls whether a user can see rules inherited from parent entities.

Within an entity's rule list, three sections are shown:

* **Applied rules (entity name)** -- rules from parent entities that apply here (visible only with the *Business rules (parent)* permission).
* **Local rules** -- rules defined directly on the current entity.
* **Rules applicable in sub-entities** -- rules from the current entity that will also apply to child entities.

***

{% hint style="warning" %}
**Urgency, impact, and priority**

If a rule sets Urgency or Impact, add a **Recalculate priority** action in the same rule so that Priority is updated consistently. Without it, Priority keeps its previous value.
{% endhint %}

{% hint style="info" %}
**On update: only changed fields trigger rules**

A rule configured for "on update" is only evaluated when at least one of its criteria corresponds to a field that actually changed in the current save. Fields that did not change are ignored by the engine, even if the rule lists them as criteria.

Exception: `entities_id`, `priority`, and `global_validation` are always available as **secondary criteria** to narrow the scope of a rule, but they will never act as the sole trigger of a rule on update.
{% 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/modules/administration/rules/ticketbusinessrules.md?ask=<question>
```

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.