The Enquiry Is Closed — The Database Doesn't Have to Be

A client enquiry arrives on a Tuesday, gets answered by Wednesday, and turns into a quote by Friday. The form entry, meanwhile, stays in the WordPress database. And stays. And stays. Elementor Pro makes it easy to collect submissions; it does not make it easy to remember they are personal data with a shelf life.

That is the gap this routine closes. Not with a dramatic purge, but with a retention clock: a clear window, an export step, a scheduled cleanup, and a paper trail that matches what the client's privacy policy actually says.

Start with the purpose, not a magic number

Thirty days is a useful starting point for a general contact form on a small UK site. It is not a universal law. The right question is why the entry is still needed. A quote request may need to live for 60 or 90 days while the conversation is live. A project enquiry might need to stay until handover, then a short cool-off period. A newsletter sign-up should not be sitting in the same bucket as a complaint.

Map each form to a purpose and a window. Write it down. If the client's privacy notice says enquiries are kept for 12 months, but your build deletes them at 30 days, that is not a compliance win; it is an inconsistency. Either change the policy or change the clock. UK GDPR storage limitation is about having a reason, not about deleting everything as fast as possible.

Also flag forms that collect special category data — health details, accessibility requirements, religious information. If the site does not genuinely need it, remove the field. If it does, the retention window should be tighter and the handover should be more careful.

Export first, then delete the export too

Deletion without handover is just data loss with extra steps. Before any cleanup, use Elementor's Submissions screen to filter by form and date, then export the entries the client still needs. Hand that CSV over through a secure route — a shared client folder or an encrypted transfer — not a casual email attachment.

Record what was exported, when, and where it went. Then delete the working copy from your own machine. It is remarkably easy to leave a file called client-enquiries-final.csv in Downloads for six months and quietly create a second retention problem.

If the client wants entries in a CRM, import them first and confirm the import looks right. Only then should the WordPress copy be cleared. The form entry is the source; the CRM is the system of record.

Put the clock in the build, not just in a note

A retention rule that lives only in a handover document is a wish. Put it somewhere the site can act on. Name forms clearly, keep a simple register of form name, purpose, retention window and owner, and make sure the client knows which window applies to which form.

For straightforward sites, a scheduled cleanup is enough. For agencies, the register matters more than the code: it is what you check when a client asks why an old enquiry is still visible, or why it vanished before they had a chance to export it.

Automate cleanup without being cavvy

Elementor Pro does not ship with a retention timer, so you need a scheduled task. You have two sensible routes. The first is a well-maintained cleanup plugin that understands Elementor submissions and gives you a log. The second is a small custom routine run by WP-Cron or, better for client sites, a real server cron job.

Whichever you choose, test it on staging first. Take a backup. Delete in batches rather than one huge query. Confirm that the submission rows and their related meta are removed, and that the site still loads, forms still send, and the Submissions screen is not left with orphaned records. If you are writing SQL, check the table prefix and never run a delete without a date condition and a limit.

WP-Cron is traffic-triggered. On a quiet site it can drift. A server cron job that calls wp cron event run on a schedule is more dependable for a client build. Log the run, not just the deletion.

Leave an audit trail the client can file

A decent log entry is short and boring: date and time, site, form name, retention rule applied, number of entries deleted, oldest and newest entry dates, whether an export was taken, who ran it, and the result. Keep it outside the public web root or in the client's compliance folder.

That log does three jobs. It proves the routine is running. It gives the client something to show if a data subject asks what happened to their enquiry. And it saves you from trying to remember what you did six months ago when the site is handed to a new host.

Backups are copies too

Deleting an entry from the live database does not delete it from last night's backup, or from the host's 30-day snapshot. Do not promise a client that data is gone everywhere if that is not true. Document the backup retention separately, and if a restore happens, re-run the cleanup afterwards.

The practical line for most UK client sites is: live database cleaned on schedule, backups kept for the host's standard window, and a note in the handover explaining the difference. That is honest and workable.

The ten-minute monthly check

Add one recurring task to the agency calendar: check that the scheduled cleanup ran, skim the log, and confirm no form has quietly changed its name or purpose. It is a small habit, but it keeps the retention clock ticking long after the launch excitement has gone.

The enquiry is closed. The database should not be the last person to know.