You're locked out. You file a ticket. You wait.

An IT admin opens your profile. Clears the block. Generates a new password. Ticks the box that forces you to change it at the next sign-in — if they remember to. If your role changed too, that's a second ticket, in a different part of the portal, on its own clock.

None of that is hard. Doing five or six of those steps, in sequence, one screen at a time, for every single request, is what makes you wait.

IT admins are smart. They're also stuck doing the same clicks over and over.

The tasks that turn into tickets

Every one of these is its own detour in Microsoft Entra ID, even though the person asking thinks of it as one request:

• Account lockout / reinstatement: an employee is disabled, on purpose or by accident, and can't do anything until someone opens their profile and switches it back on.

• Password reset with a forced change: the reset and the "change it at next login" checkbox are two separate actions in two separate places, and it's easy to ship one without the other.

• Role or privilege assignment: a role change that rides along with almost every lockout or team move lives in a completely different part of the admin center.

• Confirming it actually worked: someone has to go back and check the account shows enabled, the flag stuck, and the role landed. Assuming anyone does.

Each one is small on its own. Stacked on the same ticket, they're why "unlock my account" takes as long as it does.

Say it once: unlock, reset, force a change

This is what a recent Sia walkthrough set out to prove.

The account belonged to Vikas Mishra, disabled in an earlier session. The operator gave Sia one instruction, typed into Sia CLI, its command-line surface:

unlock the user Vikas Mishra and reset his Entra ID password, force change the password after login

Sia didn't just run it. It looked up the account first and read back where things stood — disabled, force-change flag not set — before touching anything. Then it applied the unlock and the reset together, and reported the state it left behind: account enabled, a new temporary password issued, force-change flag confirmed true.

The operator checked that against the Entra ID portal directly, then signed in with the new credential to confirm the forced-change prompt actually appeared. Both halves of the claim — it says enabled, and it behaves like a real reset — held up under a separate check, not just Sia's own word for it.

The role change that used to be its own ticket

Before assigning anything, the operator asked Sia what roles the account already had: none. Then, in plain language:

assign the Helpdesk Administrator role to Vikas

(The specific role isn't the point, swap in whichever built-in Entra ID role a reinstated employee actually needs next.)

Sia resolved the role, applied it, and confirmed the assignment. The operator refreshed the portal and saw the same role sitting there. No second sign-in. No second search. No second page load to wait on, the role change rode inside the same request as the reset, instead of becoming its own detour.

To show this isn't a one-off, the same pattern holds for a different person and a different role:

reset the password for Priya Nair and force a change at next login → Done.

assign Priya the Licensing Administrator role → Done.

Same shape, same one line, every time.
▶ Watch it happen

Before Sia, With Sia

What it's actually talking to

Sia is working directly against Microsoft Entra ID here, the same user accounts, authentication state, and built-in role catalog an IT admin already manages by hand. Nothing above is a simulation sitting on top of the portal. It's the portal, driven by a plain-English instruction instead of a mouse.

It doesn't have to run through IT admin at all

The instruction that unlocked Vikas Mishra's account isn't special IT-admin syntax. It's a sentence. That means a helpdesk agent, or a manager reinstating someone on their own team, can send the exact same line without ever opening the Entra ID admin center.

They don't even need the command line. It's the same Sia whether you reach it from the terminal, the web, or the desktop app, the surface is just how the sentence gets in, not the thing doing the work.

Role-based scoping is what keeps that safe: a manager can act on their own team, not someone else's; a helpdesk agent gets the access their role actually needs, and nothing more. IT admin stops being the only door this has to go through.

What this actually saves

Fewer manual touches per ticket. Less chance of a skipped step — like the force-change box nobody remembered to tick. A record of what state the account was in before and after, because Sia checked and said so, instead of someone eventually noticing, if anyone does. And IT admins get their queue back.

None of that comes from doing any one step faster. It comes from not doing five of them, one screen at a time, on every single request.

That's the gap Sia closes: not one click faster, but most of the clicks gone. Business moves at the speed of a sentence. IT admin should too.

Scogo AI is the enterprise platform that turns plain-English instructions into real IT operations. Sia is its AI agent — reachable through the command line (Sia CLI), the web, and the desktop app. Available to Scogo enterprise customers.