Why teams need technician-only questions in GLPI forms
This page covers how to add questions to GLPI native forms that technicians can see and requesters cannot, which is the capability many service desks had through FormCreator before forms moved into the GLPI core in GLPI 11. The work is handled with the Advanced Forms plugin, and the design choices come down to which questions belong to the requester, which belong to the technician, and how the two sets are stored and reported. For most organizations the owner is the service desk lead or the GLPI administrator, working with a technician group that defines triage data such as priority inputs, approval notes, or internal routing answers.
This work usually appears during the upgrade project rather than as a separate request. Once a team plans the move to GLPI 11, it has to inventory every FormCreator form that carried hidden or technician-only fields, because those fields will not carry over on their own. The inventory should record each question, who answers it, where the answer is read (ticket, task, or a report), and whether the field must be required. Teams that also depend on forms as part of their GLPI service catalog should review the same list, since requester-facing and technician-facing questions often share one form.
Before design starts, confirm the exact feature set of the Advanced Forms plugin with its own documentation and with the vendor. The supplied facts do not establish which question types it supports, how it controls visibility per profile or group, whether technician-only answers appear in ticket search and exports, or how it behaves during a GLPI update. Ask for a written list of those capabilities and test each one in a non-production copy of your instance, using a requester profile and a technician profile, before you commit to a design that depends on them.
What GLPI forms do and what the Advanced Forms plugin must add
Native GLPI forms collect requests and turn answers into tickets. A technician-only question adds a second audience inside the same form, so each component below has to hold for both audiences. Verify every component against the plugin's own documentation before you design around it.
Requester-facing form fields
Native GLPI forms give requesters a structured way to submit a request, and the answers become the starting point for a ticket. Whatever a requester can see and fill in forms the baseline that any technician-only addition must leave intact. Before design starts, list the questions requesters answer today and confirm which field types the core forms in your target version support. Anything on the form is visible to the requester who fills it in.
Technician-only questions
This is the capability the Advanced Forms plugin must add: questions that technicians see during triage but that requesters never see. Confirm whether core forms in your target version can hide a question from requesters. If they cannot, the plugin has to supply that split. Ask the publisher whether visibility is set per question and whether it can depend on the viewer's profile.
Routing answers into tickets
Hidden answers must reach the technicians who need them and stay out of requester-facing views. Check where each answer is stored, whether it appears in ticket followups, and whether ticket notifications copy it to requesters or watchers. Also confirm whether answers can set category, urgency or assignee through routing rules. Test each path with a requester account.
Profile and entity permissions
GLPI controls access through profiles and entities, so map each role to its rights: requester, technician, form designer and auditor. Decide who can edit technician-only questions and who can read stored answers. Confirm whether the plugin grants form rights separately from ticket rights. Repeat the tests in every entity that will use the form, because permissions differ by entity.
Upgrade and plugin reactivation
Since GLPI 11, plugins are suspended when a new version is detected and must be reactivated after major updates. GLPI 11.0.0 was released on October 1, 2025, so plan the plugin version alongside the core version. Confirm plugin compatibility with your target release, rehearse the upgrade on a copy, and back up the database, files and the glpi.key and glpicrypt.key files first.
Answer data in backups
Technician-only answers are often working notes, so they sit in database and file backups like any other ticket data. Confirm where the plugin stores them and whether exports include them. Restore a backup to a test instance and check that the same visibility rules still hold for requesters and technicians. Document who may restore and who may read the restored data.
Which design decisions shape technician-only questions
This table compares the configuration decisions that determine where technician-only answers live, who sees them, and what they affect. Read each row as a question to settle with your service desk lead before building anything, because several choices are hard to reverse once tickets carry data. Confirm each option against the Advanced Forms version you plan to run, since plugin behavior changes between releases.
| Decision | Option to confirm | When it fits | Risk if chosen wrongly |
|---|---|---|---|
| Where answers are stored | Native ticket fields, form-level questions, or a separate record linked to the ticket | Ticket fields fit answers that routing or reporting must query; a separate record fits sensitive triage notes | Answers become hard to report on or leak into requester-visible views |
| Who can see each question | Visibility tied to GLPI profile and rights, confirmed per question | Mixed teams where only level 2 technicians should see escalation data | Requesters or low-privilege profiles see internal questions, or no one can answer them |
| Whether answers drive routing | Routing rules or assignment logic reading technician answers, confirm trigger timing | Triage categories that decide queue or priority | Tickets route on answers filled in after routing already happened |
| Whether answers affect SLAs | SLA or OLA start and due logic keyed to technician input, confirm reevaluation behavior | Answers that define urgency or impact classes | Breaches are measured against values that changed after the clock started |
| Whether technicians must answer | Mandatory at a chosen status, or optional with reminders | Closure checks for regulated work or audit evidence | Mandatory fields block closure or are skipped entirely, both creating evidence gaps |
| Whether requesters see a summary | No summary, a generic status, or a copied summary field | Requesters need progress without internal reasoning | Internal notes or sensitive values appear in requester notifications or the portal |
| Survival through upgrades | Confirm how questions and stored answers carry across GLPI versions and plugin updates | Long-lived forms in a planned GLPI 11 or 12 path | Answers stranded or unreadable after a migration, with no tested rollback |
How technician-only answers reach the ticket and the people who read it
A requester opens a GLPI form, answers the public questions, and submits it. The plugin stores the requester's answers together with any technician-only answers, and the form submission becomes a ticket. A technician opens that ticket and sees the extra questions alongside the requester's answers. The requester's view of the same ticket is limited to the questions the form presents to them, so the hidden answers are not shown in the requester's interface. That interface behavior is the part most teams test first, and it is the part that matters least for data exposure. The harder question is where the hidden answers travel after they are saved.
A question hidden in the interface is not the same as data kept out of exports, notifications, API responses and history. Each of these is a separate path. Ticket followers and email notifications may render the ticket content differently from the form view. Saved searches, CSV or spreadsheet exports, the GLPI REST and OAuth2 API, and the ticket history log can each expose a stored value that the requester's screen never displays. Ask the plugin's documentation, or the vendor, exactly how hidden answers are stored: in the same table as public answers, in a separate table, or in encrypted form. The answer determines which paths need testing and whether a database backup restore exposes the values to anyone with database access.
Build a test matrix before go-live. Submit a form as a requester with a known hidden answer, then check that value as each role that can read tickets, including technicians outside the assigned group, supervisors and API clients. Repeat the check through notifications, exports, the API and history, and record which paths show the value. Decide, for each path that does show it, whether to restrict the role, change the notification template, or move the sensitive data to a question that belongs in the ticket body. Repeat the matrix after every plugin or GLPI upgrade, because a new release can change how a path renders stored fields.
How to build technician-only questions in a GLPI instance
This sequence moves technician-only questions from FormCreator into GLPI native forms in a controlled way, so each question is confirmed against the right profiles, tested with real accounts and cut over without exposing internal fields to requesters.
Confirm GLPI version and plugin compatibility
Record the GLPI version you run now and the version you plan to reach, then check every plugin against that target before any change. GLPI 11 suspends plugins when a new version is detected and they must be reactivated after major updates, so the plugin list is a dependency check, not a formality. Ask the plugin publisher or your Teclib contact to confirm which Advanced Forms and FormCreator releases match your GLPI version. Output: a compatibility register listing each plugin, its current version, its target version and the owner who confirmed it.
Inventory FormCreator forms and questions
Export every FormCreator form, section and question, including field types, mandatory flags, default values, destination rules and any ticket template or validation step each form triggers. Mark which questions are meant to be hidden from requesters today and which are visible only by accident. Interview the technicians who rely on those answers, because the questions they use during triage are the ones most often lost in translation. Output: a question inventory with one row per question and a note on who consumes each answer.
Write the visibility matrix by profile
Create a matrix with one row per question and one column per GLPI profile that touches the form, such as requester, technician, team lead and administrator. For each cell, record whether the question is shown, hidden, required or read-only, and which entity or group the rule applies to. Have the service owner and the security reviewer sign the matrix before anyone builds anything, since it is the reference for every later test. Output: a signed visibility matrix with a version number and a change log.
Build questions in a non-production instance
Install the matching GLPI version and plugin set in a non-production instance restored from a recent copy of production data, or from anonymized data if your policy requires it. Build the native form questions and their visibility conditions exactly as the matrix states, and record any setting the interface does not expose so you can reproduce it. Keep the build in configuration you can export or document, not in ad hoc clicks. Output: a non-production build with a configuration record that another engineer could rebuild from.
Test requester and technician views with real profiles
Sign in with test accounts that hold the real profiles, not an administrator account with broad rights, and submit the form as a requester, then review it as a technician in the same entity. Check each cell of the matrix, including edge cases such as a requester who belongs to a second group or an entity without the rule. Attempt to read hidden answers through the ticket view, search, and direct links, and record each result. Output: a dated test log with expected and actual results for every matrix cell and a pass or fail mark.
Check notifications, exports and API output
Review what hidden answers leak outside the ticket view. Trigger the notifications that fire on submission and on updates, read the message bodies and check the recipients, and open exports and reports generated with the affected fields. Query the REST API with a requester token and with a technician token and compare the returned fields, since an API client may expose data that the interface hides. Ask your security reviewer to confirm which channels are acceptable for each field. Output: a leakage review that lists each channel, the field it exposes and the decision taken.
Migrate existing forms and tickets
Rebuild each in-use FormCreator form as a native form, then migrate open and recent requests where the data model allows it, keeping the original FormCreator answers available for reference. Map each old question to its new counterpart in a table that a technician can read, and flag any question that cannot be carried over so it is handled by hand. Run the migration first on the non-production copy and compare the counts and sample records with the source. Output: a migration map and a reconciliation report showing migrated, skipped and manually handled items.
Run a controlled cutover and keep a rollback path
Schedule the cutover with the service owner, freeze changes to the affected forms, take a full backup of the database, files and the config directory including glpi.key and glpicrypt.key, and then switch requesters to the native forms. Watch the first submissions and the technician queue, and reactivate any plugin that the upgrade suspended before testing it again. Keep the rollback steps written down until the owner accepts the new forms in writing. Output: a cutover record with the backup reference, the time of switch, the plugin reactivation log and the owner's sign-off.
What drives effort in a technician-only forms project
This table compares the factors that raise or lower effort when moving technician-only questions from FormCreator to GLPI Advanced Forms. Read each row as a question to answer before asking for a quote, since the same driver can be cheap in one instance and expensive in another. The main takeaway is that the FormCreator inventory and the number of sign-off test cycles usually matter more than the raw count of forms.
| Driver | Why it changes effort | What to ask for in a quote |
|---|---|---|
| Number of FormCreator forms to replace | Each form needs its own mapping of questions, categories, target fields and technician-only sections. Effort scales roughly with the number of distinct forms, not the number of questions. | A form-by-form list in the written scope, with each form marked as rebuild, merge or retire. |
| GLPI profiles and entities involved | Each profile that sees or edits technician-only answers needs rights checked, and each entity may need its own form variant or visibility rule. Multi-entity setups add test paths. | A list of profiles and entities that must see each question, and confirmation of who edits the form definitions afterward. |
| Routing and SLA rules that depend on hidden answers | When ticket category, urgency, assignment or SLA depends on a technician-only answer, the rule must be rebuilt and checked against the form outcome. Rules that read answers across several forms are the most time-consuming. | A rule inventory that names each condition and the ticket field it sets, plus whether SLAs or OLAs are in scope. |
| Quality of the existing FormCreator inventory | Undocumented forms, unused forms, duplicated questions and answers stored only in free text slow discovery. Clean inventories shorten the analysis phase. | Whether the discovery phase is priced separately, and what the written output of discovery contains before build starts. |
| Integrations that read ticket data | Any tool, report or webhook that reads ticket fields or form answers may break when the data model changes. Each consumer needs a mapping and a regression check. | A list of downstream consumers, the fields each reads, and who owns the change on the consumer side. |
| Number of test cycles for sign-off | Technician and requester paths, profile combinations and rule outcomes multiply the test cases. Each failed cycle adds a fix and a retest. | The number of test cycles included, the acceptance criteria for each, and who signs off on behalf of the business. |
| GLPI Network subscription (licensing line) | Separate from implementation effort. Support or marketplace plugin access, where the chosen setup depends on it, is a recurring licensing cost billed by Teclib' and not part of the services fee. | Confirm with Teclib' whether the plugin route needs a subscription and at what level. Ask the quote to show licensing as a separate line. |
How technician-only forms connect to the rest of GLPI
A technician-only question lives inside a form that also serves requesters, so it touches access control, sign-in, notifications, inventory, integrations and upgrades. Each connection below sets a constraint on how the form is designed, and each one should be confirmed against the GLPI integration documentation for your version before the build starts.
Profiles and authorization rules
Visibility of a technician-only question depends on the profile and entity a user holds at the moment the form is opened. Map which profiles may see and answer each question, and decide whether any rule should also be enforced in ticket or asset views, not only in the form. Test with a requester account, a technician account and a user who holds both roles, because a mismatch here exposes internal answers. Confirm how authorization rules assign profiles in your GLPI release.
Authentication sources
Users are checked against the internal database, LDAP directories, IMAP servers or external methods such as REMOTE_USER, in that order. A question that a technician must answer often depends on group membership, and group data arrives from the authentication source, not from GLPI forms. Confirm which source provides technician group membership in your environment and what happens to a technician account that is disabled upstream while a form is still open.
Email notifications and mail queues
Form submissions generate notifications, and technician-only answers must not leak into messages sent to requesters. Review every notification template that renders form data, including the ones used for approvals and reminders. Queued notifications are processed by GLPI automatic actions, so a stalled queue delays technician alerts as well. Confirm the queue behavior and template variables for your version in the notifications documentation before you publish templates.
GLPI Agent inventory data
Technicians often answer questions about a device that the GLPI Agent has already inventoried, such as installed software or hardware model. A dropdown that pulls from inventory data needs the agent to report consistently across the fleet, otherwise the options are incomplete or stale. Decide which questions should reference inventory and which should be free entry, and confirm the inventory item types the agent populates in the GLPI Agent documentation.
REST and OAuth2 API consumers
If form answers feed a downstream system, the API becomes a second reader of the same data. Technician-only answers returned through an API token can reach a system with broader access than the technician who entered them. Scope the API client to the fields it needs, decide whether internal answers are exposed at all, and test what a token with a given profile can read. Confirm the current API and OAuth2 behavior in the GLPI integration documentation.
Plugin update path
Advanced Forms is a plugin, so its state follows GLPI updates. Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates. Plan the question definitions, any custom code and the backup of form data as part of the same change window, and confirm the plugin release that matches your target GLPI version before upgrading. Test the reactivation on a copy of the database first.
Questions teams ask before building technician-only form questions
Can our own team build technician-only questions without a partner?
Often yes, if your team already runs GLPI and knows its profiles, rights and notification setup. Most of the build is configuration, but the risk sits in visibility rules, so the work needs testing from a requester account and a technician account. Your team also needs an owner for profiles, notifications and the upgrade calendar. A partner adds the most value when the form must feed ticket routing, assets or external systems, or when your staff have no spare time for testing. Before deciding, confirm which Advanced Forms capabilities your installed version provides and who will maintain the forms after handover.
What drives the cost and timeline of technician-only form work?
The main drivers are the amount of work in the forms themselves and the number of systems the answers touch. Scope grows with:
- the number of forms and questions that need technician-only visibility
- conditional logic that changes which questions appear
- the number of profiles, entities and groups that must see different content
- routing, assignment or asset rules that read the answers
- whether the work starts on GLPI 10 with FormCreator forms that must be moved first
The quote should set effort and duration from this list. No public figure exists for this kind of work, so ask the vendor or partner to show how each driver was counted.
What does this work need from our staff?
It needs decisions and testing more than heavy technical effort. Plan for a named GLPI administrator who can approve profile and rights changes, a technician lead who decides which questions stay internal, and a small group of requesters and technicians who test each form. You also need a non-production GLPI instance with a copy of the current configuration, plus time for review of test results. Staff who will maintain the forms after go-live should take part in the build, so the knowledge stays in your team. Confirm these roles before the work is scheduled.
How does the GLPI 11 upgrade affect existing FormCreator forms?
GLPI 11.0.0 was released on October 1, 2025, and forms moved into the GLPI core in that release line. Existing FormCreator forms therefore need an inventory and a mapping to core forms before cutover. GLPI suspends plugins after it detects a new version and requires you to reactivate them after major updates, so a plugin-based form can stop working until that step is done. Follow the GLPI update procedure, which includes backing up the database, files and the config directory with glpi.key and glpicrypt.key. Confirm which FormCreator features have no direct equivalent in the target version.
Can hidden technician answers leak through notifications or the API?
They can, if the answer is copied into places that requesters or integrations can read. Check ticket followups, solution text, notification templates, email bodies, exports and API responses. Test each path with a requester account and with an API token that has the rights of a requester. Also review which profiles can read the field in the API and in reports, since rights set in the interface do not always cover every output. Treat the result as a test finding for your installed version, not a promise. Ask the implementation team to show the test cases and results before go-live.
What should a quote for this work include?
A quote should follow from a written scope, not a general description. Ask for:
- the list of forms, questions, question types and conditional logic
- visibility rules for each profile and entity
- integration points, such as assignment rules or asset updates
- the test plan, with acceptance criteria and the accounts used for testing
- the upgrade assumptions if the starting point is GLPI 10
- handover documentation and training for your staff
- support after go-live, and the assumptions and exclusions
DeployOpen plans most engagements as fixed-scope work, with scope, deliverables and timelines agreed in writing before work starts. Ask how each deliverable connects to a payment or review milestone.
Does a fixed-scope engagement suit this kind of form work?
It usually fits when you can list the forms and questions before the build starts. An inventory of current forms, profiles and downstream rules gives the scope enough detail to agree in writing. If the requirements are still open, a short discovery phase with its own written scope is a better first step, followed by a fixed-scope build. Changes after go-live, such as new questions after a business process change, can move to a retainer. DeployOpen offers ongoing support, upgrades and continuous testing as retainers. Confirm how change requests are priced before signing.
How DeployOpen scopes and delivers technician-only form work
DeployOpen approaches technician-only questions in GLPI Advanced Forms as a defined piece of work inside your own GLPI instance. We start from the form each requester sees, define which extra questions only technicians should answer, and deliver the change with tests, documentation and a handover your team can run.
How we scope
- We list every form, the questions technicians need, and the requester view that must stay unchanged.
- We record which profiles, entities and ticket outcomes each technician-only answer feeds into.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any build starts.
How we build
- We build the technician-only questions in a staging copy of your GLPI instance, never directly in production.
- We test requester and technician views with separate accounts to confirm hidden questions stay hidden.
- We check the form change against your GLPI version and plugin state before any production rollout.
How we hand over
- We document each form, its technician-only questions, the profile rights that control them and the rollback steps.
- We walk your administrators through how to add or change a question without exposing it to requesters.
- We hand over the staging test cases so your team can repeat the verification after future GLPI updates.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the handover.
- A retainer can cover re-testing of technician-only forms when GLPI or related plugins receive updates.
- Confirm with us during scoping how changes after handover are requested, reviewed and billed.
