Send and track form requests
Ask a portal user to complete a form template with an optional message and due date, then follow it through pending, submitted, changes requested and approved.
A form request is a specific ask: this person, this form, by this date. It lands in their portal, comes back as a submission, and sits in your review queue until someone accepts it or sends it back.
Sending requests needs the portal-manage permission.
Before you send: templates
Form templates are your organization's active form configurations. The Form templates view in the portal console is a read-only inspector for them, with two tabs per template:
- Fields — every field with its type and whether it is required, grouped by section when the template has sections.
- Client preview — the form exactly as the client will see it.
Check the preview before sending a template for the first time. A field that reads fine internally often reads as jargon to the person filling it in.
Send a request
Send form request, from the page header or from a row in Portal users:
- Portal user — active users only. Someone still on invited cannot receive a request; get them activated first.
- Template — which form to send.
- Title — optional; defaults to the template name. Use it when the same template goes out repeatedly ("Q3 site survey — north depot").
- Due date — optional. Overdue requests are flagged in red in the queue.
- Message — optional note shown to the recipient with the request.
The request appears in their portal on their next sign-in.
The lifecycle
| Status | Meaning | Who it is waiting on |
|---|---|---|
| Pending | Sent, not yet submitted. | The client |
| Submitted | Filled in and returned. | You |
| Changes requested | Sent back with flags and notes. | The client |
| Approved | Accepted and closed. | Nobody |
The queue sorts by that reality, not by date: submitted first, then changes requested, then pending, with approved last. A submitted row carries a coloured spine because it is blocking a person; an approved row recedes.
Track the queue
The Form requests view is the console's landing view. The four tiles above it are filters, not decoration:
- Active portal users → the users list
- Awaiting review → submitted requests only
- Pending requests → waiting on the client
- Form templates → the template inspector
Under the tabs, status chips filter the queue further and carry their own counts, and the search box matches request title, portal user, and template name.
What the client does
In their portal, a request opens as a step-by-step form:
- Sections become steps, with Back and Next between them.
- Required fields are checked before the form can be submitted.
- A section can accept file attachments alongside its answers.
- After submitting, the form becomes read-only and shows "Your form has been submitted and is under review."
- If you request changes, it reopens prefilled with their previous answers, with your reviewer notes shown at the top and your per-field flags visible on the fields they apply to. They correct and Resubmit, which creates a new version rather than overwriting the old one.
Review what comes back
Open any submitted request to read it side by side with the reviewer panel: flag individual fields with an annotation, add overall reviewer notes, then Approve or Request changes. Every submission is kept as a numbered version, so you can open version 1 next to version 3 and see what moved.
Approving marks the submission reviewed and closes the request. It records the answers against the request — it does not write them onto the contact or opportunity record for you, so make any record updates you want deliberately.
The full review workflow is in Review a portal form request.
Practical tips
- Set a due date when you actually need one. Overdue is only meaningful if it is rare.
- Put the why in the message. "We need this to schedule your install" gets a faster response than a bare form name.
- Send one form per subject rather than one long form. A short form comes back complete; a long one comes back partly guessed.