Forms That Don't Just Collect Answers — They Start the Work

Form building is role-gated. Out of the box it's site administrators, and the builder role can be mapped to a different role when the app is installed — so if you want a small group of HR and ops owners building forms without full site-admin rights, that's a configuration choice at setup. There's no separate publish step to manage: saving a form makes it live.

Two things have to be true. The person is a signed-in Axero user, and they have permission to create the kind of content the form produces in the space it posts to. That second check is the useful one — it means you control who can submit by controlling the target space, using the permissions you already maintain, rather than managing a separate audience list per form. The check is enforced on the server, not just hidden in the interface. Routing forms, which create no content, are open to anyone who can open the page.

This is the part that works differently from a standalone form tool. A submission doesn't sit in a form-tool inbox — it becomes real intranet content in the space you chose: an article, blog post, wiki page, case, or idea. So who can see a response is answered by who can see content in that space, under the permissions already governing it. In practice that means responses are searchable, taggable, commentable, and reportable through the same tools as the rest of your intranet, and there's no second permission model to keep in sync.

File-upload questions attach the files to the content item the submission creates, as native Axero attachments — the same kind of attachment as a file added to any article or case. You can restrict which file types a question accepts, and allow multiple files per question. Access follows the created item: anyone who can open the submission can open its attachments, and anyone who can't, can't. Nothing lands in third-party storage.

It inherits the permissions of that content type in that space — the form doesn't invent its own access rules, which is what keeps this governable. The submitter is recorded as the author, so a submission is attributable without asking people to type their own name and department into the form. You can also set the title, summary, and tags of created content from a template, using answers from the form, so submissions arrive named consistently instead of as 50 variations of "request".

No — this is deliberately an internal form builder. Everyone who opens a form is a signed-in Axero user, which is what lets a submission carry its author, land under real permissions, and become content in the right space. If you need public-facing forms on your marketing website, keep using your marketing tool for that; Form Builder is for the internal processes behind the login.

Because responses are ordinary intranet content, they live under the same retention, archiving, and governance rules you apply to everything else in that space — there's no separate submissions database ageing out on its own schedule, and no vendor-controlled retention window. For reporting, the practical approach is to treat responses as content: filter and report on them in the space, or in the case or idea queue they feed. If you need a scheduled extract of submissions to a spreadsheet or another system, raise it on a call — that's a question about your specific reporting stack and we'd rather scope it than promise it.