How to get help, and what we need from you

There are four ways to reach us and they are not interchangeable. Picking the right one is the difference between an answer today and an answer after two rounds of clarifying questions. This article says which is which, and then sets out the handful of details that make a ticket answerable the first time somebody reads it.

Check the status page first

If something that worked yesterday has stopped working for everyone in your firm at once, look at status.qorionix.com (opens in a new tab) before writing anything. A known incident is already being worked on, and the page will tell you what is affected and what is not. This takes fifteen seconds and it is the most common reason a ticket turns out to have been unnecessary.

If the status page is clear and the problem affects everyone, that is genuinely useful information and worth saying explicitly in your ticket.

Which route to use

The five things that make a ticket answerable

We are a small team and we would rather spend the time fixing your problem than establishing what it was. Five details do almost all of that work.

1. 1

   What you were trying to achieve, in business terms

   One sentence. "I am trying to stop our old scanner emailing scans through a staff mailbox" tells us far more than "SMTP error". We can often suggest a better route to the same outcome, and we cannot do that if we only know which button failed.

2. 2

   The exact identifier for the thing you are looking at

   A finding carries a check identifier of the form ZQ-M365-PRIV-003. An alert, an incident and an audit row each carry an identifier too. Copy it. It removes every ambiguity about which of eleven similar-looking findings you mean. If what you are reporting is the console itself hitting a fault rather than a feature behaving oddly, there is a further identifier worth having — see the note below.

3. 3

   The exact error text, copied not paraphrased

   Paste the string. Our messages are deliberately specific, and the difference between two of them that read similarly is often the whole diagnosis.

4. 4

   When it happened, with the time zone

   A timestamp lets us go straight to the audit trail. "This morning" costs us an hour of searching. If it happens repeatedly, tell us the last two times.

5. 5

   Who it affects, and whether it is everyone

   One person, one role, or the whole firm. If it is one person, say which role they hold — a surprising number of "it is broken" reports are a permission working exactly as designed. See Who can see and do what.

What I was trying to do:
  Approve the change attached to a critical finding about admin accounts.

Identifier:
  ZQ-M365-PRIV-002

Exact error:
  "You do not have permission to perform this action."

When:
  2026-08-28, about 09:40 CEST, and again at 14:15 CEST.

Who:
  Me only. I hold the member role. Our other partner (admin) can do it.

That ticket answers itself, which is the point: writing it out in that shape resolves a fair proportion of problems before you press send.

What not to send us

• Do not attach a full log export unless we ask for one. Raw logs from your tenant contain personal data about your staff and your clients, and sending them to us creates a processing question neither of us needs. A screenshot of the relevant rows, or the identifier, is almost always enough.
• Do not send client files as examples. If a document is involved, describe it. We do not need the actual invoice.
• Do not open five tickets for one problem. One ticket with five affected people in it keeps the history in one place. Five tickets get five different first replies.
• Do not reply to a resolved ticket with a new problem. It reopens a closed thread and buries the new issue underneath the old one.

What we can and cannot do for you

Being clear about this now is more useful than discovering it at the wrong moment.

We can explain any finding, decision or alert

Including why a check was skipped rather than passed, and what evidence a Sentinel-Q decision was actually grounded in. If a decision does not make sense to you, that is a legitimate ticket and we would rather have it than not.

We can undo changes we made

Every privileged action is recorded in a hash-chained audit row with an actor — a person, the AI or the system — and for changes it carries a recorded undo handle. If something we did broke something in your office, say what broke and we can reverse it. See Undo a change.

We can tell you when something needs a specialist

There are situations that need a human incident responder in the room. When you are in one, our job is to say so plainly and hand over a usable summary rather than pretend the software has it covered.

We are not a staffed operations centre watching your tenant

We sell software, not a rota of analysts. Nobody here is looking at your alert queue overnight waiting to ring you. If continuous human monitoring is what you need, you need a managed provider in addition to this platform, and we will say so rather than sell around it.

We cannot make your business decisions

Whether to break a fifteen-year-old scanner in order to block a legacy sign-in protocol is your call. We will tell you exactly what will break, and then it is a decision about your business.

If you think you are being attacked right now

Do these in order, and do not wait for us before starting.

1. Open the affected person's record in the Users list, go to the Sessions tab and press [Revoke All]. This signs the attacker out of anything already open, which a password change on its own does not do.
2. Press [Reset Password], and [Reset MFA] if you believe the second factor is also compromised.
3. Email [email protected] with [INCIDENT] in the subject, the word urgent in the first line, the account involved, and the timestamps you have.
4. Do not delete anything, do not wipe the machine, and do not clear the mailbox rules. Whatever the attacker set up is the evidence that tells you what they were after.

Telling us something is wrong with the product

A detection that fires constantly on something normal in your business is a defect in our rule, not a fact of life you have to live with, and switching it off yourself is the worst available outcome: a rule you disabled in week two is worth nothing in month six and nobody will remember why it is off. Send us the noisy detection with two or three examples and we will look at the rule.

The same applies to a check that keeps reporting as unable to run, a finding whose plain-language explanation does not read as plain language, and a Sentinel-Q decision you disagree with. Disagreement is a first-class action in the product rather than a complaint, and it is recorded. See Agree, disagree or escalate.