> For the complete documentation index, see [llms.txt](https://help.glpi-project.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.glpi-project.org/documentation/12-en/overview/template-management-in-glpi.md).

# Template management in GLPI

## Introduction

For certain types of objects in GLPI, it is possible to create new objects (computers, for example) using predefined templates. A template defines a creation model where certain fields are either fixed or calculated using a function. For example, in the case of a computer, a function could calculate the inventory number.

Template management is accessible via the *Templates* button located in the menu bar.

***

## Assets

For assets, the template defines a default standard object where certain fields are pre-filled and can be reused later to create new objects. This significantly simplifies the addition of a large number of objects that are almost identical.

As an example, to prepare the inventory of 20 identical printers where only the serial number and inventory number differ:

* First, a template corresponding to this printer model would be created.
* In this template, all fields that will not change are filled in (manufacturer, model, etc.).
* The 20 printers will then be created from this template.

When creating a new printer from this template, the serial number and inventory number are the only fields to enter; the other fields are already defined.

You can retroactively create a template from an asset using the "Create a template" action from the "Actions" menu in an asset's form.

### Increment

An automatic filling and incrementing mechanism is provided for certain fields that can be identified by the . These fields (name, inventory number, etc.) are then automatically completed when the object is created. To use this mechanism, the corresponding field in the template must contain a string following a syntax described below.

The string in the field:

* must start with the character `<` and end with the character `>`.
* can contain the following special characters which are automatically replaced:

  > * `\g` searches for the number in all identical fields based on the same format;
  > * `#`: is replaced by a counter with as many digits as there are consecutive `#` characters;
  > * `\Y`: is replaced by the 4-digit year;
  > * `\y`: is replaced by the 2-digit year;
  > * `\m`: is replaced by the month;
  > * `\d`: is replaced by the day.

For example, when creating a printer, it is possible in the printer template to use this mechanism to automatically generate inventory numbers.

Suppose we want an inventory number in the format: `YEAR+MONTH+DAY+fixed code structure equal to 555 + fixed operation code equal to 1234 + 2-DIGIT COUNTER`; then the inventory number field in the template will be: `<\Y-\m-\d-555-1234-##\>`.

With each printer creation, the first printer will have its inventory number as `1984-JAN-02-555-1234-01`, the second printer as `1984-JAN-02-555-1234-02`, and so on.

***

## Ticket Templates

As with inventory objects, templates are available for tickets. A ticket template allows you to customize the ticket creation interface based on the ticket type and category.

The behaviors that can be modified are:

* The list of mandatory fields for creating the ticket;
* The list of fields whose value is pre-defined;
* The list of fields that will be hidden.

{% hint style="info" %}
For mandatory field control, only fields available in the user interface will be checked. Therefore, if a field is set as mandatory but is not visible in the interface, it will not trigger an error. When defining mandatory fields, the interfaces in which these fields are used are displayed.
{% endhint %}

A template is attached to the entity where it was created and can be visible in sub-entities.

Default templates can be defined at the entity level or at the profile level. For profiles, only templates from the root entity that are visible from sub-entities can be attached.

Default templates can also be defined by ticket category.

When creating a ticket, the template used is, in order of priority:

1. First, the template defined in the selected category and type.
2. Then, the default template for the user's current profile.
3. Finally, the default template for the ticket creation entity.

{% hint style="warning" %}
In the last two cases, if the template defines a new type/category pair, then the first case is tested again with these new values.
{% endhint %}

{% hint style="info" %}

* When updating a ticket, the same priority order is applied to determine mandatory fields.
* If any of the entity, profile, type, or category parameters are modified while filling out the ticket, the template to be used is then searched again according to these new values.
* The template is used to create [recurring tickets](broken://pages/204fa67c2b73329887eaef04628f7ee8861c806f#recurrent-tickets).
  {% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://help.glpi-project.org/documentation/12-en/overview/template-management-in-glpi.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.