Asking Sentinel-Q to change something, in your own words

You do not need to know what a sign-on policy is, or how a network zone is defined, to change how your organisation signs in. Go to Sentinel-Q → Change proposals and type what you want in a sentence: nobody outside Romania should be able to log in without MFA, or suspend the account of the colleague who left last week. Sentinel-Q reads your organisation, drafts the exact change, and shows it to you in words — before anything happens.

The one fact that changes how you use this: nothing is ever applied without you pressing Approve. Drafting a proposal reads your tenant and writes nothing. There is no setting that lets Sentinel-Q skip the approval step for a proposal, at any autonomy tier — that mechanism is separate and is covered in Autonomy tiers explained. This article is about the other path: the one where you ask for something in English and a human still has to say yes.

How to ask, and what you get back

Type your request into Your request and choose Draft the change, or pick an example underneath the box. Sentinel-Q returns a proposal card showing the sentence it understood, and a line stating how sure it is: confident it understood you correctly, understood you but made an assumption worth reading, or unsure and asking you to read carefully or reject with a note.

Open the card and you get, in order: What Sentinel-Q understood (the intent in a sentence, plus its reasoning where one is given); an optional question, when the request was ambiguous enough that Sentinel-Q would rather ask than guess; the changes, each written as a sentence — “Add the sign-in rule ‘Outside office, require MFA’: for everyone, when signing in from outside Head office, require a second factor” — with a before/after table for anything being updated rather than created — with one exception, covered below: group-membership and role changes never get one; and, for every proposal with at least one change, a blast radius section.

The blast radius is the part worth reading slowly

This is counts of real people, computed from your organisation at the moment the draft was made, not a description of the rule. A typical line reads “Affects 14 of your 22 users”, followed by whichever of these apply: how many of the affected users have no MFA enrolled yet (and will be asked to enrol on their next sign-in); whether a deny rule refuses sign-in outright, and for whom; whether an administrator is among those affected, or all administrators are; whether the request affects you, the person approving it; and whether a network zone is being created for the rule to reference.

Group membership and role changes

These two are the newest kinds of change and the ones with the widest consequences, so they get a section to themselves. Both are update-only. Sentinel-Q can move a person into or out of a group that already exists, and it can give a person a role that already exists. It cannot create a group, delete a group, or invent a role.

Each renders as a single sentence on the proposal card, and for these two kinds the sentence is the whole of what you are shown:

Add [email protected] to the group “Finance”.
Remove [email protected] from the group “Finance”.
Give [email protected] the role “analyst”. (currently “viewer”)

The trailing “(currently …)” clause appears only when the person already held a role. Two small differences from the older kinds are worth noticing rather than puzzling over: these sentences end in a full stop and the sign-in-rule sentences do not, and — the one that matters — no before/after table is ever drawn for either kind. The diff the interface renders only covers sign-on-policy fields. So for a role change that “(currently …)” clause is the only before-state you are given, and for a group change there is no before-state on the card at all. If you want to know what a group holds today, open it on Identity → Groups before you approve.

What the card says about a group change

The blast radius carries one line for this kind: Group membership changes who can reach what the group is used for: check what the group grants before approving. That is a prompt to go and look rather than a summary — the card does not list what the group is referenced by, so the checking is yours to do. A group named in a sign-in policy rule, or used for an app assignment, is one where a membership change is a real access change.

What the card says about a role change

A role change always shows this line: A role change takes effect at the person's next request; their current session is not ended. Read it as written. Approving a demotion does not sign the person out, and whatever they have open in a browser tab keeps working until it next asks the platform for something. If you are removing access because of an incident rather than a reorganisation, deal with the session as well — see User lifecycle and deprovisioning.

Refusals you may meet on these two kinds

A refusal here is not an error. Sentinel-Q returns an ordinary proposal in the Needs more from you state with the reason written on it, so both the attempt and the reason stay on the record. The ones worth recognising:

• The group you named does not exist, or the person you named does not exist. Check the spelling of the group, and give the person's email address rather than their name.
• The change would do nothing — adding somebody who is already in the group, removing somebody who is not in it, or giving somebody the role they already hold. A redundant change is refused rather than drafted, which is why an approved proposal always changes something.
• Only adding and removing are supported. Asking for the group itself to be created or deleted comes back as a refusal, not as a draft that quietly does something adjacent.
• The role you named does not exist. Sentinel-Q will not invent a role to make the sentence work.

The “What would Sentinel-Q change?” button

