Guide 10 · Developer docs

Forms and data capture

Building forms with the Forms module: how a form is put together and placed on a page, validating and branching, presenting it, where submissions are stored, and what happens after one arrives, from jobs and records to CRMs and payments.

L1–L2
Unit 05 · Storing submissions

Retention and privacy

Storing submissions Page 11 of 20 Updated

What the platform keeps from a form and for how long, how to delete it, how to answer a request for someone's data, and what to agree with the client before launch.

Who this is for. The site builder and the project lead who hand a site with forms over to a client. Afterwards you can say where every copy of a submission lives, delete it on request, and write down before launch what the client has agreed to keep.

Forms are where a site collects personal data, and the first privacy request usually arrives months after launch, when nobody remembers what each form collects or where the answers went. The law that applies (the Privacy Act in Australia, the GDPR in Europe and the UK, and others) is the client's to decide with their own advice. This page covers the mechanics, which are the same under all of them.

What the platform keeps, and for how long

CopyKept until
Submissions, complete and incomplete, with every answerDeleted. There is no retention setting and no scheduled clean-up of submissions
Uploaded files, in the Files managerDeleted there. Deleting the submission does not delete them (File uploads)
Job runs, which keep what each action received and produced: answers rendered into emails and request bodiesDeleted automatically after the number of days in the Orchestration configuration, Delete batches after days: 30 by default, between 2 and 90
Emails sent by jobs: the mailer keeps each one, with its subject, recipients and rendered bodyKept; the platform has no scheduled clean-up of sent email
Copies outside the platform: notification emails in staff inboxes, CSV exports, CRM records, backupsWhatever those systems do

So by default everything a form collects is kept indefinitely, by the platform and by every system it was sent to. Carry out a retention policy as part of running the site, in the platform and in each of those systems.

Deleting

  • A submission is deleted in the admin, from the form's submissions listing, one row at a time. The API cannot delete submissions.
  • Its uploads are deleted in the Files manager. Each submission's files are in a folder named after its token, under user-files/form-submissions/<form name>/. Take the folder from a file's link in the submission's answers before deleting the submission, because afterwards nothing links the two.
  • Job runs clear themselves within the retention period. If they carry personal data, lower Delete batches after days, or set the job's Batch persistence to On Error so only failed runs are kept.
  • Everything outside the platform is deleted where it lives. This is why it matters which copies exist: a notification email with every answer in it is a copy in each recipient's inbox, kept for as long as their mail is. Prefer notifications that say "a new enquiry has arrived" and link to the admin.

Set a recurring task for whoever owns the site's data, at the interval the policy allows: list the submissions older than the retention period through the API (<created= the cut-off; Reading and exporting submissions), then delete them and their upload folders in the admin. It is manual, so make it someone's named job.

Answering a request for someone's data

A person asks what you hold about them, or asks you to delete it. For form submissions, the steps are:

  1. Find their submissions. The admin listing filters by date, not by answer, so search through the API. This request lists every form's submissions with an answer containing the address:
Shell 
curl -G "https://www.example.com/cdna-api/forms/submissions" \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  --data-urlencode '%25elementSubmissions.value=sam@example.com' \
  --data-urlencode 'limit=100' \
  --data-urlencode 'properties={id,form{id,name},created,completed,data}'

The % in front of the field is the "contains" operator, and in a URL it must itself be encoded, as %25; curl's --data-urlencode encodes only the part after the =. Left unencoded, some field names are decoded into something else, the filter no longer matches anything, so the request returns every submission. Check totalCount before sending anything to the person who asked. "Contains" also finds sam@example.com.au, so read the results before acting on them, and search again by phone number or name if the forms collect those. For a signed-in member, also list the submissions they sent while signed in, with createdBy.id=<their user id>: those match even when they typed a different address.

  1. To give them a copy, send the data of each submission and the files it links to. Nothing else about them is stored with a submission.
  2. To delete, delete each upload folder and then each submission, as above. Then the copies: the notification emails, any CRM or mailing-list record a job created, any export. List those systems in the site's handover documentation, because the request will arrive after the people who built the integrations have moved on.
  3. To correct an answer: a completed submission cannot be edited, in the admin or through the API. Correct the record downstream, where the answer is used (the person record, the CRM), or delete the submission and collect the details again.

Record each request: who asked, when, what was found, and what was done. The platform keeps no log of deletions.

What to agree with the client before launch

Each of these is cheap to settle before launch and expensive afterwards. Write the answers into the site's documentation:

  • For each form, what it collects and why. Remove any field without a use. A field nobody reads is still data you must find, protect and delete.
  • How long submissions and uploads are kept, per form. An enquiry and a job application rarely share a period.
  • Who can read them: which admin users have the Forms module, and which have the Files manager, which includes every upload.
  • Where copies go: who gets notification emails, which systems jobs send answers to, and who may export.
  • Who answers requests, within what time, and who carries out the deletions on schedule.
  • What the form tells the visitor. A short notice beside the submit button, in a Richtext element, with a link to the privacy policy: what the answers are used for and how long they are kept. Consent to anything optional, such as marketing, is a separate checkbox that starts unticked, and its answer is stored with the submission, which is your record of it.
  • What is not collected. The platform stores no IP address or browser with a submission. If the client needs evidence of when and how consent was given, add the fields for it now (what a submission stores); they cannot be added to submissions already made.
Go deeper
GuideReading and exporting submissions GuideFile uploads GuideHandover GuideHow a job's email is sent

Was this page helpful?

Your answer goes to the docs team.