GLPI ticket templates and predefined fields

How GLPI ticket templates shape every request

Most service desks lose time before any work starts, because tickets arrive without the details needed to route or prioritize them. GLPI ticket templates fix this at the point of entry: they decide which fields a requester must fill in, which ones are hidden, and which ones arrive already set. In GLPI, a template can be tied to an entity, a category and a request type, so a password reset, a hardware fault and a new starter request each present a form suited to that work. Without templates, categories are guessed by the requester, urgency is chosen inconsistently, and the SLA has to be corrected by hand after the ticket is opened.

Teams usually need templates once they have more than a handful of request types or more than one entity sharing a helpdesk. The template is the place to make a field mandatory, to hide internal fields from requesters, and to predefine values such as the category, urgency or SLA that the ticket should carry. Templates do not replace the rest of the routing logic. Business rules still run against tickets and can assign groups, categories and SLAs, so the team must decide which values the template sets and which values the rules are allowed to change. Confirm in your own test instance how a predefined value interacts with a later rule before you rely on either one, since the precedence between them determines whether your SLA clock starts correctly.

Plan the template set from the request catalog first: list each category and request type, the fields the resolver needs at intake, and the SLA that applies to each. Then check whether your GLPI version handles template-driven SLA fields the way your documentation describes, and confirm the behavior with a sample ticket for each template. Keep the list of templates short enough that administrators can maintain it, and record who owns each one so changes to categories or SLAs are reflected in the forms.

Template field behaviors and when each fits

This table compares mandatory, hidden, predefined and default field behaviors in GLPI ticket templates, along with how templates are assigned by entity, category and request type. Read each row for the situation it fits and the side effect it can cause, such as blocked submissions or hidden data that routing rules depend on. Confirm exact behavior for each field in your own GLPI version before relying on it.

Behavior	When it fits	What it can break
Mandatory field	Data the service desk always needs at intake, such as a category, a request type or a contact reference used for routing or reporting	Blocks submissions from users who lack the information, and can push people to enter placeholder values that pollute reports
Hidden field	Fields that matter to technicians but add noise for requesters, such as internal urgency or internal assignment hints	Routing rules or SLA logic that read a hidden value may see nothing if the value is never set, so confirm the rule still fires
Predefined field	Values that should be set the same way for every ticket in a category or request type, such as a fixed category or a standard SLA	A predefined value can override what a requester or business rule expects, so check which one wins in your version
Default field	A sensible starting value that requesters or technicians can still change, such as a default priority or a default type	Defaults that are too broad get left unchanged, so downstream reports and escalations treat many tickets alike
Assignment by entity	Organizations that run several entities with different intake forms, such as separate customers, business units or sites	Templates scoped to one entity do not apply to tickets created in another, so confirm entity inheritance in your setup
Assignment by category	Standard forms for a service area, such as hardware or access requests, where the same fields always apply	Changing a category later can leave tickets with fields that no longer match the template
Assignment by request type	Separating incidents from service requests when each needs different mandatory or predefined fields	Requesters who pick the wrong type may face fields that do not fit their case, so keep request type labels clear
SLA fields in templates	Setting a standard SLA or OLA at creation so the clock starts from the right target	Predefined SLA values can conflict with business rules that assign SLAs later, so test the order of evaluation before rollout

Templates for incidents, service requests and changes

Incident templates serve the requester who reports something broken and the technician who must restore service against a time-to-own and time-to-resolve target. The template should make the fields that drive priority mandatory for the requester, while leaving the free-text description open so people can explain symptoms in their own words. Urgency and category are the fields that most directly shape SLA targets, so they should be predefined or constrained rather than left to guesswork.

Urgency and impact: Make urgency mandatory for end users with clear choices, so priority and the SLA it feeds are set at creation.
Category: Predefine a category set that maps to your SLA and routing rules, and hide categories that no end user should choose.
Affected item: Keep the asset or service field visible but optional, so technicians can link the record when the requester does not know it.
Technician-only fields: Hide root cause and resolution fields from the requester form and show them only to technicians who work the ticket.
Description guidance: Keep the description open, with a short prompt that asks for symptoms, start time and who is affected.

Confirm in your own GLPI version which template fields are available on each profile and how SLA fields are populated from the template before you publish the form.

Setting up ticket templates in GLPI

This sequence moves from a list of request types to tested templates that show, hide or prefill the right fields for each requester group. The result is a set of templates, assigned to the right profiles and categories, where SLA fields are set before a ticket reaches a technician.