On the same composer screen — Sentinel-Q → Change proposals, not a posture screen — there is a button reading What would Sentinel-Q change?. It is for the moment when you know something in your posture report needs attention and you do not know how to phrase the request.

Pressing it reads your organisation's open posture findings, up to the three most recent, and asks Sentinel-Q in one request to draft a change for each one it can and to say plainly which ones it cannot change itself. If nothing is open it tells you so and drafts nothing: Nothing needs you today: there are no open findings in your posture report.

What comes back is an ordinary proposal — the same card, the same confidence line, the same blast radius, the same Approve and Reject. This is deliberately not a per-finding fix button, and there is no fixed list of finding types it supports: whether a given finding can become a change is decided exactly the way a sentence you typed yourself would be. A finding it cannot act on therefore comes back as a plain statement to that effect, rather than as a change that merely looks related to it.

Approving, rejecting and revising

Approve and apply is one action: there is no separate approve-then-apply-later step for a proposal you agree with. Pressing it opens a confirmation naming how many changes will be made now and how many of your users they affect, in a stronger tone — a danger-styled dialog — when the proposal touches an administrator or touches you. Confirm, and the changes are made immediately and recorded against your name.

If you disagree, type a reason in If you reject, tell Sentinel-Q why — a reason is required — and choose Reject. The reason is stored on the proposal and handed back to Sentinel-Q if you then choose Ask Sentinel-Q to draft again, which appears once a proposal is rejected. Revising drafts a fresh proposal from the same original request plus your reason, rather than editing the rejected one in place; the old card stays in the list as a record of what was turned down and why.

Why a proposal goes stale, and what to do about it

A proposal is drafted against a snapshot of your organisation: its sign-on policies, its network zones, every user's status, active flag and MFA enrolment, every user's current role, and the exact membership of every group. If any of that changes between the draft and your approval — somebody edits the same policy, a user is suspended, an administrator's MFA status changes, somebody is given a different role, anybody is added to or removed from any group — the proposal is marked Out of date, Approve is disabled, and the panel explains: Something in your organisation changed since this was drafted, so it can no longer be approved. Ask Sentinel-Q to draft again.

Now that roles and group memberships are part of that snapshot, the check is noticeably easier to trip than it used to be. A role change or a group-membership change anywhere in your organisation can mark an outstanding proposal out of date, including one that has nothing to do with the proposal in front of you. Somebody joining a distribution group at the other end of the company is enough. That is the cost of the guarantee in the next paragraph, and the remedy is the same one action.

This is not a bug to work around. It exists so you can never approve a change against a picture of your organisation that is no longer true — the alternative is a rule landing on top of a user who has since left, or overwriting a policy somebody else just edited without either of you knowing. If you see it, the fix is always the same: ask Sentinel-Q to draft the same thing again, and it will read the current state.

Who can ask, and who can decide

Typing a request and reading a draft needs the permission that lets you talk to Sentinel-Q at all. Approving, applying or rejecting needs a separate, higher permission — and even with it, the platform checks that you personally hold the specific permission each change would need if you made it by hand: approving a sign-in rule change needs the permission to write organisation settings, approving a network zone needs the network-zones permission, approving an account-status change needs the users permission, approving a group-membership change needs the permission that gates group writes — the same one the Identity → Groups screen itself uses — and approving a role change needs the permission that gates writing a member's role, which is the same one an administrator needs to edit somebody's role by hand in the console. A proposal drafted by a colleague and waiting on you shows Asked by another member of your organisation, so you know it was not your own request.

When it says it cannot help

Four refusals are worth recognising by their shape rather than reading as a generic error. 403 means you can draft but not decide, or the reverse — check which action you were attempting. 409 is the stale-proposal case above. 429 means Sentinel-Q has reached its usage limit for now; see AI budgets and rate limits. 502 means the model itself did not answer — retry the draft. None of these four mean the request was misunderstood; a misunderstood request comes back as a low-confidence draft or a clarifying question instead, not an error.

What to do next

1. Try one of the three example requests on the composer to see a real proposal before you write your own.
2. Read What Sentinel-Q is allowed to do for the boundary between this feature and unattended automation.
3. If your request is about who can sign in from where, read Sign-on policies and the decision trace so you can recognise the rule Sentinel-Q drafts.
4. If a draft names a network zone you have not created, read Network zones before you approve it.
5. Before approving your first role change, read Who can see and do what so you know what the role you are handing over actually holds.
6. Before approving your first group change, look the group up on Identity → Groups — the card does not tell you what the group is used for. Groups and automatic membership explains what a group does and does not grant.