Short-lived rich content
Unconverted enquiry text, image files, and chat bodies should leave the system faster than core evidence rows.
Retention
Proposed retention and evidence schedule
FluxService aims to keep rich operational content for the shortest useful window while preserving the minimum evidence needed for accepted jobs, payment events, payout events, disputes, deletion proof, and compliance. The retention periods below are a proposed schedule for legal and operational review rather than final public commitments.
Retention lifecycle
The goal is to move from rich data to minimal evidence, then delete when the record no longer has a lawful purpose.
Longer-lived core evidence
Accepted-booking records, payment references, payout references, and deletion-proof records stay longer for compliance reasons.
Backups expire separately
Deleted records may persist only inside encrypted rolling backups until the snapshot window ends.
Legal hold overrides
Open disputes, fraud checks, regulator requests, complaints, or claims pause normal deletion immediately.
Draft status
The periods below should be read as a proposed schedule for counsel review. Some windows are already aligned with the current operating model, while others still need final legal sign-off against contract, tax, payments, and complaint-handling requirements.
- Active use
Operational content is available while the enquiry, quote, booking, payout, or support issue is still being worked.
- Archived evidence
Once a job or transaction is complete, only the evidence still needed for operations, disputes, or compliance remains in longer-term storage.
- Minimized record
Where possible, message bodies, file content, and rich text are deleted first while minimal metadata stays.
- Final deletion
At expiry, the remaining record is deleted unless a legal-hold condition still applies.
Full retention matrix
This matrix reflects the current app data model plus the main operational records that may sit outside the app tables, such as mailbox support traffic and backups.
Implemented vs proposed
Some rows below reflect the current operating model and existing data structure. Others are proposed retention windows that still need final legal or tax review before they should be treated as binding public commitments.
| Data set | What is stored | Retention period | Deletion or minimization action |
|---|---|---|---|
| Authentication and access events | Detailed sign-in or token metadata, success or failure, timestamp, and IP or device details where supplied by the auth or platform stack | 90 days for detailed auth events | Delete detailed events at day 90 and keep aggregate security metrics only |
| Profile core | profiles: name, email, phone, avatar reference, role, onboarding state, and limited account flags | While account is active | After closure remove direct identifiers within 30 days unless legal hold applies |
| Plumber onboarding and compliance profile | plumber_details: regions, business details, service type, gas-safe details, consent, eligibility attestations, rating, and approval state | While account is active | After closure remove direct identifiers within 30 days unless legal hold or linked financial records require a narrower residual reference |
| Payout onboarding record | plumber_connect_accounts: Stripe account ID, onboarding status, payout flags, charges flag, and due-count state | 6 years from end of financial year after final payout activity | Retain only the minimum processor and reconciliation references needed for accounting, disputes, or legal hold |
| Unconverted enquiries | enquiries with no accepted booking: issue text, address, preferred date or time, chatbot transcript, and timestamps | 90 days from last activity | Delete enquiry body and keep anonymized analytics only |
| Unconverted enquiry files | Stored enquiry photos and attachment objects referenced from enquiries.images | 14 days | Hard-delete at day 14 if no booking or dispute exists |
| Quotes not accepted | jobs rows that were quoted, declined, or cancelled without becoming the accepted booking, including amount, schedule, plumber ID, and quote description | 12 months | Delete quote-level detail and keep aggregate conversion metrics only |
| Accepted booking and job evidence | jobs and linked accepted workflow evidence: accepted quote, status timeline, participant refs, PIN state, completion confirmations, and close-out state | 6 years from close or cancel | Delete at expiry unless legal hold applies |
| Job chat bodies and attachments | job_messages.content and any related files used during active coordination | 30 days after close or cancel | Delete message body and files while keeping minimal metadata |
| Job chat metadata | job_messages metadata such as job ID, sender ID, timestamp, and delivery or read state | 6 years from close or cancel | Delete at expiry unless legal hold applies |
| Payment and payout ledger | payments and payout_transfers: payment references, charge or transfer references, refund or reversal state, dispute state, fee amounts, and delay reasons | 6 years from end of financial year | Retain minimal accounting and dispute evidence only |
| Webhook event records | webhook_events: processor event ID, event type, object ID, processing result, and error code | 18 months | Delete event rows at expiry and keep only high-level operational reporting if still needed |
| Support requests | Email or mailbox support content, contact metadata, and follow-up notes where support is handled outside the core app tables | 24 months from close | Delete ticket body and keep anonymized support metrics only |
| Security logs | Authentication incidents, abuse monitoring, admin or API access logs, and incident-response traces | 12 months, or 18 months if an incident is still open | Rotate and delete automatically |
| Backups | Encrypted database and object snapshots | 35-day rolling window | No selective edits inside snapshots; deletion completes when snapshots expire |
| Deletion audit trail | Dataset, record ID, deleted time, reason, and actor or service where a deletion-control record is kept outside the primary app tables | 6 years | Keep minimal compliance evidence only |
Open mapping items for legal review
A few current schema-backed records still need final retention wording signed off explicitly rather than only by implication.
Reviews
reviews stores rating, comment, and moderation flag state. Final public retention wording should be stated expressly.
Fee penalty records
plumber_fee_penalties tracks fee-multiplier enforcement and should be mapped explicitly to finance or booking-evidence retention.
Mixed chat table design
job_messages currently stores body and metadata together, even though policy splits the two retention tracks conceptually.
Converted enquiry files
The current draft names unconverted files clearly. Final wording should also state the retention rule once an enquiry becomes a booked job.
Legal hold override
Normal deletion stops as soon as a record becomes relevant to an active hold condition.
Deletion pause conditions
Chargebacks, fraud investigations, complaints, legal notices, regulator requests, or claims can all pause scheduled deletion until the hold is cleared.
Liability model and physical records
Retention rules support the platform’s role as a marketplace and workflow system rather than an on-site contractor.
- FluxService acts as the marketplace and workflow platform.
- Independent plumbers remain responsible for on-site execution quality and local trade duties.
- Payment processors handle financial movement and onboarding references where integrated.
- Non-excludable legal or statutory duties still apply where required by law.
Paper-only storage is not a workaround
Moving records to paper does not remove data protection duties and usually weakens security, searchability, and deletion control.