Inventory request types and categories
Start by listing the request types your service desk actually receives, such as access requests, hardware faults, software installs and change-related work, and map each one to a ITIL category already defined in GLPI. Include the entity each group of requests belongs to, because templates are scoped per entity. Ask the service owners to confirm which requests need a different priority, urgency or service level. The step is done when every request type has one category, one owning entity and one service owner recorded in a shared sheet.
Decide mandatory, hidden and predefined fields
For each request type, decide which fields the requester must complete, which should stay hidden because technicians fill them later, and which should carry a fixed default. Typical examples include making the location mandatory for hardware faults, hiding the internal cost field from requesters, and predefining the urgency and the SLA for a given category. Confirm the SLA and OLA names you intend to use with the team that owns them, since template defaults must match existing objects. The check is a field matrix with one row per field and one column per request type, reviewed and signed off by the service desk lead.
Create templates per entity and request type
In GLPI, create a ticket template for each request type in the entity that owns it, using the ticket template configuration in the administration menu. Add the predefined fields, mark the mandatory fields and set the hidden fields according to your matrix. Give each template a name that tells administrators the entity and request type, so they can be told apart later. Keep the number of templates small, since every extra template is one more thing to maintain after upgrades. The check is a list of templates per entity, with each one matching a row in the field matrix.
Assign templates to profiles and categories
Attach each template to the profiles that should use it, and to the categories where it is the default, so a requester who opens a new ticket lands on the correct form. Check which profiles can see which entity, because a template only helps users who can reach the entity it belongs to. Remember that a template defines the form, while business rules can still change values after submission, so record which values rules are allowed to override. The check is a short table of profile, entity, category and template, confirmed against the live configuration.
Test with a requester account
Sign in as a requester from each affected entity and open one ticket for every request type. Confirm that mandatory fields block submission when empty, that hidden fields do not appear, and that predefined values are present and correct. Try to submit a ticket with missing data to verify the mandatory rule is enforced. Record the results per template in a test log. The check is a completed test log with a pass or fail result for every template and requester profile tested.
Test with a technician account and confirm SLA fields
Sign in as a technician and open the test tickets created in the previous step. Confirm that the SLA and OLA fields are populated as predefined, that the due dates appear, and that the ticket is visible to the right group. Check that the technician can still update fields that were hidden to requesters, and that business rules do not overwrite the values you set. If any SLA field is blank, review the template and the SLA definition before going further. The check is a test ticket where the SLA fields show the expected values after submission and after one technician update.
Document and hand over the templates
Write a short guide for the service desk that lists each template, its entity, its category, its mandatory fields and the SLA it sets. Note who owns each template and the process for requesting changes, so that future edits go through the same field matrix. Ask the service owners to confirm the guide and store the test log with it. Before any future GLPI upgrade, plan to retest these templates, since the form and field behavior should be verified on the target version. The step is done when the guide, the owner list and the test log are stored together and approved.

Predefining SLA fields without breaking the clock

A predefined urgency, impact or category value in a ticket template can decide which SLA and OLA a ticket receives, so template defaults and business rules must be designed together. When a template sets these fields, GLPI treats the value as the starting point for the ticket. Any business rule that later assigns an SLA, an OLA, a priority or a category then competes with that starting value. If the template is set to lock a field, a technician may be unable to correct it when the request turns out to be different from what the form assumed. The result is a ticket that runs against the wrong clock, or against no clock at all. Before you lock anything, list which fields feed SLA and OLA selection in your own configuration, and confirm in your GLPI version how templates and business rules order their updates on new and existing tickets.

The most common failure is a hidden or predefined field that silently holds a value a technician needs to change. For example, a template that fixes urgency to a low level for a general request category may keep a password reset or a service outage on the wrong priority, and the priority matrix then computes a target time that does not match the business impact. Hidden fields are harder to spot than mandatory ones because nobody sees them in the form. Ask your service owners which combinations of category, request type and impact should never be pre-set, and keep those fields visible and editable. Where a template must fix a value, document why and who may override it.

Test every template against the priority matrix configuration that is live in your instance, not against a default or a copy from a test environment. Create one ticket per category and request type, submit it with each template, and check the resulting priority, SLA, OLA, calendar and time-to-own and time-to-resolve targets in the ticket. Then change urgency and impact manually and confirm the targets recalculate as you expect. Repeat the check after any change to the matrix, the SLA definitions or the business rules. Keep the test results with your change record, since they are the evidence that the clock starts when you intend it to.

Where template designs go wrong

