Portal Forms

Connecting form data back to Growth Suite

Quick answer: Form submissions can automatically push answers into the parent's Growth Suite record — so your existing workflows, tags, and automations can react to a submission like any other event.

The basics

Each form has an optional writeback configuration — a small list that maps a form field to a Growth Suite custom field, like this:

When a parent submits the form, the system writes those answers into the parent's Growth Suite record. The write happens within a few seconds of submission and runs in the background — the parent doesn't wait on it.

Per-student writeback (the slot pattern)

Per-student forms write answers into per-student slots on the parent's record. A family with three children has three slots: student_1, student_2, student_3. The slot is chosen automatically based on which child the form was for.

So a Cafe Worker Permission Form for the second child would write:

• Growth Suite field student_2_cafe_worker_permission ← whatever the parent answered
• Growth Suite field student_2_cafe_worker_permission_date ← the signature date

This matches the per-student slot pattern that already powers the rest of Growth Suite, so all your existing reporting still works.

Why this matters

Once form answers are on the Growth Suite record, your existing automation tools work unchanged. You can:

• Add a tag when a specific form is submitted ("Photo Release on file 25-26")
• Send a workflow email when a permission is granted or denied
• Filter contact lists by completion status (e.g. "families who haven't submitted handbook acknowledgement")
• Trigger conditional follow-ups — if a parent uploaded an immunization exemption, send the next step in your enrollment workflow
• Power any segment in your dashboards using the same field as a filter

Setting up writeback on a form

For each form, the writeback config has a simple table the operator fills in:

1. Pick the form field you want to push.
2. Pick the matching Growth Suite custom field key. (Use Settings → Custom Fields in your Growth Suite admin to find or create the field first.)
3. Mark whether the writeback should use the per-student slot prefix or write to a family-wide field.

Important: the Growth Suite field must exist first

Writeback uses the field key to find the field in your Growth Suite account. If the key doesn't exist, the write is silently skipped (and shown as a "skipped" warning in the submission's sync status). Create the custom fields in Growth Suite first, then add the writeback config.

What happens if the write fails

The submission itself always succeeds — even if Growth Suite is temporarily unreachable. The writeback runs in the background and one of three things happens:

• Synced — everything wrote successfully
• Synced with skipped keys — some target fields didn't exist. Submission still succeeded; you just need to create the missing fields
• Error — the connection was temporarily unreachable. Shown as a red badge on the submission. Re-syncs are scheduled automatically

You can see the status of every submission in the Portal Forms Inbox widget on your admin dashboard.

Tips

• Keep field keys consistent across forms. If two forms ask "is this child allowed to take OTC medication", both should write back to the same Growth Suite field. The most-recent submission wins, which is normally what you want.
• Don't map every field. Map only the fields you actually need to filter or automate on. A free-form "additional notes" field probably doesn't need writeback — you'll read it in the inbox when reviewing the submission.
• Date fields write back as ISO dates (2025-09-15). Growth Suite's date triggers handle this format natively.

Related articles

• Per-student vs per-family forms
• Reviewing submissions
• The Student Health Profile