When GLPI native forms replace custom request intake
GLPI native forms let a service desk build structured request intake inside the GLPI 11 core, so users submit well-formed requests instead of describing problems in email or opening ad hoc tickets that technicians must triage by hand. Teams that previously built intake around FormCreator should first check whether their form needs fit the native editor, because the core now carries the interactive form editor and the answer-to-ticket mapping that intake depends on. The GLPI 11 announcement lists integrated forms with an interactive editor among its features, so the decision is less about whether the capability exists and more about which requests are worth moving and what the migration costs in your environment. This page covers three areas: the interactive editor where forms are designed, how each answer is mapped to a ticket field such as category, urgency or assignee, and how technician-only questions are added. Technician-only questions are the main reason many teams reach for the Advanced Forms plugin. According to the Advanced Forms plugin documentation, that plugin adds technical questions visible to technicians but not to users, a capability previously provided by FormCreator. Before committing, confirm with your own GLPI administrator which of your existing FormCreator forms rely on that behavior and which can run on the core editor alone.
Start with an inventory of the requests you receive by email today. Group them by how much structure each one needs. A password reset or a new laptop request may need only a few fields, while an application access request may need an approver, a system name and a data classification. Requests that are simple and frequent are usually the first candidates for native forms, since their answers map cleanly to ticket fields. Requests that depend on hidden technical details, or that must stay unclear to end users, need a decision on whether the Advanced Forms plugin is part of the design from the start. Plan the mapping before building any form. Each question should have a clear target on the resulting ticket, and each target should be a field your technicians already use for routing and reporting. Unmapped answers end up in ticket descriptions, where they are hard to search and report on. Confirm the plugin's current compatibility with your GLPI 11 release before you rely on it, and record the decision in your change plan, because forms, plugins and the upgrade path to later GLPI versions all affect the same intake process.
Which form approach fits which intake need
Use native GLPI 11 forms when every question is meant for the requester and each answer maps cleanly to a ticket field. The interactive editor sits in the core, so the form is built, changed and published without adding a plugin to your upgrade path. This is the usual starting point for access requests, hardware orders and standard change asks, where the requester supplies the facts and a technician works from the ticket that results.
- Requester-visible questions only: Everyone who submits the form sees every field, so keep the wording plain and avoid internal routing vocabulary.
- Answer-to-ticket mapping: Decide which answers fill the ticket title, category, urgency and description so technicians receive consistent tickets.
- Covered by core upgrades: Native forms follow the same backup and update steps as the rest of GLPI, which keeps the maintenance plan simpler.
- Simple branching: Confirm which conditional options the editor offers in your target version, and document any complex rule before building it.
Check that each question has a named owner who will act on the answer, and test the mapping with one sample submission per request type.
Use the Advanced Forms plugin when intake needs technical questions that technicians can see and requesters cannot. Typical examples include internal classification, asset identifiers or impact notes that help triage but would confuse or expose information to the person submitting the request. The plugin is a separate component, so the decision adds a version to track alongside the GLPI core. Treat it as part of the platform, not as a one-off add-on.
- Hidden technical fields: Capture internal values such as asset tags or triage notes that requesters should never see.
- Extra component to maintain: The plugin must be compatible with your target GLPI version, backed up with the rest of the instance and reactivated after major updates.
- Visibility testing: Sign in as a standard requester and confirm that technician questions do not appear in the portal, the form or the ticket view available to that user.
- Named ownership: Assign a team to each technician question, since those answers drive triage and assignment.
Confirm plugin compatibility in the Advanced Forms documentation before you plan the build, and record which questions are hidden from requesters.
If your instance already runs FormCreator forms, plan their move before upgrading. GLPI 11 brings forms into the core, and the Advanced Forms plugin covers the technician-only questions that FormCreator handled. Each existing form needs a decision: rebuild it in the core editor, keep a plugin-based version, or retire it. Skipping that review often leaves live request paths broken after the upgrade.
- Form inventory: List every FormCreator form with its owners, its last use and the ticket types it creates.
- Field-by-field comparison: Rebuild each form in the new editor and compare its fields and ticket mapping against the original.
- In-flight requests: Decide how open tickets and pending submissions will be handled during the cutover.
- Plugin reactivation: Since GLPI 11 suspends plugins after a new version is detected and they must be reactivated after major updates, schedule that check as a named step.
Ask for a written list of FormCreator features that have no direct equivalent in your target version, and review it with the form owners before the cutover date is set.
Every form approach needs the same verification before users see it. Testing belongs in a separate instance that resembles production, because form behavior depends on the database engine, PHP version and web server layout. The goal is to prove that each request type reaches a technician with the right data and that hidden questions stay hidden. Record the expected results first so the same checks can run after every upgrade.
- Production-like test instance: Run the target version on a copy of production data with the same database engine and document root layout.
- Requester walkthrough: Submit each form as a standard user, including blank, long and unusual answers.
- Ticket review: Check that category, urgency, entity and assignment land as designed.
- Backup before change: Back up the database, the files and the config directory, including
glpi.keyandglpicrypt.key, before editing forms in production.
Write the expected ticket output for each form in a short test script, so the same checks can be repeated after the next GLPI update.
Configuration options and when each fits
This table compares three ways to build request forms in GLPI: core forms, core forms with the Advanced Forms plugin, and FormCreator-era forms that remain in use. Read each row against your own request types and your current installation, because the choice depends on whether technicians need questions that requesters never see. The main takeaway is that the Advanced Forms plugin is the option for technician-only questions, and existing FormCreator forms need a planned move rather than an assumed one.
| Option | What it does | Requester sees | When it fits | What to confirm |
|---|---|---|---|---|
| Core GLPI 11 forms | Builds request forms in the GLPI 11 core with the interactive editor, mapping answers to tickets | Only the questions the form defines | Standard requests where every question can be asked of the requester | Which ticket fields each answer maps to, and that your GLPI version is 11 or later |
| Core forms plus Advanced Forms plugin | Adds technical questions that technicians see but users do not | Public questions only, technician questions are hidden | Requests that need routing data, asset identifiers or internal classification from the technician side | Plugin compatibility with your GLPI version, and who maintains the plugin after upgrades |
| FormCreator-era forms still in use | Forms built with the earlier FormCreator plugin, kept running after the move to core forms | Whatever the existing FormCreator form presents | Installations that already depend on these forms and cannot change them during the current cycle | Whether a migration plan exists and which GLPI 10 to 11 steps and plugin data moves apply |
| Technician-only questions | Captures internal details such as priority, asset tags or triage notes on the request | Nothing, the question is not shown | Triage data that should not be exposed to requesters | Which questions must stay internal and whether they are reported or filtered in ticket views |
| Mapping answers to tickets | Writes form answers into ticket fields, categories or content | The answers they typed, shown as the request | Routing requests to the right queue without retyping data | Each answer has a target field, and mapped values match your ticket categories |
| Forms published as services | Makes a form available through the service catalog | The catalog entry and its form | Self-service request types offered to users in several entities | Catalog enablement per entity and how child entities inherit the setting |
| Dual form inventory | Runs core and FormCreator-era forms side by side during a transition | Whichever form they are directed to | Phased rollouts where some request types move first | Which requesters reach which form, and how duplicate forms are retired |
Building and publishing a native request form
This sequence takes a request form from a planned set of categories to a published, tested entry point in the GLPI 11 core. Each step ends with a check so the requester sees the right questions and the technician receives a ticket with the information needed to act on it.
Confirm the GLPI version and plugin state
Before building anything, the GLPI administrator confirms which GLPI version is running and whether the Advanced Forms plugin is installed and active. GLPI 11 includes integrated forms in the core, so the team does not need to start from FormCreator, but the plugin state must be known before technician-only questions are planned. Record the version, the plugin version and any existing FormCreator forms that could overlap with the new ones. The step is done when the team can name the version, the plugin state and the list of forms already in use. Plugin behavior after upgrades should be checked against the GLPI update documentation before go-live.
Define request categories and required answers
The service owner and the help desk lead agree on the request types users will submit, such as access requests, hardware orders or software installs. For each type, they list the answers the technician needs to act without a follow-up email, and they mark which answers are mandatory. Keep the list short enough that a requester can finish the form in one sitting. The output is a written table with one row per request type and one column per question, reviewed by someone who handles these tickets today. The step is complete when every question has an owner who can explain why it is needed.
Build the form in the interactive editor
An administrator with form rights creates the form in the GLPI 11 core using the interactive editor, adding sections, question types and conditional display where the design calls for it. Use the question labels from the approved table so that wording matches what the help desk expects. Save a draft and keep it unpublished until the mapping work is complete. The check is a review of the form preview: every mandatory question is marked, the order follows the user's path, and no question asks for information the requester cannot reasonably know.
Map each answer to ticket fields
Each form question is linked to the ticket field that will store its answer, such as the title, description, category, urgency or a custom field. Decide in advance which answers feed the ticket title and which go into the description, because technicians rely on these to triage. Confirm that the category and type settings match the routing rules the help desk already uses. The check is a list of question-to-field pairs signed off by the help desk lead. This step is done when no answer is left without a destination, and no ticket field is populated by two questions without a reason.
Add technician-only questions with Advanced Forms
If the triage process needs information that requesters should not see, such as an internal cost code, a risk score or a routing hint, the team adds those questions with the Advanced Forms plugin. These questions are visible to technicians but hidden from users, a capability previously provided by FormCreator. Keep this set small, document why each one exists, and confirm that the answers still reach the ticket. The check is a test on a sample form: the requester view must not show the technician questions, and the technician view must show them.
Test as a requester
A tester with a standard requester profile submits each request type using realistic but non-sensitive data, and then checks the result. The tester confirms that mandatory questions block submission when empty, that conditional sections appear correctly, and that technician-only questions are absent. Review the created ticket content: the title, description, category and any custom fields should match the answers entered. Any mismatch goes back to the mapping step. The step is complete when each request type produces a ticket whose content matches the submitted answers.
Test as a technician
A technician account repeats the same submissions or reviews the tickets created in the previous step. The technician confirms that technician-only answers are present, that routing and assignment rules fire, and that the ticket contains enough detail to begin work without contacting the requester. Ask the technician to note any missing information and to say whether the ticket could be closed or escalated from what is shown. The check is a short written sign-off per request type. Fix gaps in the form or the mapping, then rerun the affected tests.
Publish the form to requesters
Once both tests pass, the administrator publishes the form so requesters can find it, and records the publication date, the GLPI version and the plugin version in the change log. Confirm that the form is visible only to the intended profiles and entities. Keep the unpublished draft available for future edits, and plan a review after the first real tickets arrive. The check is a fresh test submission by a requester account after publication, which should create a ticket identical in structure to the tested one. This closes the sequence.
How requester answers become ticket fields
The mapping decision determines which form answers become structured ticket data and which stay as free text in the description. Category, urgency, requester location and assigned group are the fields that drive routing and reporting, so each one should come from a closed choice or a question with a defined set of answers. Answers that only add context, such as a free-text account of what the user was doing, belong in the description. Before building, list every question in the draft form and mark it as one of three things: a ticket field, a description input or a technician-only question. Confirm in your GLPI 11 version which answer types the native form editor can map to which ticket fields, since mapping options have changed between releases and between the core and the plugin layer.
The main risk is free-text answers driving routing rules. If a rule matches on words typed by a requester, misspellings, abbreviations and vague wording will send tickets to the wrong group or leave them unassigned, and the failure is often silent until a queue starts to fill. Keep routing conditions on structured fields wherever possible, and where a free-text answer must influence routing, test it with realistic submissions before go-live. Treat the form mapping as part of the helpdesk routing design rather than a separate task: the rules that assign groups, set urgency from category and trigger escalation should be written against the same field names the form populates. Ask the team that owns routing to review the mapping table before the form is published.
Ask your implementation partner or GLPI administrator to document the mapping table as a deliverable: form question, target ticket field, allowed values, default when unanswered and the routing rule that consumes it. Check how an unanswered or invalid answer behaves, since a required question left blank can produce a ticket with an empty category. Where a technician needs a question the requester should never see, such as an internal cost code or a triage hint, confirm how the Advanced Forms plugin exposes that question and whether its answer can be mapped to a field without changing what the requester sees. GLPI 11 is out describes the integrated forms, and the Advanced Forms plugin documentation explains technician-only questions. Verify both against your installed versions before finalizing the design.
Security and access considerations for technician-only questions
Technician-only questions sit in the same form as the questions requesters answer, so their safety depends on visibility rules, notification content and the change history around the form. The cards below cover what to decide before publishing and what to test after each change.
Keeping technician answers hidden
A technician-only question is only useful if the requester never sees it on the form, in the submitted ticket or in a copy of the form they reopen later. Confirm how the Advanced Forms plugin decides who sees each question, and test with a requester account rather than an administrator account, since administrators often see more than end users. Record which questions are internal so reviewers can check them later. Ask your partner to show this test on your own instance before go-live.
Profile and entity visibility
Who can see a published form depends on the GLPI profile of the requester and the entity the form is published in. Check which profiles can open the form, whether child entities inherit it, and whether a technician in one entity can reach answers collected in another. Keep the access model for forms in the same design review as your general profile and entity rules, so a form does not quietly widen access to tickets.
Sensitive data and retention
Request forms often collect personal data, account identifiers or details about incidents that should not be widely copied. Decide which fields are truly needed, mark the sensitive ones as technician-only where possible, and agree how long answers stay on the ticket. Confirm with your compliance lead what retention applies to ticket content in your organization, and check how deleted tickets and attachments are handled in your GLPI version.
Testing for leaks in notifications
Hidden answers can leak through email notifications, reminders, satisfaction surveys or the requester portal even when the form itself hides them. For each notification template used by the form, send a test ticket and read the full message, including subject lines and any attached ticket summary. Repeat the check for the portal view after a technician adds a followup. Treat any appearance of a technician-only answer outside the technician view as a blocking defect.
Recording changes to published forms
A form change that adds, moves or re-labels a question can change what requesters submit and what technicians receive. Keep a written record of each published version, including who approved it, the reason and the test results. Store the exported form definition alongside your change tickets so you can compare versions after an incident. Ask your partner how change history is kept during any GLPI upgrade that touches forms.
Questions teams ask before building GLPI request forms
What does building GLPI request forms cost in-house compared with a partner?
Building forms in-house costs the salaried time of the people who design, test and maintain them, while a partner bills for the written scope. The main cost drivers are the number of request types, how many approval paths and technician-only questions each form needs, how many entities publish services, and how many integrations or plugin dependencies are involved. Ask any partner for a quote that lists each form, the questions and routing per form, the test cases, the handover documents and whether ongoing changes are priced separately. Confirm with your own team how many hours each request type will take to design, since no public GLPI figure covers your processes.
How long does it take to design and test a set of GLPI forms?
Duration depends on the number of request types, how settled your approval rules are, and how many stakeholders must sign off on each question set. Teams usually lose more time to unresolved decisions about routing and categories than to the form editor itself. Plan separate phases for requirements with the service desk, building in a test instance, user acceptance with a small group of requesters, and a release window. No public figure is available for this work, so ask a partner to state the phases and the assumptions behind any schedule in the written scope.
What does the service desk owner need to provide for form work?
The service desk owner is the person who decides what each request type must collect and where it goes. They need to supply the list of request types, the required fields for each, the approval chain, the category and assignment rules, and the wording that requesters will see. They also need to approve test cases and accept the forms before release. Without a named owner with decision authority, form work stalls at the first disagreement about routing, so confirm that owner before the scope is signed.
Can a small IT team build GLPI forms without outside help?
A small team can build simple forms with the interactive editor in the GLPI 11 core, especially for a few request types with clear routing. The work becomes harder when forms need technician-only questions through the Advanced Forms plugin, when several entities publish different services, or when ticket mapping must match existing SLAs and approvals. Check whether your team has someone who can test changes in a non-production instance and maintain the forms after go-live. Outside help is most useful for design review, test coverage and documentation.
How do native forms affect a GLPI 10 to 11 upgrade and plugin reactivation?
Forms built on FormCreator belong to a plugin, so they need a planned migration before they can run as native GLPI 11 forms. The GLPI update procedure requires a backup of the database, files and config directory, including the key files, and since GLPI 11.0 plugins are suspended after a new version is detected and must be reactivated after major updates. Plan the order of plugin reactivation, test every form and its ticket mapping after the update, and keep a rollback path. Confirm the current migration steps for your plugin versions with the vendor before you start.
What should a written scope for GLPI forms include?
A written scope should name every request type, the fields and question types for each form, the mapping from answers to ticket fields, the routing and approval rules, and any technician-only questions that need the Advanced Forms plugin. It should list the entities and users who will see each form, the test cases and acceptance criteria, the environments used for build and test, and the handover and documentation deliverables. It should also state what is excluded, how change requests after sign-off are priced, and what support follows go-live. Ask for these items explicitly before comparing quotes.
Do native forms replace the need for plugins such as Advanced Forms?
Not always. The GLPI 11 core provides integrated forms with an interactive editor, but technical questions that only technicians see are covered by the Advanced Forms plugin, a capability previously available in FormCreator. Decide early which questions must stay hidden from requesters and whether the plugin's version fits your GLPI release. Confirm plugin compatibility and its support status with the plugin documentation before you rely on it in production.
Official sources for GLPI 11 forms
Before you design a request form, read the GLPI 11 announcement from the GLPI project. It describes integrated forms with an interactive editor as part of the GLPI 11 core, which is the baseline this topic assumes. Read it against your own instance: confirm which GLPI 11 release you run, since the project publishes point releases after the major version, and check the release notes for the version you plan to deploy. Forms behavior can change between point releases, so note the version you tested against in your build records.
The *Advanced Forms* plugin documentation is the next read for technician-only questions. It explains that the plugin adds technical questions that technicians can see but requesters cannot, a capability previously provided by FormCreator. Use it to confirm which question types, visibility settings and ticket mappings the plugin supports on your target version, and whether your existing FormCreator forms need to be rebuilt rather than carried over. Ask your implementation team to confirm the plugin's compatibility with your planned GLPI version before you commit to a design that depends on it.
How DeployOpen works on this
DeployOpen plans, implements, customizes, documents and supports self-hosted open-source platforms inside your own infrastructure, including GLPI. For native request forms, we start from the services your teams need to offer, then build and test the forms in your GLPI instance before anything reaches end users.
How we scope
- Written scope lists each request form, its answers, and the ticket fields each answer fills
- Scope names which forms need technician-only questions and which plugin work they require
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
- Scope records the GLPI version, database and web server your instance runs on
How we build
- Forms are built in the GLPI 11 core editor on a staging copy of your instance first
- Answer-to-ticket mapping is configured and tested with representative request samples
- Technician-only questions are added with the Advanced Forms plugin where your scope requires them
- Configuration is kept under change control so each form can be reviewed and rolled back
How we hand over
- Handover includes a written record of each form, its questions, mappings and approval routing
- Test results show which requests created which tickets, with the fields populated
- Administrators receive steps for editing forms and publishing changes after handover
- Operating notes cover how forms behave during GLPI updates, including plugin reactivation
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer
- Retainer work can cover form changes as your services and approval rules evolve
- Plugin and GLPI version changes are reviewed against your forms before upgrades are applied
- Ask any provider which GLPI versions and plugin releases they test against before signing