Most ticket template problems do not appear on the day the template is built. They appear weeks later, when users start working around required fields, when a business rule quietly overrides a value, or when an upgrade changes behavior nobody retested. The cards below describe the symptoms to watch for and the control to put in place for each.

Mandatory fields that invite junk input

When every field is mandatory, users fill gaps with placeholder text such as a dash, a single letter or the word test, and the data later breaks reporting and SLA categorization. The symptom is a rising share of tickets with meaningless descriptions or identical filler values. Make mandatory only the fields that routing, SLA selection or the approver actually needs, and review the ticket data every quarter for filler patterns.

Templates that conflict with business rules

A template can preset a priority, category or SLA while a business rule later changes the same value, or the reverse. The symptom is tickets whose SLA differs from what the template promised, and support staff who cannot explain why. Before go-live, document which object wins for each field, then test sample requests from every template against the rule set in a non-production instance.

Category trees that drift from templates

Templates are usually bound to a category, and categories get renamed, split or moved as the service catalog changes. The symptom is a template that still loads but applies the wrong fields, or a category with no template at all. Assign a named owner to the category tree, and review template-to-category mappings whenever the tree changes.

Duplicated templates across entities

Teams often copy a template into each entity and then edit the copies separately. The symptom is the same request type behaving differently in two entities, and a fix in one place that never reaches the others. Keep one master template per request type, use entity-specific rules only where a real difference exists, and record every intentional deviation in the change log.

Changes not retested after an upgrade

Template behavior depends on the GLPI version, and field handling can change between major releases. The symptom appears after an upgrade, when a mandatory field stops saving or a predefined value is ignored. Keep a test script that submits one ticket per template, checks the stored values and SLA dates, and run it on a staging copy before every GLPI update. The GLPI update procedure is the place to start.

Template edits that affect open tickets

Changing a template does not always change tickets that already exist, so staff may see different fields on new and old tickets for the same request type. The symptom is reports that mix two field layouts and support questions about missing data. Announce template changes with an effective date, decide whether open tickets need manual correction, and check the reporting views before and after each change.

Questions teams ask before building GLPI templates

How long does GLPI ticket template work take and what drives the duration?

Duration depends mostly on how many categories, request types and SLA combinations the templates must cover, not on the template screens themselves. Each category and request type needs its own mandatory fields, hidden fields and predefined values, and each of those needs a test ticket to confirm it behaves as intended. Teams with a settled category tree and a single SLA matrix move faster than teams that are still deciding who owns each request type. Ask any partner to show how the scope is broken down into categories and what each one will be tested against before accepting a fixed timeline.

Can our internal staff build GLPI ticket templates themselves?

Yes, a GLPI administrator with access to the setup menus can create templates, and the work is largely configuration rather than code. The harder part is the decisions behind the configuration: which fields are truly mandatory for each request type, which values should be predefined, and how those choices interact with SLAs and routing. Internal teams usually succeed when they already have an agreed catalog and an administrator who can test changes in a non-production instance. If that catalog does not exist yet, a partner can help define it, and your team can then maintain the templates afterward.

What does the partner need from us before template work starts?

The partner needs four inputs to scope the work accurately:

A request catalog listing every type of request users submit and who submits it
A category tree showing how categories nest and which teams own each one
An SLA matrix with the response and resolution targets agreed for each priority or service level
Sample tickets, ideally anonymized, that show how real requests are written and where they go wrong today

Missing any of these usually adds discovery work to the engagement, and it is worth confirming the expected format with the partner before the scope is signed.

How do ticket templates interact with business rules and SLAs?

Templates set starting values when a user opens a ticket, while business rules can change those values later when conditions match. This means a predefined field can be overwritten by a rule, and an SLA field set in a template may not be the final SLA the ticket receives. Teams should decide in advance which layer owns each value, document the rule order, and test edge cases such as a ticket created through email or the API, which may not pass through the same template. Confirm the exact precedence in your GLPI version's documentation before finalizing the design.

Which template settings should we retest after a GLPI upgrade?

Retest every template that sets a mandatory field, a hidden field or an SLA value, because upgrades can change form behavior and plugin interactions. Pay particular attention to plugins that add their own fields or forms, since the GLPI update procedure suspends plugins after a new version is detected and they must be reactivated after major updates. Keep a set of test tickets for each category and request type, run them on a staging copy after the update, and compare the stored field values and SLA assignments with the expected results. Follow the update steps in the GLPI installation documentation, including the database and key backups, before starting.

Who is responsible for template ownership after the project ends?

