Public forms

A public form is a page anyone can open without an account. Someone fills it in, and their answers arrive in your workspace as an ordinary task — no copying by hand, and nothing else in the workspace is exposed.

Public forms appears in the menu for anyone with the design public forms permission; administrators always see it, under Administration. The tasks a form creates are read like any other work item; there is no separate inbox.

Public forms are off in a new workspace. An administrator turns them on under Configuration → Features → Public forms. While they are off, nobody sees Public forms in the menu and every form link answers that the form is not available; the forms themselves are kept.

Creating a form

New form opens the designer, with a preview of the public page beside the settings and questions. Nothing in the preview can be filled in or sent; once the form is saved, Open the form opens the real page in a new tab. The designer checks the form before saving and names what is missing.

The form

• Form name — shown as the title of the public page.
• Address — the last part of the public link. Lower-case letters, numbers and hyphens only, and unique in your workspace. The full link is shown under the field. One word is not available: ticket, which is where senders follow their requests (see What the sender gets).
• The form is open — turn it off and the link stops working. Visitors are told the form is unavailable; they are never told why.
• Submissions accepted per day — a safety limit. Past it, the form answers temporarily unavailable until the next day, so a flood of spam costs you a number instead of a full project. A new form starts at 20; raise it when you expect more.
• Check that the sender is not a robot — the public page runs a check before a request can be sent. Shown only when this installation has the check set up, and on for a new form. See The robot check.

Where submissions go

Settings of the form. Visitors never see any of this.

• The task will be created under the project — the project or phase every submission becomes a task inside. The picker offers only items you can add work to.
• Created as — the user each ticket is created by. Their name is what the task's history shows, and their access decides where tickets may land, so a dedicated account (invited once and signed in once) is the tidiest choice. It must be someone who has signed in at least once.
• Assign every ticket to — optional. The person you choose gets the usual new-assignment notification.
• Route every ticket to a team — optional, and an alternative to the person above: pick one or the other, not both. Shown only when work teams are enabled. Each ticket is created restricted to that team with no assignee, so it waits in the team's block on Home until a member presses Take, and every member is notified that it arrived. Everyone else can still read the ticket; only the team can edit it. When the target project or phase is itself restricted to a team, only that team can be chosen, and the ticket keeps the target's own visibility.
• Customer group — optional. Every ticket is created with this customer group already set, the same as choosing it in the task editor. Shown only when customers are enabled in your workspace.

The page visitors see

Everything here appears on the public page.

• Language — the language of the buttons and messages on the public page. Your own wording is used exactly as you type it, in whatever language you write. A form with language versions lists them under this field, each opening its own designer, and the field leaves out the languages they already have.
• Introduction — your words, shown above the questions. It takes formatting: headings, lists, bold and links, with Preview to check the result. Mentions and links to work items are not available here: visitors read the page without an account.
• Footer — small print under your logo and name, at the very end of the page. Meant for a disclaimer or a side note; line breaks and formatting are kept.
• Thank-you message — shown in place of the form after a successful submission, with the same formatting.
• Your logo and name — shown under the submit button and again at the top of the thank-you message, so visitors can see whose form they are filling in. They come from your workspace branding; with none set, the default mbovy logo and name are shown.

Questions

Visitors see every question, in the order listed.

A question is set up top to bottom, in the order it takes effect:

1. Question and Help text — what the visitor reads, above and under the answer box.
2. Answer type — the control the visitor gets: short text, long text, choose one, choose several, date, email address, yes/no, file upload or task type (both below). Choice questions take their options one per line, in the order shown.
3. Use this answer as — where the answer lands on the task. It only appears on the types that can fill a task field; every other answer is written into the description as Question: answer, and the question says so.
4. Fill from the link — on short text only, and optional. The name of a parameter of the form's link, in lower case. With workspace here, a link ending in ?workspace=acme opens the form with acme already in this question's box. lang cannot be used: it chooses the form's language version. See Sharing the link.
5. Required — whether the visitor must answer.

Each use belongs to one question. Where another question already holds it, the choice is shown greyed out with that question's name, so nothing is taken over by accident: free it there first.

Keeping the sender informed

On the question used as The sender's email address, the switch Keep the sender informed appears under Use this answer as. It is off in a new form. With it on, every ticket the form creates from then on writes to its sender:

