Locking a Microsoft 365 license to one app per team, and onboarding the people who need it, run and verified with Sia.

You give Sales a license so they can use Teams. Seat granted, ticket closed, done.

Nobody told you that same license also switches on Word, Excel, SharePoint, Planner, Yammer, and every other app bundled into it, whether Sales asked for it or not.

A license looks like one decision, hand someone a seat, done. It is actually sixty two of them, one per app bundled inside, and the default answer to every single one is yes. The setting that keeps it down to just the one you meant is the setting almost nobody opens. In the Microsoft 365 admin center, each of those apps rides on something called a service plan, and a license ships with every single one of them switched on unless somebody turns each off by hand.

The request that looks like one ticket and is actually six

Standing up a new department's group. Sales needed one, same as HR and Dev before it. Named right, created clean, the easy part.

Assigning the one app that group actually needs. Teams for Sales, the same shape as Forms for HR and Planner for Dev. Also easy, and already solved once you've locked an app to a group with assignment required, the enforcement step we walked through start to finish in an earlier post on department isolation.

Handing out the license itself. Without a seat, none of the above does anything, so HR, Dev, and Sales each need a Microsoft 365 Business license. This is where it slows down, because a license isn't a single toggle. It's sixty two of them, and the default is all sixty two switched on.

Turning off the sixty one apps the team was never meant to have. Click through, disable, repeat, for HR, then Dev, then Sales, double checking each time that the one app you wanted to keep is still the one left standing. Skip a few and the app-level lockdown barely matters, the license quietly hands out the rest of the suite anyway.

Working through the actual hires. A spreadsheet with names and departments, some people already in the tenant, some not, and somebody has to check each row, create the missing accounts, and get credentials to the right person.

Sorting each person into their group. Off the same spreadsheet, matched by department, by hand, one row at a time, hoping nobody lands in HR when the sheet says Dev.

None of this is hard. All of it is repetitive. And the step most likely to get skipped, closing the sixty one service plans nobody asked for, is invisible until someone in Sales opens Planner by accident and nobody can explain why.

What we asked Sia to do

Here's that same request, all of it, handed to Sia as one instruction typed into the Sia CLI, against a tenant where Dev Team and HR Team already existed with Planner and Forms assigned, but no license, and no lockdown, behind either one:

"Create a security group named Sales Team and assign the Microsoft Teams application to it. Give HR Team, Dev Team, and Sales Team a Microsoft 365 Business license each, block every application the license offers, and leave only Forms open for HR Team, Planner open for Dev Team, and Teams open for Sales Team. Then read the Mumbai New Hires file on my desktop, create whichever users don't already exist, share their credentials, and assign everyone to their security group by department."

Sia broke that into seven tasks and ran all of them. It created the Sales Team group. It found the new-hire file on the desktop without being pointed at it twice. It pulled the license's full service plan list, sixty two entries, and matched the three it actually needed against Forms, Planner, and Teams. It checked the spreadsheet against the tenant and found Vikas Mishra already there. It assigned Teams to Sales Team, then attached the Microsoft 365 Business license to all three groups with every service plan disabled except the one each group was meant to keep. It created accounts for Abhay and Vrinda, the two names on the sheet that didn't already exist, and issued their credentials. Then it read each person's department straight off the spreadsheet and dropped them into the matching group: Vikas into Dev, Abhay into Sales, Vrinda into HR.

Then it checked its own work, and so did we. A refresh of the Entra admin center showed the Sales Team group present, Teams attached to it. All three groups carried the Microsoft 365 Business license, and against each one, only the single named service plan read enabled, the rest of the sixty two showed disabled. Abhay and Vrinda existed as new accounts. Vikas was untouched, exactly as he should have been. Each of the three sat inside their own group, matching the department column on the spreadsheet, not the one next to it.

