# Form-to-Database Validation Workflow

Design a safe form-ingestion workflow that validates, normalizes, deduplicates, and stores submitted data with review queues and privacy controls.

## Prompt

You are a senior workflow automation designer. Your task is to design a form-to-database workflow that protects data quality and privacy before records reach downstream systems.

Design the workflow so it can be implemented in Zapier, Make, n8n, a native integration, or custom code. Do not pretend that you have connected to, configured, tested, or deployed any system. Do not invent field names, API capabilities, permissions, prices, limits, credentials, business rules, or approval authority.

USER INPUT
Form purpose and audience: {{form_purpose}}
Form platform and destination database: {{tools}}
Source fields and field types: {{source_fields}}
Destination schema: {{destination_schema}}
Required and optional fields: {{required_optional}}
Validation and accepted-value rules: {{validation_rules}}
Unique identifiers and duplicate rules: {{duplicate_rules}}
Consent, retention, and privacy requirements: {{privacy_rules}}
Downstream actions: {{downstream_actions}}
Review owners: {{review_owners}}

DESIGN METHOD
1. Define the submission event and anti-spam or authenticity checks.
2. Validate required fields, types, lengths, formats, ranges, and allowed values.
3. Normalize dates, phone numbers, names, identifiers, booleans, and controlled vocabularies.
4. Reject unsafe payloads and strip unsupported formatting without destroying source evidence.
5. Search for duplicates using approved unique identifiers and matching rules.
6. Route uncertain duplicates, invalid submissions, and privacy exceptions to human review.
7. Map accepted fields into the destination schema.
8. Define storage minimization, access, retention, deletion, and audit requirements from supplied policy.
9. Trigger downstream actions only after the database write is confirmed.
10. Add replay protection, logging, alerts, and a dead-letter or failed-record queue.

REQUIRED OUTPUT
A. Data contract and assumptions
B. Trigger and intake controls
C. Field validation table
D. Normalization rules
E. Duplicate and record-linking logic
F. Source-to-destination mapping
G. Privacy and retention controls
H. Review and rejected-record queues
I. Downstream action conditions
J. Failure handling and replay logic
K. Test cases and implementation checklist

CORE RELIABILITY RULES
1. Separate confirmed requirements from assumptions and unresolved questions.
2. Define one precise trigger and the conditions that should block false or duplicate runs.
3. Identify the system of record for every important field.
4. Map data explicitly between source and destination fields.
5. Validate required fields before taking downstream actions.
6. Use a stable unique identifier or idempotency key to prevent duplicate records and repeated messages.
7. Add human approval before external messages, publishing, payments, deletion, permission changes, or other difficult-to-reverse actions.
8. Define retries, timeouts, error logging, alert ownership, and a manual fallback.
9. Minimize movement and storage of personal or sensitive data.
10. Keep secrets in the automation platform's secure credential manager. Never request real API keys, passwords, access tokens, or webhook secrets.
11. Include test cases for the happy path, missing data, duplicates, invalid data, unavailable services, permission failures, and partial completion.
12. End with a clear list of items that require human confirmation before implementation.
13. Never collect or retain a field merely because it may be useful later; every stored field needs a stated purpose.
14. Do not silently overwrite an existing record when duplicate confidence is uncertain.

## Best for

Operations and product teams moving form submissions into Airtable, Notion, Supabase, spreadsheets, CRMs, or internal databases.

## Compatible tools

- Claude
- ChatGPT

## How to use

- Provide the full source form and destination database schemas.
- Define validation, normalization, duplicate, privacy, and retention rules.
- Review uncertain matching and overwrite behavior with the data owner.
- Test malformed, duplicate, missing-consent, oversized, and replayed submissions.

## Customization tips

- Use stable form submission IDs as idempotency keys.
- Store raw source data separately only when policy and operational need justify it.
- Add validation for attachments, file types, and file sizes when forms accept uploads.
- Define how users can correct or delete their submitted data.

## Example input

A Typeform application sends full name, email, country, portfolio URL, consent checkbox, and free-text notes to Airtable. Email is the unique identifier. Invalid URLs and unchecked consent must not enter the accepted table. Existing emails should update only the submission timestamp and notes after review. Downstream Slack alerts should occur only after a successful database write.

## Example output

Validation:
Full name: required, trim whitespace.
Email: required, normalize casing, validate syntax.
Country: required, map to approved country values.
Portfolio URL: optional, but must use an accepted URL format when present.
Consent: must be explicitly true.
Notes: apply length limit and preserve original text in the restricted source record.

Duplicate logic:
Search Airtable by normalized email.
New email → create accepted record.
Existing email → create Duplicate Review item; do not overwrite automatically.

Ordering:
Write and confirm the accepted database record first.
Only then send the Slack notification.

Failure handling:
Invalid records enter a rejected-record queue with reasons.
Temporary Airtable failures retry safely using the submission ID.
Repeated failures alert the workflow owner.