• when the task's status or priority changes, automatically;
• when a team member chooses to send them a comment (see the editor).

Nothing else leaves the workspace: not the assignee, the dates, the description, the files or the team's other comments. Every email carries a link to a page where the sender follows the request and can answer the team. See What the sender gets.

The switch needs the email question: every message goes to that answer. Removing the question, or using it for something else, turns the switch off. Make the question Required if every sender should be kept informed; a sender who leaves the address empty gets nothing, whatever the switch says.

The switch decides how new tickets start. A ticket that already exists keeps its own setting, which your team can change on the ticket itself.

To ask for the sender's name, add a short-text question and use it as The sender's name. The task then shows the name beside the address. Mark it Required if you always need one.

Letting visitors pick the task type

Set the Answer type to Task type and two pickers appear under it:

• Task category — not shown to visitors. It only decides which types you can offer.
• Task types visitors can choose — shown to visitors as the choices in the list, in this order. Only the types you tick are offered, so a category with twelve types can offer three. A type that has a default priority shows it beside its name, because the ticket takes it (see below).

The question text and help text are yours, as for any other question, and they are what the visitor reads above the list. Only one question per form can pick the task type; once one does, Task type is greyed out on the others.

Visitors see the type names as they are at the moment they open the form; a renamed type shows its new name without saving the form again. A type you later disable or delete simply disappears from the list. If every offered type is gone, the form stops accepting requests and is marked Needs attention like any other broken form; tick other types and save to fix it.

Make the question Required when every ticket needs a type. Left optional, a visitor who skips it creates a task with no type, and your team sets one later.

Letting visitors attach files

Set the Answer type to File upload and two numbers appear under it:

• Maximum files — how many files a visitor can attach to this question. Starts at 1; from 1 to 10.
• Maximum size per file (MB) — the largest file accepted. Starts at 5; from 1 to 10, or less when this installation stores smaller files, in which case the field shows the real limit.

Under the two numbers the designer says what they can cost: how much one submission can add to your workspace's storage, and how much the form can add in a day at its Submissions accepted per day. Allowing more files or larger files can fill your storage quickly, and the note turns into a warning once you go above the starting numbers. Your plan's storage limit still applies to these files, exactly as it does to files your team attaches.

One submission can carry 25 MB at most, over all its file questions. The designer adds up what each file question allows (files times size) and marks the questions when the sum passes 25, so lower one of the numbers. A form can have more than one file question as long as they fit.

The accepted types are fixed and cannot be changed per form: images (JPG, PNG, GIF, WebP), PDF, Word, Excel and PowerPoint documents (.docx, .xlsx, .pptx), text and CSV files, and ZIP archives. Anything else is refused, and so is a file whose content is not what its name says, a renamed program for example. The visitor is told which file was refused and why, and nothing is created until every file is accepted.

The files arrive as ordinary attachments of the task: they are on its Attachments tab, its History shows each upload under the Created as account, and the description lists their names under the question. Who can open them is decided by the task, like any other attachment.

Adding a file question needs nothing beyond the design public forms permission. The Created as account does not need the upload attachments permission: that permission is about what a signed-in person can attach by hand, and these files come in through the form.

Files use your workspace's storage. See When a form stops working for what happens when it is full.

Everything else — status, priority, whether it is a project, phase or task, dates, customer, assignee, restriction — stays with your team. A visitor can never set them, so a "how urgent is this?" question is simply a line of text your team reads before triaging.

A ticket is created at Normal priority, with one exception your team controls: when the visitor picks a task type that has a default priority, the ticket is created at that priority. The visitor is never shown priorities, only the type names.

Every task also gets a short footer saying which form it came from, when it was sent, and the sender's address if the form asked for one.

The robot check

Check that the sender is not a robot, in The form group, makes the public page run a check by Cloudflare (Turnstile) before a request can be sent. The switch appears only when this installation has the check set up; if you do not see it, it is not available here.

