Service governance: retention, masking, sensitive cases, channel permissions, file policy, login history and requester data requests

Service governance lives under Settings > Service governance. It is the support-specific layer on top of the platform's security: row-level isolation, roles and permissions, the audit trail, the sensitive access log and the privacy tools already exist. This screen governs what happens to cases, mess

Service governance lives under Settings > Service governance. It is the support-specific layer on top of the platform's security: row-level isolation, roles and permissions, the audit trail, the sensitive access log and the privacy tools already exist. This screen governs what happens to cases, messages, attachments and the people who handle them. Everything starts empty: with nothing configured, support works exactly as before.

Fine-grained permissions Four permissions were added to the role matrix (Settings > Roles): ticket_internal_note (see and write internal notes), ticket_message (delete a message for everyone), ticket_sensitive (open a case marked as sensitive, and mark or unmark it) and ticket_pii (see personal data in messages without masking). Every role that could read cases kept the right to see internal notes, so nobody loses anything on day one; administrators can now remove it from external partner or API roles. Tenants that do not use roles and permissions yet are not restricted by these cells.

Retention by data class A retention policy says how long a resolved case keeps its data, per class: the case itself, customer messages, internal notes, attachments and satisfaction responses. The clock starts when the case is resolved; open cases are never touched, however old. Each policy chooses between anonymize (the row stays, personal data such as e-mail, name, phone, document and card numbers is removed from it, so volume and SLA metrics survive) and delete. Attachments can only be deleted. The nightly sweep applies the policies in batches and writes every pass to a ledger that cannot be edited; the Retention tab shows the ledger and lets an administrator run the sweep now for this workspace. Classes without a policy are shown as not declared, never assumed to be kept forever by choice.

Masking in the conversation Masking rules decide what is hidden in case messages for people without the ticket_pii permission. Three kinds exist: personal data (e-mail, phone, tax ids, card numbers, using the same detectors that protect AI prompts), financial amounts anchored to a currency, and custom patterns you write (an account number format, an order code). Each rule applies to customer messages, internal notes or both, and replaces the match with a marker of your choice. The tab lists which roles see everything before you create the first rule, and previews the effect of a rule on a sample text. People with the permission always see the original text.

Sensitive cases Anyone with the ticket_sensitive permission can mark a case as sensitive from the case header in the console, with an optional reason. From then on only people with that permission can open it; everyone else receives an explicit refusal. Every opening is recorded in the sensitive access log (who, when, which case), de-duplicated per person every ten minutes so page refreshes do not inflate the trail. Marking and unmarking are recorded as security events in the audit trail, which administrators cannot switch off.

Channel permissions By default anyone who can reply can do so on every channel. In the Channels tab an administrator allows specific roles on a channel. The first row written for a channel closes it to everyone else: from then on only the listed roles can reply there. Channels without rows stay open. The server enforces this on every reply, whatever the screen.

File policy One policy per workspace: allowed extensions (if the list is not empty, only these pass), blocked extensions (always refused, even if allowed elsewhere), a per-file size limit below the platform's 25 MB, and whether the policy also applies to attachments arriving by e-mail or portal. There is no antivirus scanning; the policy is about file types and sizes.

Login history The Logins tab shows who signed in, when, from which address and device, and failed password attempts for members of this workspace. Authentication itself is handled by the identity provider; this is a mirror of what the server sees, one row per session, kept in a table that cannot be edited.

Requester data requests When a customer asks for a copy of their data or for erasure, use the Data requests tab with their e-mail. If a contact with that e-mail exists, the export and the anonymization use the same privacy tools as the contact record and cover messages, satisfaction responses, side conversations, activities, board items and attachments. If there is no contact (a requester who only ever wrote in), the cases, messages and satisfaction responses found by that e-mail are exported or anonymized directly. Anonymization is irreversible, requires a reason and is recorded as a security event.

Open this article inside the system →