Designing the form is half the job. The other half is making sure the right people see it and the wrong people don’t, that it’s available when needed and closed when it isn’t.
Publishing state
Forms have three states:
| State | Visible to users? | Submissions accepted? |
|---|---|---|
| Draft | No | No |
| Published | Yes | Yes |
| Closed | Yes (visible but with a notice) | No |
Set the state on the form’s properties page. Most forms move Draft → Published when ready, then Closed once the response window has ended.
Targeting by audience
Forms can be targeted at:
- Parents — appears on the parent dashboard / forms list.
- Students — appears on the student dashboard / forms list.
- Staff — appears on the staff dashboard / forms list.
Multiple audiences are allowed — a single form can be visible to all three.
For form types attached to another module (Booking, Activity Signups, Slips, Incident), the audience is implicit — the form runs as part of that module’s workflow.
Targeting by user attributes
For finer targeting, restrict to:
- Year groups — only show to families/students of specific year levels.
- Access groups — only show to members of a configured access group (often used for staff-only forms).
- Members directly — pin to specific individuals (rare, but useful for one-off forms).
Combine attributes — e.g. parents of Year 7 students only. The form is hidden from anyone who doesn’t match all the criteria.
Submission limits
Two options:
- One submission per user — each parent or student can submit only once. After they submit, they see their response rather than the form. Use for surveys, expressions of interest, consent forms.
- Multiple submissions allowed — users can submit multiple times. Use for things like report an issue or book a meeting.
Release and expiry dates
For forms with a time-limited window:
- Release date — the form moves to Published automatically on this date.
- Expiry date — the form moves to Closed automatically on this date.
Use these to set-and-forget a form’s availability — e.g. a survey that opens Monday at 9 am and closes Friday at 5 pm.
Notifications when published
When you publish a form (or it auto-publishes on a release date), PortalHQ can:
- Add a notification to the targeted users’ dashboards.
- Send an email to targeted users.
Configure these in the form’s notifications section. For high-priority forms, both is useful — the dashboard catches users who log in, the email catches those who don’t.
Slip integration
For Slip-type forms, the publication settings are taken from the Slip’s settings rather than the form itself. The Slip determines who sees it and when; the form just defines the fields.
Embedding in other workflows
Forms attached to a Booking Event or Activity Group inherit visibility from that parent:
- Booking forms appear when a parent books a session — see Linking a custom form to a booking event.
- Activity signup forms run during co-curricular signup — see Managing signups.
- Incident forms are invoked from the coach roll page — see Administering rolls and attendance.
You don’t set audience or release dates on these — the parent module controls visibility.
Testing before publishing
Always preview the form as the target audience before publishing:
- Use a test parent or test student account if your school has one.
- Walk through the form end-to-end, including any required fields.
- Submit and check the submission appears in the submissions list.
- Test any email notifications by submitting from a real account.
Issues caught at this stage are easy to fix; issues caught after 200 parents have submitted are not.