Run registration intake
Purpose
Publish an application form, review who applies, decide, and get the answers out as a file.
Who this is for
Account administrators and whoever handles applications.
Where this lives
Registrations in the sidebar. Two things to know before you open it:
- The page's real URL is
/<accountId>/dashboard/team/triage, one level under Team & Access — which is why its breadcrumb reads Team & access › Registration triage. - The page still calls itself AI Gatekeeper Triage. That is the title, not a warning: it is the working registration inbox, and the subtitle says so — "Review registration payloads and apply an accept, waitlist or decline decision — by hand or by agent." Decisions made here are real.
The sidebar entry only appears if your role carries registration permissions.
Create a form
In Registration Form Configuration:
- Choose New form.
- Fill in Form name (required) and Survey Template ID (required). The template id must be typed or pasted — there is no picker. Copy it from the ID line under the template's name in the Assessments library.
- Optionally set a Public key and a Description.
- Set the visibility switches:
- Public — the form is reachable at all.
- Allow Incognito — off means applicants must sign in first.
- Allow Iframe Embed — off means the form refuses to run inside another site's page and offers a button to open it directly.
- Autonomous Triage Enabled — whether the assistant may pre-classify submissions.
- In Prompt rules, put one rule per line. These are the plain-language rules the triage assistant is asked to apply, and they are shown back to you in the Active Agent Rules panel.
- Choose Create form (or Update form on an existing one).
Applicants then use /register/<formId>. The form does not open on question one: it
opens on an email gate — Where should we reach you?, with the hint "Your application
is filed against this address, and the outcome is sent to it.", an Email address
field and a Start the form button. Nothing is filed until an address is given,
because the address is what the decision is sent to.
If the form is attached to a public campaign and that campaign has registration enabled in its access settings, the campaign's public page shows an Apply to Take Part button pointing at it. Attaching the form alone is not enough.
Set up what happens after a decision
Registration Actions (IFTTT) turns a decision into work. An action has a title, a condition, a type, and configuration:
Types available: Add User To Campaign, Assign Members To Participant, Add Labels To User, Add Labels To Member, Send Message To Member.
Configuration fields take comma-separated raw ids — campaign ids, member user ids, a role id — plus an optional message template. There are no pickers; copy the ids from the relevant pages.
Tags is the exception: it takes free-form text, not ids. Whatever you type there is
merged onto the person's labels on their campaign roster row or membership, so it is how
you mark a cohort you want to filter on later — wave:a, vip,
source:registration_form. Nothing has to exist first, and these are not label ids: the
field was called "Label IDs" until it was renamed to stop that reading. Actions saved
before the rename keep working, and are read back under the new name.
Capture the organisation and a group label from the answers
Two more fields on an Add User To Campaign action carry what the applicant told you onto their roster row, instead of leaving it in the submission for somebody to type in again afterwards.
The two fields sit together in a box headed What this form captures about the applicant, with a Preview underneath that reads back what a save will actually capture — one line per field, naming the question each one reads.
Organisation takes the name of the form question whose answer is the applicant's organisation — the question's name, not the words shown on the form. When they are accepted, the organisation named by that answer is matched against the organisations your account already has, one is created if it is new, and the person is linked to it. That link is what lets a report group by employer rather than by the spelling somebody typed; the matching rules are the same ones the import uses, described under The organisation on a participant's row. An applicant who leaves the question blank is linked to no organisation — never to an empty one.
Add a label field does the same for your own label groups. Each row is a pair: choose the Label group from the list — it offers the groups from Labels in your account settings whose applicability includes participants — and type the From question whose answer files the applicant under it. Add as many rows as the form feeds, and Remove the ones you no longer want. When the applicant is accepted, their answer becomes a label of that group on their roster row.
Two rows naming the same group is a half-finished edit rather than a choice: the last one wins, and the preview shows you which.
If the list of groups is empty — the account has none that apply to participants, or the
read failed — the row falls back to a typed box, and what you type there is the group's
key: one word with later words capitalised, so a group called "Department" is
department and one called "Service area" is serviceArea.
Three things are worth knowing before you rely on it:
- The group has to exist. Naming a group your account does not have is refused when you save the action, and the message lists the group keys you can use. It is refused then rather than ignored later, so you never leave a rule configured that could not fire.
- An answer that matches no label of the group is reported, not refused. The applicant is still accepted and every answer that did match is still written; the decision's result names the answer that could not be placed. The fix is either to add that label to the group or to correct the form's choices — the message is there so you can tell which.
- Nothing is ever created in your taxonomy to make an answer fit. A label group is a controlled list you maintain, and an intake door that could add to it would fill it with misspellings.
If the form asks a question in words that do not match your label names — "Public Works
Department" where the label is "Public works" — an action can carry a translation table
between the two. There is no field for it on this screen yet; it is set through the API
(valueMap on a label mapping) and this screen carries it through untouched when you
edit the action.
Having defined actions, bind them under Bind Actions To Form Branches to one or more of Accepted, Declined and Hold-like (Waitlisted / Human Review Required), then choose Save branch bindings. Unbound actions never run.
Review an application
The Submissions list on the left is deliberately named for what it holds: every submission in the account, decided or not. Each row shows the applicant's email and current state: Pending, Accepted, Declined, Review or Waitlisted. Select one to open it.
The workspace shows:
- Payload Answers — the submitted answers.
- Reviewer Notes — an internal thread; type a note and choose Save note.
- Decision Audit — who processed it and when.
Decide with Approve, Waitlist or Reject in the header. Recording a decision does two things: it sets the status, and it runs the actions bound to that branch.
What an acceptance sends
Approving does more than set a status. In one transaction it emails the applicant an acceptance letter, mints an invitation for them, and emails that too — and the second message matters more than it looks. An invitation's activation link is the only readable copy of its token: the token never appears in the submissions list, in an export, or in any API response, so an invitation that is minted and not mailed is an invitation nobody can use.
Both messages can be refused, and the screen tells you which:
- The address is on the suppression list. Nothing goes to it — not the letter, not the invitation. The applicant is still accepted; they simply have no way in until you pass the link on yourself, or an administrator removes the listing. An address lands there after a hard bounce, a spam complaint, an unsubscribe, or a manual entry.
- An identical message went a moment ago. Somebody applying twice is accepted twice, and the second acceptance finds their invitation still live rather than minting a new one. Re-sending it would put two messages carrying one link in their inbox, so the second is refused and named instead. Nothing is missing: they are holding it.
Silence means both messages went.
Run agentic triage asks the assistant to classify the submission against the form's
prompt rules. Its verdict and reasoning appear under Agent Verdict, attributed to
AI_GATEKEEPER. It sets a status like a human decision would, so treat it as a
recommendation you are accountable for, not an unattended process.
Edit an applicant's answers
Choose Edit answers above the payload. The answers become an editable JSON document. It must stay a valid JSON object — anything else is refused with "Answers must be valid JSON." or "Answers must be a JSON object." Save answers records the change against your user in the audit trail; Cancel discards it.
This is a raw editor. There is no form view of someone else's application on the admin side.
Applicants can also edit their own answers, but only if they applied while signed in,
and only before a decision is recorded — their page is /registrations/<submissionId>.
Applications submitted anonymously carry no user identity, so those applicants have no
self-service page at all; changes for them have to go through you.
Export the answers
Two buttons in the page header, with an Export as selector (CSV, JSON, XLSX) and a Form picker beside them:
- Export account — every registration submission in the account.
- Export form — only the currently selected form's submissions.
Both download a file directly, and both include the per-question answer matrix, not just metadata. Export is permission-gated on the server; if you are refused, the reason is shown.
Re-run a decision's actions
A decision's bound actions run once. Release decision clears that record so the next Execute actions runs the whole set again — the way out when the actions ran with the wrong configuration, or a message went to a mis-keyed address.
Releasing sends nothing by itself; arming and firing are two separate presses. What the re-run sends is worth understanding before you press it:
- Every action runs again. Three of the four are idempotent — they add somebody to a campaign, assign a reviewer, apply labels — so re-running them changes nothing.
- Send Message To Member is the one that reaches a person. It goes out again unless an identical message already reached that member in the last hour, in which case it is refused as a duplicate and reported back to you rather than delivered twice.
- So if the point of the re-run is to send a corrected message, edit the message first. An unchanged message inside the hour will not go.
Two different applicants tripping the same action still each get their own notice; the refusal only applies to the same message, to the same person, twice.
Limits and gotchas
- Accepting an application always emails the applicant twice — the acceptance letter and their invitation link. Anything beyond that (a note to your team, a place on a wave) is what the actions bound to the Accepted branch do.
- Declining, waitlisting or sending an application back for review emails the applicant nothing by itself. Only the Accepted branch has mail of its own.
- The submissions list is not filtered or paged. On a busy form it is a long list.
- Deleting an action also removes it from any branch it was bound to.