An agent inbox holds customer conversations, which means it holds personal data, which means somebody will eventually ask which country it lives in and how long it stays.
Residency is per tenant, not per product
Two customers can have incompatible requirements: one wants everything in the EU, another has no constraint but a strict retention limit. A single global bucket satisfies neither. The storage location has to be a property of the tenant, decided at creation and recorded somewhere an auditor can read.
Retention needs a clock per mailbox
Deleting on a schedule means knowing what the schedule is for each mailbox, not for the product. Store the retention policy with the mailbox and run deletion from that, so changing the global default does not silently rewrite history for existing customers.
Backups are part of the answer
A deletion that leaves the data in a nightly backup has not deleted anything. Either expire backups on the same schedule or document the gap plainly, because the first audit question after 'do you delete it' is 'including backups'.
The detail that avoids a scramble
Attachments are the part everyone forgets. If the body is in the region and the attachments are in a shared global bucket, residency is not satisfied and the answer to the questionnaire is wrong.
Volanea attaches storage and retention settings to each inbox, so residency follows the tenant instead of the deployment.
Top comments (0)