Redacting sensitive information with triggers

Plan requirement

Subscription Any plan
Access Admin

Redaction driven by a rule rather than by somebody noticing. Powerful, and it needs testing before it runs.

Set it up

  1. Decide exactly what pattern should be removed.
  2. Build the rule in a sandbox.
  3. Test it against real examples and near misses.
  4. Deploy it.
  5. Check the first tickets it acts on.

Only for reliable patterns

Something with a fixed shape: a national identifier, an account number in a known format, an internal reference. Anything fuzzy will either miss the real cases or remove the wrong text.

Redaction is permanent, so test hard

An over-broad rule removes content from every ticket that matches, immediately, with no recovery. That is a different class of mistake from a trigger that sets the wrong field.

This is the case for a sandbox if ever there was one.

Test the near misses

An order number that looks like the pattern. A date formatted the same way. A reference with one digit fewer. Those are what a rule gets wrong, and they are invisible until you look for them.

Watch the first day

Look at real tickets it acted on. A rule that seemed precise in testing behaves differently against the variety of real messages.

Tell agents

Content disappearing without explanation looks like a fault, and they will raise it as one. One message explaining what is removed and why prevents that.

Keep the list short

Each rule is something that can silently destroy content. Two or three well-tested ones are worth far more than a dozen written in an afternoon.

See also

Was this article helpful?

0

Still stuck?

Our support team will take a look with you.

Comments

0 comments

Article is closed for comments.