Intake forms
What this page is — bridges that turn each submission of a marketing form into a Papers document of a chosen type, with the submitted answers mapped into its fields.
What it is for — so a request that arrives through a form on your website becomes a real draft document, instead of a row somebody re-keys.
The problem it solves — form submissions are re-keyed into documents by hand, slowly and with transcription errors.
Route: /org/settings?tab=papers → Intake forms · Permission: Configure intake-form bridges: map a marketing form to a Papers document type with a field mapping so each submission auto-generates a document (FB-238)..
1. What it is
A bridge joins one marketing form to one document type:
| Part | You choose | Notes |
|---|---|---|
| Marketing form | The form to listen to | Fixed once created — delete and recreate to change it |
| Document type | What each submission becomes | Active types with a published version only |
| Title template | The generated document's title | Blank → {{form_name}} intake |
| Field mapping | Form field → document field | May be empty |
| Active | On / off | — |
How a submission becomes a document:
| Step | What happens |
|---|---|
| 1 | The form is submitted; the submission is queued on the Papers outbox as form.submitted |
| 2 | The outbox worker (RESIDENT_PAPERS_OUTBOX, about every minute) picks it up |
| 3 | Each active bridge for that form creates a draft of its type, in the bridge's project |
| 4 | Mapped answers fill fields; unmapped fields take defaults and merge sources |
| 5 | A second delivery of the same submission is skipped: a document for this submission already exists (skipped as duplicate) |
Bridges and generation triggers both listen. A form bound to a bridge and a form.submitted
generation trigger produces two documents.
2. Why you would use it
- No re-keying. The customer's answers land in the document's fields.
- Requests become work immediately. A draft appears in the documents list within about a minute.
- Deliveries are safe to repeat. The outbox may redeliver; the bridge will not duplicate.
- One form, one type, explicit mapping. What fills what is visible on one screen.
3. Step by step
- + Bridge → Marketing form → Document type.
- Optionally a Title template, e.g.
{{form_name}} — {{fields.company_name}}. - Field mapping — for each answer, pick the form field and the document field.
- Save and leave it active.
- Submit the form once yourself and check the documents list.
4. Field reference
| Field | Rules | Refusal |
|---|---|---|
| Marketing form | Required; cannot be changed afterwards | The form cannot be changed — delete this bridge and create a new one instead. |
| Document type | Required; must have a published version | type has no published version |
| Title template | {{form_name}} and {{fields.<form field id>}} | — |
| Field mapping | Form field id → document field name | field_map must be a JSON object of form field id -> document field name |
Retiring a mapped type is refused: this type is generated by a Papers intake bridge from the "X" form — delete that bridge in Organization Settings → Papers → Intake forms before retiring the type.
If a submission cannot become a document — the type lost its published version, say — the failure is recorded in the outbox audit, and the bridge still looks healthy here. Submit a test after any change to the type.
5. Designing a form for a bridge
A bridge can only map what the form asks. Start from the document type, not the form.
- List the type's required fields on its Fields tab. Each one is either a required form question, a default, or a merge source — or it becomes a draft someone has to finish by hand.
- Ask each question in the shape the field expects. A date question for a date field, a number for a number, a choice list whose values match the field's select options.
- Keep form questions stable once mapped. The mapping is keyed on the form field's id. Renaming a question's label is safe; deleting and re-adding the question gives it a new id, and the mapping silently fills nothing.
- Write the title template so a list of generated drafts is scannable — the requester's company, not the form's name alone.
- Test before announcing the form.
Test checklist
| Test | Expect |
|---|---|
| Submit with every question answered | A draft within about a minute, every mapped field filled |
| Submit with optional questions blank | A draft; those fields empty or at their defaults |
| Submit the same answers twice, as two submissions | Two drafts — duplicate protection is per submission, not per content |
| Check the draft's project | The bridge's project |
| Submit the draft for approval | No missing required fields refusal — or a known list of fields staff complete |
When the type changes
| Change to the type | Effect on the bridge |
|---|---|
| A new version is published | New submissions use it |
| A mapped field is renamed or removed | That mapping fills nothing, silently |
| A new required field is added | Drafts need that field completed by hand, until the form asks for it |
| The type is retired | Refused while the bridge exists |
6. Worked example
A sales team's website has an NDA request form: company name, contact name, email, purpose.
| Setting | Value |
|---|---|
| Marketing form | NDA request |
| Document type | Mutual NDA (India) |
| Title template | NDA request — {{fields.company_name}} |
| Mapping | company_name → counterparty_name · purpose → purpose · effective_on → effective_date |
Contoso submits the form. About a minute later the list shows NDA request — Contoso Ltd, a draft with the counterparty and purpose filled. The effective date is empty — Contoso left it blank — and the type requires it, so the legal assistant fills it before submitting.
Someone later adds a form.submitted generation trigger for the same form, and the next submission produces
two drafts. They remove the trigger.
7. The admin contract
| Must be true | Where | What breaks without it |
|---|---|---|
| The role holds Configure intake-form bridges: map a marketing form to a Papers document type with a field mapping so each submission auto-generates a document (FB-238). | Role editor | The section is missing |
| The type is active and published | Type Designer | Generation fails silently |
| The form asks for every required document field | Marketing forms; Fields | Drafts need completing by hand |
| The outbox worker is enabled | Job monitor | Submissions queue and nothing is generated |
| No trigger duplicates the bridge | Generation triggers | Two documents per submission |
8. Downstream
| When… | Then |
|---|---|
| A submission arrives | A draft of the type appears in the bridge's project |
| You deactivate a bridge | New submissions generate nothing |
| You change the type's fields | Mappings to removed fields fill nothing |
9. Don't confuse this with…
| The Service Desk catalog | Also form-driven, but creates tickets — see Orbit Resolve |
| Generation triggers | Any platform event, including form submissions |
| Capture inbox | Files that arrive, not structured answers |
| Building the form | Done in marketing forms; a bridge only maps one |
10. Troubleshooting
| Symptom | Cause |
|---|---|
| Submissions produce no document | Bridge inactive, type unpublished, or the outbox worker is off |
| Two documents per submission | A generation trigger also listens to the form |
| Fields are empty | Unmapped, or the answer was blank |
| The form cannot be changed | Delete and recreate the bridge |
| The type cannot be retired | A bridge uses it |