Deleting Submission Data

Unqork supports two deletion modes: soft delete and hard delete. Soft delete marks records as deleted but keeps them in the database. Hard delete permanently removes the submission document from the database. File attachments, PDFs, and Excel files in cloud storage are not removed by a hard delete. Those must be deleted separately using the attachments endpoint before hard-deleting the submission.

Order of operations matters. Always delete attachments and revisions before deleting the parent submission. Deleting the parent first removes the reference needed to locate associated files.

What Counts as Submission Data

A submission in Unqork encompasses more than its JSON document. A complete hard delete must address each of the following data types:

Deletion Methods

Two tools support hard deletion: the Bulk Data Operations (BDO) tool and the Submissions REST API. BDO is the recommended approach. It handles both workflow and module submissions without requiring separate calls per submission type.

Hard Delete Flag

Each method uses a different hard delete flag:

• BDO: Set bdoJobRecord.data.options.delete.mode = delete in the job configuration.

• REST API: Append ?destroy=true to the request.

Without the hard delete flag, the operation performs a soft delete only.

Coverage by Data Type

Workflow submissions always act as entry point modules and workflows. Any data created by modules within a workflow is stored under the workflow submission, not the individual module submissions. For workflow-based applications, deleting only schema or module submissions leaves the workflow submission, including its revisions, intact. The workflow submission must be explicitly included in the deletion process. Deleting workflow submissions and their revisions requires two separate BDO operations: POST /bulkOperations/delete for submissions, then POST /bulkOperations/deleteRevisions for revisions and their S3 data objects.

Disabling Submission Revisions

Submission revisions are stored by default for all entry point modules and workflows. Revisions can be disabled at the application level in Application Settings.

Disabling revisions triggers a background cleanup job that deletes existing revisions for all active (non-deleted) submissions, including their S3 data objects. Revisions for previously soft-deleted submissions are not included in this cleanup and must be removed separately using the deletion methods above.

For environments with strict data retention requirements, disabling revisions reduces ongoing data accumulation. It also simplifies the deletion workflow by eliminating the revision step for new submissions.

Order of Operations

Follow the steps below to ensure all associated data is removed before the parent record is deleted.

1. Delete file attachments: Use the REST API attachments endpoint for the submission. Save the attachment delivery URLs before this step. They are needed to identify the S3 objects to remove. Once the parent submission is deleted, those references are no longer accessible from the submission document.

2. Delete revisions: Use BDO (POST /bulkOperations/deleteRevisions) or the REST API revisions endpoint.

3. Delete the parent submission: Use BDO (POST /bulkOperations/delete) or the REST API with ?destroy=true.

Cleaning Up Previously Soft-Deleted Records

If an existing batch process has been performing soft deletes instead of hard deletes, those records still exist in the database with a deleted flag. The attachment and revision references are intact but the records are marked inactive.

Query and delete without restoring: Use GET /modules/:formId/submissions?includeDeleted=true to retrieve both active and soft-deleted submissions. Soft-deleted records include a deleted field (Unix timestamp) in the response. File delivery URLs can be extracted from the data field without restoring the submission. The per-submission deleteRevisions endpoint works on soft-deleted submissions without restoring.

Restore first: Undelete the record to make it accessible through the standard deletion endpoints, then follow the standard order of operations above. Use this approach when the delivery URLs were not preserved and cannot be reconstructed from the soft-deleted record.

Service Log Configuration

Unqork has two separate log systems with different defaults and controls.

Plugin/Integrator service logs record request and response bodies for calls made through Plug-In components and integrations. Body capture is off by default and controlled per service in Services Administration (Capture Request & Response Bodies setting). The TTL is configurable per service from 0 to 30 days.

Module execution logs (remote execute/SSE) record request and response bodies based on the environment-level Server Side Execution Request/Response Body Log setting in Environment Administration. The default is Error Only, which stores request and response bodies for any failed request (HTTP status 400 or above), even without explicit configuration. Set to None to disable body capture entirely. The TTL is fixed at 3 days in non-production and 30 days in production and cannot be configured.

S3 Lifecycle Policies

When a hard delete is issued, the platform removes the record from its database immediately. However, the underlying files in S3 are not physically removed until the bucket's lifecycle policy expires them.

The default S3 resource bucket lifecycle policy is 180 days. Environments with strict data retention requirements (for example, a 7-day deletion window) require the lifecycle policy to be adjusted. Contact Unqork Support to request a lifecycle policy change for a specific environment.

Database Backup Retention

Hard-deleting a submission removes it from the live database immediately. MongoDB database backups follow a standard retention schedule and retain submission data until the backup retention period expires. A hard-deleted record can still be recovered from a backup until that backup ages out.

Environments with strict deletion windows (for example, 7 days) require a custom backup retention policy. Shortening the backup retention period means losing the ability to restore the database to an earlier snapshot. Acknowledge that tradeoff before requesting the change. Contact Unqork Support to discuss backup retention adjustments for a specific environment.

Known Limitations

Orphaned File Attachments

Files uploaded through the attachments endpoint are associated with a module, not directly with a submission. If the upload call succeeds but the submission save fails, the file exists in S3 with no submission reference. The platform has no retrieval or deletion  for these orphaned files.

Data Model Attachments

File attachments associated with data model records are not covered by BDO or the REST API. If the implementation uses data models with file attachments, those files require a separate deletion process outside the standard submission deletion workflow.

Data Model Revision S3 Objects

The REST API revision delete endpoint for data models (DELETE /dataModels/records/revisions) removes MongoDB documents only. S3 revision data objects are left orphaned. Use BDO deleteRevisions to remove both MongoDB documents and S3 objects for data model revisions.

Audit Log Metadata

Instrumentation audit events are written to S3 for every submission create, read, update, and delete operation. These records include submission IDs, operation type, user, and timestamps. No field values or submission data are included. Audit log metadata is permanent. There is no delete API. Clients with strict data retention requirements should be aware that submission metadata persists in audit logs regardless of whether the submission itself has been hard-deleted.

Tracker Records

The tracker collection stores component value fields (actual field values linked to submission IDs). Tracker records are not removed by any submission deletion path. They expire based on a TTL, but represent a transient data trace that persists after a submission is hard-deleted. Clients with strict data retention requirements should account for this when designing deletion workflows.

Out-of-Platform Data (Emails and SMS)

Workflow timed events can send SES emails and Twilio SMS messages with full submission data rendered into templates. Once sent, this data is outside Unqork platform control and cannot be recalled or deleted through any platform mechanism. Clients with strict data retention requirements should review whether their workflows  email or SMS delivery containing submission data.

Module Log TTL

Module execution logs retain data for 30 days in production environments. The TTL is hardcoded and cannot be shortened through configuration. For environments with sub-30-day retention requirements, the gap must be disclosed to clients.