GDPR / data protection
Overview
Two jobs sit together here because they belong together: handling data subject requests and maintaining retention policies. Two tabs, Subject requests and Retention.
Data subject requests are the rights people hold over their data — access (Art. 15), rectification (Art. 16) and erasure (Art. 17). The purpose of this surface is not that requests get handled at all, but that the handling is traceable. A request fulfilled but not documented is worthless when it matters.
Core tasks
Create a request. New request records the case as soon as a data subject asserts their rights. The case is carried from recording through to completion.
Provide access. For an access request, the stored data can be produced and downloaded.
Carry out erasure. Erasure is handled through the case and therefore stays evidenced.
Maintain retention. The second tab holds the policies by which data is removed once its period expires. That is the other half of data protection and the less comfortable one: keeping data for which there is no longer a reason is as much a breach as a failure to erase.
Fields in detail
Two masks, one per tab: the data subject request and the retention policy. Alongside them sits the rectification dialog, which takes the corrected master data.
Data subject request
| Field | Required | Values / format | What it does |
|---|---|---|---|
Request type type | yes | access (Art. 15) · rectification (Art. 16) · deletion (Art. 17) | What is demanded — and therefore which action the row offers later. These three kinds only; a restriction of processing is expressed through the retention action seal, not here. The mask offers it on creation only; editing leaves it as it is. |
Email of the data subject subjectEmail | yes | email address | The key to the whole case. Access and erasure search across every module for exactly this address; a typo returns an empty disclosure, not an error. |
Name subjectName | no | text | What the person is called. For recognition in the list only — the search runs on the address. |
Notes notes | no | text | Internal remarks on the handling, such as the proof of identity or the reason for a rejection. |
Not enterable but visible in the list: status (status, open → processing → done, or rejected) and deadline (dueAt) — the deadline is set automatically to 30 days on creation. In truth it runs from the receipt of the request, not from its creation in the system; recording the case late leaves correspondingly less time than the date suggests.
The four row actions take no input — with one exception:
| Field | Required | Values / format | What it does |
|---|---|---|---|
Correction values corrections | yes | first name, last name, company name, email, phone | The values of the rectification dialog (Art. 16). They are applied to all master records of the person — customer, contact, employee, portal account — and to the plugin-owned copies of name and phone number. Empty fields stay unchanged; at least one must be filled. The operation is recorded with old and new value in the audit log. |
Export disclosure assembles the disclosure JSON and files it in the document store (exportPath), erase data carries out erasure or anonymisation, reject closes the case as rejected. Erasure and rejection are final; carrying on means creating a new request.
Retention policy
| Field | Required | Values / format | What it does |
|---|---|---|---|
Data type entityType | yes | key from the data type catalogue | What the rule acts on — customers, contacts, employees, portal users, leads, form submissions, audit log, disclosure dossiers, plus the types contributed by plugins. One policy per data type only. |
Retention period in days retentionDays | yes | whole number, 0 or more | After how many days of inactivity the action takes effect; 0 means immediately. Careful in both directions: too short breaches commercial and tax retention duties, too long breaches data minimisation. |
Action action | yes | anonymize · delete · seal (restriction of processing — customers and contacts only) | What happens at the end. Anonymise keeps the figures for reporting and removes only the personal reference — usually the right choice, because it satisfies both duties. |
Description description | no | text | What justifies the period. The place for the reference to a law or a contract. |
Active active | no | yes/no (defaults to yes) | Whether the rule runs. Off means the period is not applied while the rule is kept. |
Every run leaves evidence — the time is shown as last run (lastRunAt) on the rule. Without that evidence a fulfilled erasure duty could not be demonstrated.
Settings & permissions
- No route permission of its own. The page is reachable; the individual operations are checked by
the server.
- Retention and the recycle bin are two different things. The recycle bin
is a 30-day grace period against mistakes; retention is the planned removal after a substantive period expires.
- Modules bring their own retention rules. Whatever data a module holds, it registers itself.
- Every step appears in the audit log — with actor and timestamp.
FAQ & troubleshooting
An erasure was not carried out completely. Check whether modules are disabled. A disabled module does not register its data — erasure does not reach it.
We are asked to erase data we are required to keep. Statutory retention obligations take precedence over an erasure request. Record that reasoning on the case — that is exactly what it is for.
The access response contains less than the customer expects. What is produced is what is stored about the data subject. Free-text notes inside other people's records are not found by any automatism.
Is the recycle bin enough for an erasure request? No. It is a grace period against mistakes, not an erasure procedure.