Help center › Set up
Request forms and conditional questions
Every category in Beacon is a request form. When someone picks it on the portal, in New Ticket or in the mobile app, they get that category's questions, and the ticket is routed with the category's default team, priority and SLA policy. One help desk can carry several departments this way: Technology, Events, Operations and Facilities each get their own categories, their own questions and their own team, and nobody has to run a second system. Everything on this page is under Admin › Categories.
A category is a form
Open a category and its Request form lists the questions it asks. Each question has a label (what the requester reads), a key (how the answer is stored, filled in from the label), a type, and a few options:
| Type | What the requester gets |
|---|---|
| Text, Paragraph | A line or a box of text. |
| Number, Date, Link | A number, a date picker, a web address. |
| Date and time | A day with a time, picked on your district's clock (Admin › Settings › Time zone) whatever the person's device is set to, and shown that way everywhere, with the zone named: "Nov 5, 2026, 7:00 PM CST". |
| Yes / No | Two choices. It is unanswered until one is picked, so a required yes/no has to be answered, and the questions that follow a Yes wait for a real Yes. |
| Choice, Multiple choice | One of the options you list, or any number of them. |
| Person, Device | A pick from your people or your devices. Technicians only, whatever the Show on portal box says: the portal and the mobile app do not ask these, so a required one never keeps a requester from sending. |
Required means the request cannot be sent without an answer. Show on portal decides whether requesters get the question at all; a question with it off is for technicians, who see every question on New Ticket and in the ticket's Request form section. A subcategory with no questions of its own asks its parent's questions. Options for a Choice or Multiple choice question are typed as a comma-separated list; correcting an option's spelling keeps it in the rules that name it, while removing an option drops it from them.
Asking a question only after a certain answer
Under each question, Show this question only when lists the yes/no and choice questions on the same form. Pick one, then pick the answer (or answers) that should bring the question up. The question appears the moment that answer is given and disappears, with its answer cleared, when the answer changes. A question that appears this way can bring up another one in turn, as long as the rules never point at each other; Beacon refuses to save a loop, a rule that names a question not on the form, a rule with no answer picked, or an answer the choice does not offer. A question that follows another belongs below it, and a portal question cannot follow a technicians-only one (requesters cannot give the answer that reveals it); the builder points both out without blocking the save.
Three things follow from this, and they hold on the portal, in New Ticket, in the mobile app and in the API alike:
- Required means required while asked. A question hidden by its rule is never required, whatever its Required box says. The builder labels it Required when shown.
- A hidden answer is never stored. If someone answers Yes, fills in the details, then changes to No, the details are dropped before the request is sent, and the server drops them again if a client sends them anyway. A technician who flips the answer later in the ticket's Request form section clears them the same way; the ticket's history lists which answers were cleared and keeps what they held. Flipping back to Yes asks the question again, so the Yes is saved together with its answer: the section holds the change, says what is still to answer, and saves once it is. A requester's flip leaves a technicians-only answer behind it alone; a technician's next edit clears it.
- Requesters only see their part of the form. A question whose rule depends on a technicians-only question is never asked on the portal, whatever the technician answered, because the requester cannot see the answer it depends on.
What the portal asks above the questions
Above a department's questions, the portal asks for a title ("What do you need help with?"), a description ("What happened?") and an asset tag. A department whose questions already say everything can drop any of the three, so its questions start right under the department card. At the top of the category's Request form section:
- Title: ask for one; use a question's answer (the ticket is titled with the answer and the department, "Events: Fall play tech rehearsal"; a text, choice, number, date or date and time question); or fill in a template such as "{department} request from {requester}", where {date} is the day the request is sent. The question has to be one the form asks: if you rename or remove it, the pick follows or clears, and a subcategory that asks its own questions needs the question among them or title settings of its own. Beacon says so before you save.
- "What happened?": ask, or do not ask. When it is not asked, the ticket's description is written from the answers, one per line in the form's order, so technicians still read a request and replies by email thread onto it as before. A note typed in the mobile app's quick report, which has no such field, is kept under those lines. When an answer is corrected later, the lines are rewritten to match, unless someone has edited the description by hand.
- Asset tag: ask, or do not ask. When it is not asked, no device is attached to the request, and a tag sent anyway is not kept.
A subcategory follows its department's settings unless it has its own; its editor shows the department's settings, and a change to one of them gives it its own. The technicians' New Ticket page keeps its own fields whatever the settings say. Preview form shows which of the three a requester will see, with a built title carrying the department's name.
An Events request form
An events office that takes room and equipment requests might build this, with the Events team as the category's default team, the title taken from Event name, and "What happened?" and the asset tag not asked:
| Question | Type | Shown | Required |
|---|---|---|---|
| Event name | Text | Always | Yes |
| Date and time of the event | Date and time | Always | Yes |
| Do you need AV equipment? | Yes / No | Always | Yes |
| Which equipment? | Multiple choice: Projector, Microphone, Speakers | Only when Do you need AV equipment? is Yes | When shown |
| How many microphones? | Number | Only when Which equipment? includes Microphone | When shown |
| Room setup | Choice: Theater, Classroom, Banquet | Always | No |
| How many tables? | Number | Only when Room setup is Banquet or Classroom | When shown |
| Caterer | Text, technicians only | Only when Catering booked (a technicians-only yes/no) is Yes | No |
A teacher who picks Events sees these questions and nothing above them. One who answers No to the AV question sends a request with a name, a date and time and a No; one who answers Yes is asked which equipment, and, if Microphone is among the choices, how many. The Events team gets a ticket titled "Events: Fall play tech rehearsal" whose description reads "Event name: Fall play tech rehearsal", "Date and time of the event: Nov 5, 2026, 7:00 PM CST", "Do you need AV equipment?: Yes", and so on, one answer per line. An Operations category can sit beside it with its own questions (which building, which room, is anyone blocked) and the Facilities team as its default, so the two departments share one help desk and one portal while each reads only its own queue.
Previewing the form
Preview form, on a category's row and inside the editor, opens the form the way a requester will fill it in, so you can answer the questions and watch the follow-ups appear. Switch to As a technician to include the technicians-only questions. Nothing typed into the preview is saved.
What the ticket keeps
A ticket stores the answers to the questions that were asked when it was sent. Technicians see them in the ticket's Request form section (and can change them, which follows the same rules); requesters see them under Your answers on the request page and in the mobile app. A change to several tickets at once, and an automation's Set custom field action, follow the same rules: an answer to a question the ticket's form hides is not stored. An automation can read an answer in its conditions (customFields.<key>), so a Yes to "Is anyone blocked?" can raise the priority or notify a team on its own.
Changing a form later does not rewrite old tickets. An old ticket keeps its answers, and a question it has no answer to yet (one added since) does not keep it from being edited. If a question it answered has since gained a rule that hides it, that answer is left out of the display, and is removed the next time anyone edits the ticket's answers; the history lists it under cleared, with the value it held.