Intake forms and the portal
An intake form turns a plain page of fields into a work item. This page covers building one, reaching it, and the portal where a signed-in requester submits and checks on their own requests.
An intake form belongs to one project. Submit it, and the server creates one issue there: a title, an optional description, and a value for each field the form exposes. The form's own defaults — issue type, priority, an initial state, labels, and more — fill in everything the submitter did not enter themselves.
Open a project's Project settings → Forms. Click New form.
A form has:
- A name and an optional description, shown at the top of the submit page.
- A title prompt — the label over the title box (default "Summary").
- A description area, on by default, with its own label and an optional Required toggle. Turn it off and the submit page has no description box at all.
- Any number of fields, added from Add a field: a dropdown of the custom fields already in the project's scope. Each one you add gets its own label override, help text, and a Required on this form toggle. A field can be required on one form and optional everywhere else.
- Defaults applied to every issue this form creates: issue type, kind, priority, an initial state, labels, an assignee, a cycle, a release, dates, the flag, and estimate points. Leave any of these unset, and the project's own default takes over — exactly as if someone had created the issue by hand.
- Let submitters share the request with one of their teams (off by default). Turn this on, and the submit page offers a team picker. Everyone in the chosen team can then open the request and check on it. See The service desk for how a mail-born request instead gets an external contact.
A form with no fields at all still works — it takes only a title (and a description, unless you turned that off).
A form is reached in one of two ways. The difference between them is who may use it without holding any permission on the project.
The portal, at /portal, is for anyone signed in. A form appears
there only when it is explicitly shared with a person or a whole team,
in the form's own Portal sharing list (below). A submission through a
shared form needs no permission on the project at all — the share itself
is what grants it. Someone completely outside the project can still file a
request this way. This is the path for people who need to reach a
project's requests without being members of it.
A member link inside the project sits at each form's Submit page. The form's own row, on Project settings → Forms, links to it — share that address directly with anyone who needs it. To open it, you need permission to create issues in that project. An ordinary project member reaches it with no share required; a stranger to the project cannot.
An earlier version of Radd also had a third path: a tokened link with no sign-in at all, for a requester with no Radd account. That path is gone. Mail reaches that person instead: an email to a connected mailbox opens or updates an issue, and its sender gets a reply back by email. Neither of these two form paths is involved — see The service desk.
On a saved form's builder page, the Portal sharing block lists the people and teams who see it on the portal and may submit it. Search and add a person or a team; presence in this list is the whole grant, with no separate levels. If you remove an entry, that person or team loses access to the portal copy of the form. It never affects the member link, which still opens for anyone with permission to create issues in the project.
Radd's form record also carries a flag for making a form visible to every signed-in person on the portal, with no explicit share. The current form builder has no control for turning it on — only Portal sharing, naming specific people and teams, is reachable from the interface today.
The portal, at /portal, is one page for everyone signed in:
- Submit a request lists every form shared with you or one of your teams, grouped by project. With none, it says so, and points you at a project administrator.
- My requests lists the issues you raised, and any raised for a team you belong to, most recently updated first. Each row shows its state, and whether someone answered since you last spoke. Open one to read its description and its public conversation, and to reply. You do not need to watch it yourself — the server adds you to its watchers the moment you raise it, so the ordinary notifications still reach you.
The portal never shows a request's labels, custom fields, worklogs, or internal-only comments — only what a requester needs to check on their own request.
The portal's submit page accepts file uploads even though the issue does not exist yet. Each file lands in a staging area that belongs only to you. It is moved onto the issue only when you go on to create one. A file you upload and then abandon, by closing the tab, is cleared out after a week. A second browser tab does not interfere with the first: only the files a submission names as its own move with it.
Approvals are not a form feature — they belong to a project's workflow. An administrator adds a Require approval rule to a guarded move between two states, in the Transitions section of Project settings → Workflow. The rule names who must approve: specific people, or a set number of members of a team.
Once that rule exists, moving an issue into the guarded state needs an approval request first. Each named approver votes to approve or decline. The issue moves automatically the moment every named approver, or each team's quota, is satisfied. A single decline ends the request.
A form's defaults can file an issue straight into a state that happens to be guarded this way. The same approval rule then applies to it, like any other move.
Mirrored from project.radd-hq.com on 2026-09-12. Documentation is written there; this copy is regenerated by scripts/publish_wiki.py and hand edits do not survive it.