• A new form starts with the switch on. Turn it off if you do not want the check; the form keeps your choice. Forms created before the check was available stay off until you turn it on.
• Most visitors notice nothing, and neither will you when you try the form: the check runs on its own and shows nothing. Only a visitor Cloudflare is unsure about is asked to tick a box, which appears just above Submit.
• A request is accepted only when the check passes. When it does not, the visitor is told so and can send the form again; nothing is created and nothing counts toward Submissions accepted per day.
• When you give a form with the switch off its first File upload question, the switch turns itself on and says so next to it: files are what a flood of spam costs most. You can turn it off again and the form keeps your choice. Forms that already had a file question are not changed.
• The preview shows where the check goes as a placeholder. The check itself only runs on the public page.

With the switch on, each visitor's browser contacts Cloudflare, which sees their network address and details of their browser. If your visitors should be told, say it in the form's Footer or in your own privacy notice: the form adds no notice of its own. With the switch off, the public page never loads the check.

The check makes spam more expensive to send; it does not replace the form's other limits. Submissions accepted per day applies with the switch on or off.

Duplicating a form

Duplicate, in the row's More actions menu in the list, opens the designer with a copy of the form: the same project, account, routing, texts, questions and limits. The copy's name ends in (copy), its address ends in -copy, and it starts closed. Nothing is stored until you save it; leaving the designer first creates nothing. The original's submissions stay with the original.

A copy keeps the original's language and is not one of its language versions. To offer the same form in another language, use Add language version instead.

Language versions

A form can have one version in each of the app's languages, and the versions answer each other's links: a visitor who opens the English form's link with ?lang=es gets the Spanish version (see Sharing the link).

Add language version, in the same menu, first asks which language the new version is in, offering only the languages the form does not have yet. Then the designer opens with a copy, as for a duplicate: its name ends in the language's name, its address ends in the language's two letters (-es), and it starts closed. Translate its name, texts and questions, and open it once it is ready. Nothing is stored until you save it. When the form already has a version in every language, the option is greyed out.

With the use the AI companion permission, the same dialog offers Translate with the AI companion, greyed out while the AI companion is not set up. Ticked, the companion writes the copy's name, texts, labels, help and choices in the new language before the designer opens; the address, the question keys, the link parameters and the task type names stay as they are. The draft is not saved until you save it, the version still starts closed, and a notice above the form asks you to read every text first: nobody else checks them. If the translation fails, or does not match the form's questions, the designer opens with the original's texts and says so. A form too long to translate in one request is refused before anything is sent.

• Each version is a form of its own, with its own address, switches, limits, routing and submissions, and each counts its own Submissions accepted per day. Saving one changes nothing in the others: a question added to the English version is missing from the Spanish one until you add it there.
• One version per language. A version's Language can only change to a language the other versions do not have.
• No version is the original. Deleting one leaves the others as they are.
• A form becomes a version only when it is made with Add language version. A new form or a duplicate belongs to no set, and no later edit adds a form to one or takes it out.
• Task type names are not translated. A Task type question shows your task types by their names in every version, so name them in a way all your visitors read.

Sharing the link

Copy link on the list copies the full address. It is meant to be shared — pasted into emails, printed on a page — so treat it as public rather than secret.

QR code, next to it on the list and beside Open the form in the designer once the form is saved, shows a code that opens the same link when scanned with a phone camera. Download image saves it as a PNG picture to put on a poster, a counter card, a receipt or in an email. The code is made from the link as it is at that moment: if the form's Address or the workspace name changes, download it again, because the printed copies point at the old link.

When your workspace has its own web address, the link is that address followed by /intake/ and the form's Address, for example acme.example.com/intake/support. The workspace is named by the web address itself, so the link does not repeat it. Links shared before your workspace had its own address carry the workspace name after /intake/, and they keep working.

When your workspace does not have its own address, the link carries the workspace name after /intake/.

To send visitors to the version in their language, add lang and the language's two letters to the link: acme.example.com/intake/support?lang=es, or &lang=es after other parameters. A regional code such as es-AR works too. When the form has an open version in that language, the visitor gets that version, with its buttons and messages in that language, and the request is created by that version. Otherwise (no lang, a language with no version, or a version that is closed) the link opens the form it names, and a closed form stays closed whatever lang says. Nothing else chooses the version, not the visitor's browser or account, so put lang in every link you hand out.