Ownership should be assigned to named roles before the project closes, because templates drift as categories and services change. A typical split gives service desk leads ownership of request types and required fields, SLA owners ownership of predefined SLA values, and the GLPI administrator ownership of the configuration itself. Without a change process, templates often grow inconsistent, so agree who approves a change and how it is tested. Ask any partner whether ongoing maintenance is covered by a retainer or left to your team.

Does hiding a field in a template improve data quality or create gaps?

Hiding a field reduces noise for users, but it can also hide information that technicians later need for reporting or routing. A field hidden from requesters should still have a predefined value or a clear rule that fills it, otherwise tickets may reach reporting with blank data. Review each hidden field against the reports and SLA statistics you rely on, and test that the values still appear where analysts look for them. This review is usually one of the more valuable steps in the design phase.

Limits to confirm in your environment

Ticket templates touch mandatory fields, SLA assignment and category logic, so a template that looks right in a demo can behave differently in your version, entity tree or plugin set. The cards below list what to test on a non-production GLPI instance before templates reach the service desk. Treat each item as a question for the vendor documentation or your own test results, not as a settled capability.

Field behavior in your exact version

Mandatory, hidden and predefined settings are implemented per field and per release, so the behavior you document for GLPI 11 may not match a point release or the GLPI 12 line. Build a short test matrix: for each category and request type, create a ticket as a requester, as a technician and through the API, then record which fields are required, hidden or pre-filled. Repeat the test after every upgrade. Confirm which GLPI version your instance runs before you trust any screenshot or tutorial, including this page.

Template scope across entities

A template is attached to a specific context, and entity inheritance decides which tickets it applies to in a multi-entity tree. Check whether a template defined at the root entity reaches child entities, whether a child entity can override it, and what happens to tickets opened by users who belong to several entities. Test one ticket from each entity level. Without this check, a mandatory SLA field may appear for one customer and vanish for another.

SLA and OLA fields set by templates

Predefined SLA and OLA fields interact with business rules that assign or override those same values after the ticket is saved. Confirm the order in which the template, the rules engine and manual edits apply, and whether a rule can replace a value the template filled in. Also confirm that a template-set SLA starts the expected clock and that pending status behaves as your SLA design expects. Record the result in your test notes before go-live.

Interaction with custom forms and plugins

Forms, custom fields and third-party plugins may add fields or change the ticket form, and a template may not reach them. Verify whether template-defined fields still apply when a request is created through a form, an email receiver, an API call or a plugin form. Also check whether a plugin update resets field visibility. List every plugin in use and test each intake path that produces tickets for your teams.

Behavior after the GLPI 10 to 11 move

The move to GLPI 11 changed how some forms and generic assets are handled, so older templates and plugin-based fields may need rework or may not carry across unchanged. Export your current template definitions, rebuild them in a staging copy of the upgraded instance, and compare the results with your production behavior. Plan this check as part of the upgrade, not after users report missing fields.

Permissions and who can edit templates

Template changes affect every requester and technician in scope, so confirm which profiles can create, edit and delete templates and whether changes are logged. Test whether a delegated administrator can alter a template that also governs another entity. Keep a documented owner for each template family and restrict edit rights to that owner's group.

How DeployOpen scopes GLPI template work

Template work is scoped in writing before any template is built. The written scope names the request types in play, the entities and categories each template serves, which fields are mandatory, hidden or predefined for each one, and which SLA and OLA assignments the templates must carry. Anything outside that list, such as business rules that later overwrite template values, escalation logic or email intake, is either agreed as a separate item or left out in the document. Ask for this written scope to name the GLPI version it targets, because field behavior and the forms that sit beside templates have changed between releases, and confirm with the vendor documentation which version your instance runs.

The request type inventory is the working step that drives the rest of the engagement. DeployOpen's team walks through how requests actually arrive, usually from the service desk, the business owners of each category and a sample of closed tickets, and records for each request type the information the technician needs on the first touch. The inventory shows where templates would conflict, for example two categories that want opposite mandatory fields, or a predefined SLA that a routing rule would change anyway. Your team should bring the people who close tickets, not only the ones who designed the categories, because the gaps show up on the closing side.

A test plan and handover close the work. Each template is tested by creating tickets from the entity and profile that will use it, checking which fields appear, which are required, and which SLA values are set, then confirming that the same ticket still reads correctly after a business rule runs. The handover includes the template inventory, the test results, the decisions taken and a short operating note for administrators. Ongoing support, including changes to templates as request types evolve, can be taken on under a retainer, which is a separate written agreement. Ask any provider how changes after handover are priced and approved before you sign.