Any employee can flag a misclassified app. Only a manager can override one. Here's the actual split
A productivity classifier that calls a support ticketing tool "non-productive" because it doesn't recognize it is a fast way to make an entire team distrust their monitoring software. Custelis splits who can flag a problem from who can fix it - and never lets a fix apply invisibly.
Automatic classification - is this app or site productive, neutral, non-productive, or restricted - is never going to be perfect out of the box. A niche client-management tool, an internal wiki, a research site relevant to one specific role: all of these can get misclassified. What matters is what happens next, and who gets to decide.
Two different powers, two different bars
Flag - anyone
Any employee or manager can flag an app or site as misclassified, with a reason. No permission gate - if a support ticketing tool is showing up as "non-productive," the person actually using it every day can say so directly, immediately.
Override - managers/admins only
Applying an actual classification change requires the policy-management permission. It's always scoped - organization, branch, department, role, or a single employee - never a blanket global change from one report.
Why overrides are scoped, not global
A classification override applies to a specific scope you choose - not automatically everyone, everywhere. A tool that's genuinely productive for the Audit department might be a genuine distraction for Sales. Applying "reclassify this as productive" globally because one department flagged it would just recreate the original problem for someone else. Every override is recorded as a correction with a status - applied, in this case - and who applied it.
The exception path is separate, and always audited
A related but distinct capability: rule exceptions - suppressing a specific risk signal, DLP rule, or alert for a scope, with an expiry if you want one. These require a mandatory reason (the API rejects a request without one) and are never a silent whitelist - every exception creation and revocation is written to the audit log. The distinction matters: overriding a productivity classification changes how time gets categorized; suppressing a rule exception changes what triggers an alert. Different risk, same principle - nothing happens invisibly.
What this is built against: a monitoring product where flagging a problem requires manager permission trains employees to stay quiet about bad data instead of correcting it - and a product where anyone can silently reclassify anything makes the whole productivity picture untrustworthy. Splitting flag from override, and logging every override, is meant to avoid both.
Related reading
See the flag-and-override flow live
No credit card to start. Intrusive features stay off until your own DPIA is recorded.
Try for free