A link can carry starting answers. For each short-text question with Fill from the link set, add its parameter to the end of the link: acme.example.com/intake/support?workspace=acme, with & between several. The form opens with those values already in their boxes. The visitor sees them and can change or clear them before sending, and from there each is an answer like any other: a filled box counts for Required, and nothing on the task says the link wrote it. The name is matched whatever its capitals, a parameter no question names is ignored, and a value longer than its box allows is cut.

Anyone can edit a link, so a value that arrives this way is what the sender's browser said, not something checked. On the title question it also means that whoever writes the link writes the title a hurried visitor sends. And a link is no place for anything private: whoever sees the link sees the value, and it stays in the address bar.

What the sender gets

If the form asks for an email address and email is switched on for this deployment, the sender gets a receipt echoing their answers.

Senders can attach files only when the form has a File upload question. The receipt lists the names of the files they sent, not the files themselves.

What happens next depends on Keep the sender informed.

With the switch off, the receipt carries no link and no reference number, and there is no public page where the sender can check progress. To tell them the work is done, write to the stored address.

With the switch on, the receipt gives the request's number and a See your request button, and the sender then gets:

• an email when the task's status or priority changes. A save that changes both sends one email naming both;
• an email with the text of each comment a team member sends them.

Emails are written in the form's Language. Replies to them are not read, and each one says so.

The workspace sends at most 3 of these emails a day to one address, and 100 a day to all senders together. Past either limit the request still arrives and becomes a task as usual; only the email is not sent, and the request's messages say so.

The button opens the request's page: the form's own link followed by /ticket. The page asks for the request number, already filled in from the link, and the email address the request was sent with. The address is never in a link; typing it is what proves who is asking. With both right, the page shows:

• the request's number and title, its status and priority, when it was received and who it is assigned to;
• everything the sender was told, newest first, and their own answers.

It shows nothing else of the task: not its description, its files, its other comments or its history.

When the newest message is a comment from the team, the page offers Answer the team. The answer is plain text with no files. It arrives on the task as a comment marked From the sender, and the assignee and anyone following the task are notified. The sender can answer once per comment: to hear more from them, send another comment. A status or priority change after your comment also closes the answer box until you write again.

A wrong number or address gets the same answer as a request that does not exist, so the page says nothing to someone guessing. After ten wrong tries on one number, that number stops opening for an hour, for everyone.

The page keeps working after the form is closed to new submissions (The form is open off). It stops for a ticket whose own Keep the sender informed is switched off, and for every ticket of a deleted form.

When a form stops working

A form only saves when the account it creates tickets as can actually add a task under the chosen target. If that changes later — the project is archived, the account loses access or leaves the workspace, the customer group is deleted, every offered task type is gone — submissions start failing. Visitors see only temporarily unavailable; the form is marked Needs attention in the list, and opening it shows what went wrong. Fixing the cause and saving the form clears the mark.

A form with a File upload question can stop for one more reason: the workspace's storage is full. Submissions that carry files are refused until there is room again. Deleting a task does not delete its attachments, so when you clear out unwanted submissions, delete their files on the Attachments tab first and then the tasks. Lowering Submissions accepted per day limits how much storage a flood of spam can use.

If the files of a submission cannot be stored because the storage service itself is failing, the task is still created and the visitor still sees the thank-you message. The task's description names the files that are missing, and the form is marked Needs attention.

A form with Check that the sender is not a robot turned on can stop for two more reasons, and in both the visitor sees only temporarily unavailable:

• The installation's keys for the check are missing or rejected. Every request is refused and the form is marked Needs attention with The robot check is misconfigured on this installation. Whoever runs the installation has to fix the keys. Until then you can turn the switch off and save: the designer keeps showing the switch, with a warning, so that you can.
• Cloudflare cannot be reached. Requests are refused until it can be. The form is not marked, because there is nothing in it to fix.

Every form of the workspace also stops accepting requests while the workspace is read-only. Visitors are told the form is unavailable; the forms are not marked, and they accept requests again as soon as a license is applied.

Deleting a form

Delete, in the row's More actions menu, removes the form and stops its link immediately. The tasks it already created stay exactly where they are.

Deleting a form also deletes the record of who sent each of its tickets and of what they were told. The tasks lose their From the public form card, their senders can no longer open the request's page, and nothing more is sent to them. Their comments stay on the tasks.