Forms & Consent Schema
Every PF TECH form, its submissions, and — kept deliberately separate — the marketing-consent registry.
What it stores
Every PF TECH form, its submissions, and — kept deliberately separate — the marketing-consent registry. The consent side is built to CASL, GDPR, and CAN-SPAM standards: double opt-in, suppression states, and right-to-erasure are all tracked in full.
Owned by the Forms agent. Lives in the Public Pages database · forms schema.
The tables
Friendly names first, with the real table name underneath. Key fields only.
Form Definitionsforms.definitions
The canonical definition of each form — its questions, routing, and lifecycle.
| Column | Type |
|---|---|
slugURL-safe identifier | Text |
title | Text |
statusdraft, active, paused… | Choice |
fieldsThe questions, in order | Structured |
routing_configWhere a submission goes | Structured |
Relationships
- one-to-many
forms.submissions. Receives many submissions - one-to-many
forms.versions. Has a version history
Field Typesforms.field_types
The registry of every supported question type.
| Column | Type |
|---|---|
label | Text |
categoryinput, choice, upload, layout, consent | Choice |
supports_options | Yes/no |
config_schemaValid settings for the field | Structured |
Submissionsforms.submissions
Every form submission. Note: a submission is not consent — see the Mailing List.
| Column | Type |
|---|---|
form_slug | Text |
email | Text |
payloadThe answers given | Structured |
referenceHuman reference, e.g. PFT-123 | Text |
Relationships
- one-to-one
forms.definitions. Belongs to one form
Mailing List & Consentforms.mailing_list
The marketing-consent registry. Every record requires double-confirmed opt-in; suppression and erasure are tracked for compliance.
| Column | Type |
|---|---|
email | Text |
statuspending, active, unsubscribed, bounced, complaint | Choice |
consent_versionPolicy in effect at opt-in | Text |
double_opt_in_confirmed_atThe authoritative consent moment | Date & time |
unsubscribe_tokenPermanent one-click unsubscribe key | ID |
erasure_completed_atWhen personal data was anonymised | Date & time |
Relationships
- one-to-one
forms.submissions. Links to the opt-in submission
Version Historyforms.versions
An immutable audit trail — one snapshot per version of each form. Never edited or deleted.
| Column | Type |
|---|---|
version_number | Number |
snapshotThe form as it was | Structured |
changed_by | Text |
changed_at | Date & time |
Relationships
- one-to-one
forms.definitions. A version of one form
You don't need all of this to start
Most of what these agents rely on has a simpler equivalent. Anywhere we use a database, you can usually start with a spreadsheet or a document — whatever you're comfortable with. Anywhere we built a custom MCP server, you can reach for a prebuilt AI connector instead of building your own.
We go further because it's where our experience pays off. Years of hands-on database work make a custom data layer feasible for us, and purpose-built MCP servers let us hand each agent a short, sharp instruction file and exactly the tools it needs — custom descriptions, only the endpoints we want, and the occasional extra gate — instead of a long manifesto or playbook. Nothing more, nothing less.
Ready to build technology that works for your mission?
Tell us where your organisation is and what's slowing your team down. We respond personally.