The strongest check didn't come from the portal at all. We logged in as Abhay. Teams opened, no friction, exactly what Sales Team's license was left to allow. Then we opened Forms, the app that belongs to HR, not Sales, and Microsoft's own sign-in screen turned him away, the administrator has restricted this application to specific users, and he isn't one of them. Not a setting that reads true in an admin panel somewhere. A real account, hitting the wall, from the other side of it.

The same pattern covers the requests that didn't make it into this walkthrough. Add a fourth department mid-quarter, same shape, same one line. Swap which service plan a group keeps because their tool changed, done, no seven-step ticket needed. Just the same short loop every time: instruction in, tenant changed, checked.

Watch it happen

The full sequence above, run and verified live in Entra ID and the Microsoft 365 admin center.

Before Sia, with Sia

Before Sia: assign the license, then click through all sixty two service plans by hand to switch off the ones the team was never meant to have.
With Sia: one instruction, and the license lands already narrowed to the one app each group needs.

Before Sia: open a hire spreadsheet, check each name against the directory, create accounts for whoever's missing, then track down a separate channel to get their credentials to them.
With Sia: name the file, and the missing accounts, and their credentials, come out of the same request.

Before Sia: sort each new hire into a security group by hand, matching departments to group off a spreadsheet column, one row at a time.
With Sia: it reads the department and places them, no cross checking required.

Before Sia: trust that a locked-down license is actually locked down, because nobody has time to log in as the user and check.
With Sia: log in as the user, and watch the block happen for real.

Before Sia: three separate tickets, one for the group, one for the license, one for the person. With Sia: one sentence, seven tasks, and a login test that proves it.

What Sia actually touches

Sia works directly against Microsoft Entra ID and Microsoft 365 licensing: security groups, enterprise application assignments and the service principals behind them, license SKUs and every individual service plan inside them, user account creation and credential issuance, and files sitting on the desktop it's asked to read. Forms, Planner, and Teams are what this walkthrough used. The same license-narrowing pattern holds for any service plan in any Microsoft 365 SKU assigned in the tenant.

The interaction is conversational. The execution is not a guess. Every change runs through the same governance that lets Sia act on identity and licensing in production: a mutation gate with three verdicts, allow, require approval, or block, sensitive changes queued for a human, destructive operations blocked outright, and every action written to an append-only, HMAC-signed audit log that exports with its signatures intact. When compliance asks which apps a license actually opens, the answer is a query against a signed record, not sixty two checkboxes read one at a time.

This is not only an IT admin's job anymore

None of this needs an IT admin at the keyboard for every hire. An HR manager onboarding a batch of new starters can hand Sia the same spreadsheet and get accounts, licenses, and group placement back without opening the admin center once. Ask Sia to onboard someone into a department outside your own scope, and it will not. Access control did not disappear. Sia runs inside the role-based scope you set, so the permission model moves from a human clicking with admin rights to an agent acting within a policy you defined.

It is the same Sia whether the request comes in through the command line, the web, or the desktop app. The surface is just the door.

What this actually changes

New hires land in their group with exactly the one app they need, and nothing else in the suite, on their first day, not after someone circles back to clean up the license. Departments stay separated by what the license actually allows, not by whoever remembered to click through sixty two checkboxes. A spreadsheet of new starters turns into working accounts, in the right groups, in one request instead of a queue of separate tickets. And when someone asks whether the lockdown actually works, the answer comes from watching a real login fail, not from trusting a settings page.

A license was never supposed to be a side door into the rest of the suite. Now, for HR, Dev, and Sales, it isn't one.

Availability

License-scoped access and spreadsheet-driven onboarding run on the Microsoft 365 integration that is in Sia now, across the Sia CLI, the Sia Desktop App, and the web. We deliver Sia as part of the Scogo platform to enterprise customers, so there is no public download.

If your team is still clicking through service plans one at a time, or onboarding new hires off a spreadsheet by hand, we want to put Sia in front of your tenant. Start with a pilot at scogo.ai/request-demo.

Autonomous where it is safe, governed where it matters, on the record everywhere.