Retention periods and purge

Personal data is kept only as long as its purpose requires (article 5.1.e of the GDPR). MyZapp purges each data category at the end of the period you set in the processing register, category by category, and keeps a record of each run.

The screen is in Data protection › Retention periods. Everyone in the module can read it; only data protection officers (and administrators) change it.

What the table shows

One line per data category the modules can purge: sent messages, regulated requests, logs (audit, sign-ins, sensitive access…).

Set the period: in the register

The period is set on the processing activity, field Retention period (months). If several activities in force carry the same source, the longest one wins: data is never purged before the end of its longest purpose.

Without a period in the register, the category shows No period in the register: nothing is computed, nothing is purged.

Simulation first, then apply

A category is in simulation until you switch it to apply. Every night, the task counts what would be processed, without touching anything; the log shows it. Simulate now does the same on demand, never applying.

When the figure suits you:

1. In the Policy column, choose Apply and the final action.
2. Click Save.

The purge starts at the next nightly run, in batches. A failure leaves the data intact: the category is picked up again the following night.

Hold the purge (legal hold)

A dispute, an authority audit or an investigation requires keeping the data as it is.

1. In Legal holds, choose the category, or All categories.
2. Enter the reason, without any personal data, and if possible a Review on date.
3. Click Hold the purge.

While the hold is in force, the category is no longer purged, regulated requests included. Once the review date has passed, the hold shows Review due. Release the hold, with a note, restores the purge.

Inactive accounts and tickets

• Inactive accounts: an account that has not signed in for the period set in the register (user accounts activity) is disabled: it can no longer sign in, its open sessions are ended, and an administrator can enable it again. If you choose the Anonymize action, the account is anonymized as when it is deleted. Administrators, the System account and accounts synchronized from a directory are never affected.
  • Notice: when applied, the person first receives an email announcing the disabling date. The account is only disabled (or anonymized) 30 days later, and only if they have not signed in meanwhile: signing in cancels everything. The period is set in the configuration (Users:Inactivity:NoticeDays, 0 = no notice). In simulation, no email is sent.
• Guest access to tickets: once the access link has expired or been revoked, the guest's address is deleted after the period in the register. The ticket and its messages remain.
• Ticket read markers (who read which ticket, and when): deleted after the period in the register.

Intermediate archive (restricted access)

Between the end of active use and the purge, some data moves to an intermediate archive: it stays in the database but disappears from current screens, searches and exports. Only the data protection officer (group PRIVACY_DPO) and the members of the PRIVACY_ARCHIVES group (litigation, audits) can still see it, and every read is logged in the sensitive access log.

• The period is set in the register, on the activity: "Active use (months), then archive". It must be shorter than the retention period. Empty: no intermediate archive.
• Archiving follows the same rule as the purge: simulation first, then application, and a legal hold suspends it. The purge log shows an "Archive (restricted access)" line.
• Today, closed regulated requests (with no appeal in progress) are archived this way. The requester keeps access to their own requests, and the execution of a data subject request still finds them.
• Completed or cancelled projects are archived too: they leave everyone's list and dashboards, members included; the data protection officer and the archives group open them read-only.
• Closed tickets are archived the same way: they leave the agents' list, grids, searches, exports and statistics. The requester keeps access to their own tickets; the data protection officer and the archives group can read them, and every opening is logged. Reopening a ticket brings it back into current use.
• Academy enrollments with no activity are archived too: they leave the trainer's screen and no longer trigger reminders. The learner still finds and resumes them; any activity brings them back into current use. Certifications are never archived: they are proof.
• CRM contacts and leads with no activity at all (email, call, meeting, quote, opportunity) for the current-use period are archived too: they leave lists, searches, exports and the API, even for their owner; the data protection officer and the archives group open them read-only. A contact of an organization that has an active contract or an unpaid invoice is never archived. Any new activity brings the record back into current use.

Categories set elsewhere

• Logs (audit, sign-ins, denied access, API calls, sensitive access): their period is set on the server, per log category. The table shows that setting; the purge remains the logs' own, which keeps proof of each deletion.
• Assistant conversations (one period per audience) and CRM call transcripts: their period is set in the assistant and CRM settings. The table shows it.
• Regulated requests: their period comes from the country model, extended by the entity in the desk settings. The table shows "Periods set by the module"; the legal hold applies to them.

Purge log

Each run writes one line per category: date, mode, cutoff date, due items, processed items, outcome (Simulated, Applied, On hold, No period, Stopped (time), Failed). The log contains no personal data and is kept two years.