Many forms need more than one person. A second applicant adds their own details, an employer or adviser certifies part of an application, a client finishes what an adviser started, or your own team reviews a submission before it goes anywhere. FormsByAir has several mechanisms for this, and they combine. This page sets out what each one does, what each person sees, and when to use which.
The options at a glance
| Option | Who does what | Who triggers it | What the other person sees | What the main form filler does afterwards |
|---|---|---|---|---|
| Third party request | Someone else completes one part, on their own device | The form filler, from a send them a request link inside the part | The form opens on the section holding their part; everything outside the part is read-only, with a prompt to review the rest | Keeps filling out the form, waits for the part if they didn’t complete it themselves, then submits |
| Required request | Someone else must complete one part; the form filler cannot | The form filler, from a Generate Request button they cannot skip | As above | Cannot pass the part until it is completed, so they save, come back and submit |
| Review request | A reviewer the form filler chooses checks the whole form and adds their own details | The form filler, at the end of the form | The entire form read-only, with their own part to complete at the end | The form is locked while the review is outstanding; they submit once it is done |
| Staged submission | The same person, or someone the link is passed to, completes a later part after an earlier part has been submitted | Submit on the section that ends each stage | Only the current stage; completed stages are not shown | Each stage is submitted in turn; nothing further once the last stage is in |
| Staged with required requests | Named people complete their parts after the form filler has submitted theirs | FormsByAir, automatically, when the earlier stage is submitted | Their stage, with only their part editable; earlier stages are not shown | Nothing; the last request to be submitted submits the form |
| Prefill | Someone starts the form for someone else, who then completes and submits it | Your team in the portal, an adviser on a Third-Party Prefill form, or the API | The whole form, with the prefilled answers in place | The person who prefilled takes no further part |
| Workflow | Your own team reviews, adds office-use information, approves or returns a submission | Submission of the form | Your team sees the submission read-only plus workflow-only content; the form filler sees nothing unless the document is returned | Only if the document is returned for changes |
Third party request
A Request element wraps the part of the form someone else completes: their personal details, identity verification, a signature. The form filler can complete it themselves if that person is with them. If not, they click send them a request, FormsByAir creates a request with its own link, and the other person opens the link on their own device, completes the part and submits it. Their answers merge back into the main document and the form filler carries on.
Use it for parts that belong to someone else who is not in the room: additional applicants, directors, trustees, guardians. Put the Request at the top of each person’s row in a repeater, with Hide First so the first row, which is normally the form filler, does not show the prompt. See Elements > Request for the element, its options and the email integrations.
What the other person sees: the form opens on the section that holds their part, with the rest of that section read-only. A prompt asks them to complete their part, review the rest of the form, then submit. By default what they enter is not shown to other people completing requests in the same form; the Shared option changes that.
Sending the link: FormsByAir does not send anything by default, the form filler passes the link on. Add an email integration with delivery type On Third Party Request to have FormsByAir send it. Its recipient must be a tag for an email address question inside the Request. The form filler sees that address in a box when they generate the request and can change it; if the question is blank, they type it there. Add an On Third Party Submit email to tell the form filler when the part has been completed, with the link back to the main document.
Required request
Tick Required on the Request when the form filler must not complete that part themselves, for example a section an employer, lawyer or accountant has to fill in. The prompt becomes a Generate Request button, and the form will not move past that part until a request has been generated and then completed. The form filler saves, waits for the other person, opens the saved form again and submits.
Because the form filler has to come back, pair a Required request with an On Third Party Submit email to them carrying the link to the main document. Without it, they only find out the part is done by reopening their saved form.
The recipient for the On Third Party Request email follows the same rule as above: a tag inside the Request. If the address is known from an earlier answer, for example looked up from an employer selection, store it in a hidden formula inside the Request and point the email at that tag; the form filler then sees it prefilled.
Review request (Required + Lock Form)
Tick both Required and Lock Form on a Request placed in the last section of the form. This is for a reviewer the form filler chooses, such as their financial adviser or solicitor, who must check the whole application and then add their own details.
The form filler completes everything, is forced to generate the request before they can submit, and from then on the form is locked. The reviewer opens the link, sees the entire form read-only, completes their part at the end and submits. The form filler can then submit, or cancel the request if they need to change something or send it to someone else.
Use a required request in a staged form instead when the reviewer is a specific person or group you already know, rather than someone the form filler picks.
Staged submission
Submission Mode = Staged, in Form Settings, turns one form into a sequence of stages, each with its own Submit. The next stage is completed later: by the same person, who prints, signs and uploads, or supplies something they did not have, or by someone the link is passed to, such as a manager signing off.
On their return only the current stage is shown. Completed stages are not rendered and cannot be reached with Back, but their answers are still in the document, so a display note of tags can summarise what was submitted earlier. FormsByAir does not send the link between stages: add an email integration on the earlier stage that carries it. The section that ends each stage can be named with a Tag Name, and <<[DocumentStage]>> then tells your integrations which stage has just been submitted.
Use it when the later part can only be done once the earlier part has been submitted, or when the whole of a later part belongs to a different person who does not need to see the earlier one.
Staged submission with required requests
When a staged form has Required requests in a later stage, FormsByAir generates those requests itself as soon as the previous stage is submitted, and sends each one to the address its On Third Party Request email resolves. The form filler is not asked for an address and cannot cancel the requests; they only see their status. The main document sits in Requesting status until every request is submitted, and the last submission submits the main form. More than one stage can carry required requests, for several rounds of review or approval.
This is also the secure way to collect a part the form filler must not be able to reach. Each request is a separate document with its own id, created on the server and sent directly to the third party; the form filler is never shown it. While the requests are outstanding the main document is in Requesting status, which the form page will not open, so the form filler’s original link returns the same generic “Form Not Found” page as any other link that cannot be opened. That page is deliberately vague: it does not reveal whether a document id is, or ever was, valid. A required request in a Normal form keeps the main document saved and open to the form filler, with the request id stored inside it.
The people completing the requests see their stage with only their own part editable; the stages submitted before it are not shown. If they need the form filler’s details in front of them, repeat those details inside the request as display content.
Use this when a form is sent to a primary contact for general completion but must be seen or authorised by every party, and the parties are known: trustees, directors, an employer whose contact address is on file. After Third Party Request reminder emails are available to chase outstanding requests.
Prefill and requests
Prefill is the other direction: someone starts the form for the person who will submit it. Your team can prefill any form from the portal and generate a request; a form in Third-Party Prefill access mode opens in prefill mode for advisers and other third parties working on behalf of their clients; and the API creates requests programmatically. The resulting document is Requested, the On Request email carries the link to the recipient, and the request expires after the form’s Document Request Expiry period (see Expiry). Request Only access mode stops anyone opening the blank form, so the only way in is a request.
Third party requests cannot be generated while prefilling. A prefilled form that also uses requests has the form filler generate them when they open their request.
Workflow
Workflow covers your own team rather than other form fillers. After submission the document enters a queue, is assigned by rules or self-assigned, and is reviewed read-only alongside any Workflow content, the office-use-only part of the form. The reviewer approves, returns the document to the form filler for changes, assigns it on, or declines it. Authorisation adds a second, senior sign-off.
Workflow sits on top of any of the options above. A document waiting on third party requests is saved, not in workflow, until the form filler submits it. In a staged form each stage’s submission goes through workflow unless a Bypass Expression lets the earlier stages straight through.
Choosing
- Another applicant or a signatory adds their own details, and may or may not be with the form filler: a third party request, inside the repeater row, with Hide First.
- A part that must be done by someone other than the form filler, and the form filler should carry on and submit afterwards: a required request, with an On Third Party Submit email to bring them back.
- A reviewer the form filler picks must see the whole form and sign off before it is submitted: a review request, Required and Lock Form, in the last section.
- A known person or group must complete or authorise their part after the form filler has finished, and the form filler should not have to return: staged submission with required requests.
- The same person must come back later for a second step: staged submission.
- Someone starts the form for the person who submits it: prefill, with Third-Party Prefill access mode when the starter is outside your organisation.
- Your team must check or add to a submission before delivery: workflow.
Combining them
- Post-submit identity verification inside a request runs when the main form is submitted, not when the request is. A request whose verification needs another attempt can be returned to the third party from the portal while the main document is saved or in workflow before authorisation, and resubmitted as many times as needed.
- Requests inside a staged form behave as third party requests within their stage; only Required requests in a later stage are generated automatically.
- A document waiting on requests or verification is in Requesting status and is treated like a saved document for expiry: after 30 days it moves to workflow if the form uses it, otherwise it expires.
- Submission Mode, Access Mode, workflow settings and email integrations are form settings in the portal. Copying a form carries them; deploying a schema onto another form does not, so set them on the target form as well.