Data Privacy, Security, and Consent

Overview

Forms collect personal data, so StretchForms is built to keep that data private and under your control. This article explains the protections that apply to every form and response — tenancy isolation, consent, PII handling, the guarded automation model, and the audit trail — and how to configure forms responsibly.

Tenancy isolation

Everything in StretchForms is scoped to your organization. Forms and responses are served through the workspace gateway, which hard-filters every read and write to your workspace. There is no shared public list and no cross-organization access — another tenant simply cannot see or touch your data.

The suite also keeps the public surface closed by default: the public form builder and public writes are off, so forms and submissions live inside your authenticated workspace rather than on an open endpoint.

When you collect personal data, capture consent explicitly:

Add a checkbox field for terms/privacy agreement (see Building a form).
Mark it required if agreement is mandatory to submit.
Submissions record consent flags for terms and privacy, so you have a record of what each respondent agreed to.

Always link to your actual terms and privacy policy in the field label or nearby helper text.

PII handling

Contact-style submissions carry personal data — name, email, phone, company — alongside the message and source. StretchForms treats this carefully:

The submission detail view that shows PII is admin-gated; only people with the right read access see it.
When the Intelligence engine is enabled, it can detect PII in a response and flag it, so handlers know to be careful.
Follow the principle of least data: only ask for the fields you genuinely need to act on a response.

Guarded automation

StretchForms is intentionally conservative about letting algorithms act. Under the algorithm contract:

Allowed now (read-only): intake classification, routing recommendation, validation quality, spam/risk detection.
Dry-run only: CRM-handoff scoring, support-priority scoring, automated assignment — these suggest, they don't act.
Autonomous mutation is off. The engine never changes a submission; StretchForms stays the system of record.
Persisted outputs are audited. If an algorithm result is ever stored, it's recorded for review.

This means a human is always in the loop for anything that changes ownership, priority, or routing.

Action tokens and audit trail

Changes to forms are treated as sensitive:

Admin creates, updates, and deletes require a step-up action token — an everyday read token isn't enough to change a form.
Each of those actions is recorded as a sensitive action with the form key, type, status, and target app, giving you a clear audit trail of who changed what and when.

Example: a compliant intake form

A clinic builds a New Patient form:

Asks only for the fields needed to book (name, contact, reason for visit).
Adds a required consent checkbox linking to its privacy policy.
Keeps the form inside the workspace — no public endpoint.
Limits who can open the PII-bearing detail view to front-desk staff.
Relies on the audit trail to show exactly who edited the form during an internal review.

Tips

Collect the minimum. Fewer personal fields means less risk and higher completion.
Make consent explicit and linked to your real policies.
Restrict PII access to the people who genuinely need it.
Lean on dry-run while you build trust in any automation — nothing changes without a person.
Use the audit trail during reviews to demonstrate control over changes.

FAQ

Can the public reach my forms directly? Public writes and the public builder are off by default; forms live in your authenticated workspace.

Does the AI or classification engine store my data elsewhere? Classification is read-only and doesn't mutate submissions; api-core remains the system of record, and any persisted algorithm output is audited.

Who can delete a form? Only someone with the write action token — and the deletion is recorded as a sensitive action.