The Form submissions panel
Everything one client has sent back, across every form: the intake filter, what each column really shows, and how this list relates to their check-ins.
Open a client, pick Tracking, then Form submissions under Forms. This is everything that one person has ever sent back, whatever form it came from: the onboarding questionnaire, a par-q, a satisfaction survey, a form they filled in before they were even a client.
What the panel shows: every form this client has sent back
Three tiles and a table.
- Submitted counts every submission this client has, whatever the filter says.
- Answers adds up the answers across all of them, which is a rough measure of how much they have actually told you.
- Most recent is the date of the newest one, with how long ago that was.
The tiles count the whole history and do not follow the filter. The table does.
The columns, and one that is misnamed
- Date is when the submission arrived.
- Form is the form’s name, so you can tell two submissions apart without opening them.
- Type does not say what kind of form it was. It shows the action the form ran when it came
in, which is one of
CREATE_CLIENT,AUTO_ONBOARDorSEND_PDF_HOOK. Most forms run no action, and those rows read Submission. What you probably wanted from this column is the Purpose one. - Answers counts the questions answered on that submission.
- Purpose is the form’s declared purpose: INITIAL QUESTIONNAIRE, CHECK IN, SURVEY or OTHER. A form with no purpose set shows a dash, and that is common on older forms.
Click a row to open the submission with the form beside it, so every answer sits under the question that was asked rather than on its own.
The three filters
All, Intake and Other forms. Intake means exactly one thing: the form marked as the initial questionnaire. Everything else, including check-in forms and surveys, is under Other forms. If a client’s intake is not under Intake, the form it came from was never marked as the intake form; the answers are still there, under Other forms.
The list holds up to the 200 most recent submissions, which is more than any real client has.
How this relates to Check-ins
They are two different records and neither is a subset of the other.
A check-in is a progress entry: measurements, photos, notes, and your reply. A form submission is a set of answers to a form. They live separately, which is why they are separate panels.
Where they meet is a form whose answers are mapped to tracked measurements. When a client submits one of those, Protocol records the submission here and creates the check-in entry it describes, so the same event shows up on both panels with a different half of itself visible on each. Read the answers here; read the numbers, photos and your reply on the Check-ins panel.
The two ways they differ in practice:
- A check-in you logged by hand never appears here. There was no form.
- A survey, a par-q or a lead-magnet form never appears under Check-ins. There were no measurements.
What is not on this panel
There is no automations view here. A form can trigger automations, and several of them run on submission, but they are built and watched in one place, Vault → Automations, rather than in a smaller copy of that screen inside each client record. See Automations for building one and reading its runs.
You also cannot edit a submission from here. What the client sent is what they sent; corrections belong on the entry it produced, or in a new submission.
Related: Building forms for turning answers into tracked measurements, and Onboarding a client for getting the intake filled in.