Populating Form Dropdowns with Microsoft 365 Licenses and Groups

When a client submits a new-employee onboarding form, your techs need to know which Microsoft 365 license to assign and which groups to add the user to. Today that usually means a free-text box, a guess, or a back-and-forth email.

This guide shows how to make those questions dropdowns that list the actual licenses and groups in that client's tenant, kept current automatically. One master onboarding form, tenant-specific choices in every company.

This is not a built-in feature. It combines three things CloudRadial already supports: tokens, comma-separated dropdown options, and the API. A small script (attached to this article) connects them to Microsoft Graph.

• PowerShell Script is Here!

How it works

1. Dropdown questions in a catalog item accept a comma-separated list of options. Test A, Test B, Test C becomes three choices.
2. That options field can be a token, for example @M365Licenses. Tokens resolve company-first, then partner-level, so the same form shows different options in each company.
3. The CloudRadial API has a POST /v2/token endpoint that creates or updates a token's value.
4. The attached PowerShell script reads licenses and groups from a Microsoft 365 tenant through Microsoft Graph, formats them as a comma-separated list, and writes them to the token. Schedule it and the dropdowns stay current.

Prerequisites

• Partner admin access to CloudRadial
• Global admin (or Application Administrator) access to the Microsoft 365 tenant you are reading from
• A Windows machine with PowerShell 5.1 or later to run the script (no modules required)
• The script file: Sync-M365ToCloudRadialTokens.ps1 (attached)

Plan on 30 to 45 minutes for first-time setup.

Step 1 - Create the tokens in CloudRadial

For a single-tenant test, create partner-level tokens:

1. Go to Partner > Settings > Tokens.
2. Add a token named M365Licenses, type String, with a placeholder value such as License A, License B.
3. Add a second token named M365Groups, type String, with a placeholder value.

For a real client, create the same two tokens at the company level instead (open the company under Partner > Clients, then Tokens). Company tokens override partner tokens, so each client gets its own list while the form stays shared.

Token names are case-sensitive. The script writes to whatever name you configure, so the name in CloudRadial and the name in the script must match exactly.

Step 2 - Use the tokens in a form

1. Open the onboarding catalog item (or any problem report or service request).
2. Add or edit a Dropdown question, for example "Which license should this user receive?"
3. In the options field, enter @M365Licenses and nothing else.
4. Add a second dropdown for groups with options @M365Groups.
5. Save, then open the form as a client user. You should see the placeholder values you entered in Step 1 as separate choices.

If you see the literal text @M365Licenses instead of choices, check the token name and capitalization.

Step 3 - Create a CloudRadial API key

1. Go to Partner > Settings > Integrations > API.
2. Click + Add API Key and name it, for example M365 Token Sync.
3. Copy the Public Key and Private Key. The private key is shown once.

Treat this key like an admin password. API keys currently have full read and write access to your portal's API. Store it somewhere secure and never paste it into tickets, chat, or email.

Step 4 - Create an app registration in Microsoft 365

The script needs its own identity to read from the tenant. CloudRadial's existing Microsoft 365 connection cannot be reused for this.

1. Sign in to the Microsoft Entra admin center as a global admin.
2. Go to Identity > Applications > App registrations > New registration.
3. Name it CloudRadial Token Sync. Under Supported account types, keep the default Single tenant only - [your tenant name] 
   • Note that older portals label this "Accounts in this organizational directory only". 
   • Leave Redirect URI empty. 
   • Click Register.
4. On the Overview page, copy the Application (client) ID and Directory (tenant) ID from the Essentials section.
5. Still on Overview, click Add a certificate or secret next to Client credentials (or expand Manage in the left menu and choose Certificates & secrets). 
   1. On the Client secrets tab, click New client secret. 
   2. In the panel, enter a Description such as Token Sync and set Expires to 730 days (24 months), then click Add. 
   3. The new row in the table has two columns that both look like credentials: Value and Secret ID. The script needs the Value column. Despite the name, the Secret ID is not the secret; it is just a label for it and will not authenticate anything. The Value is a long random string (it often starts with letters like GG_ or abc8Q~); the Secret ID is a GUID with dashes like every other ID in Entra. Click the copy icon next to the Value and paste it somewhere safe right away. It is shown once. If you navigate away before copying it, delete the secret and create another. 
      • If the script later fails with AADSTS7000215, this is what went wrong.
6. In the left-hand menu of the app, click Manage to expand it (it is collapsed by default), then choose API permissions. Do not use the Azure search bar at the top of the page; it searches all of Azure and will not find this. Click Add a permission, then select Microsoft Graph.
7. You are asked "What type of permissions does your application require?" with two boxes. Choose Application permissions (the second box, described as "runs as a background service or daemon without a signed-in user"). Do not choose Delegated permissions; the script runs on its own with nobody signed in, and Delegated will fail.
8. A searchable list of permissions appears. Type Organization in the search box, expand the Organization group, and check Organization.Read.All. Clear the search, type Group, expand the Group group, and check Group.Read.All. Click Add permissions at the bottom of the panel.
9. Above the permissions table, click Grant admin consent for [tenant] and confirm. Both permissions should show a green check in the Status column.

The two most common mistakes are choosing Delegated instead of Application permissions, and skipping the Grant admin consent button. Either one produces an authorization error when the script runs.

Step 5 - Configure and test the script

1. Save Sync-M365ToCloudRadialTokens.ps1 to a folder on the machine that will run it.
2. Open it in Notepad or PowerShell ISE and fill in the SETTINGS block at the top. Only change the text inside the quotes on the right side of each =. Do not rename the $Variable on the left.
   • $TenantId: the Directory (tenant) ID from the app's Overview page
   • $ClientId: the Application (client) ID from the app's Overview page
   • $ClientSecretValue: the client secret Value you copied in Step 4 (not the Secret ID)
   • $CRPublicKey, $CRPrivateKey: paste the values from Step 3
   • $CRCompanyId: leave 0 for partner-level tokens. For a client company, use that company's ID (see Step 7).
   • $LicenseTokenName and $GroupTokenName: already set to M365Licenses and M365Groups. Leave them unless you named your tokens something else. No @ sign; the @ is only used when referencing the token inside a form.
3. Open PowerShell and change to that folder. On Windows, right-click Start and choose Terminal or Windows PowerShell, then cd to the folder (for example cd "C:\Users\you\Downloads"). On macOS or Linux, install PowerShell 7 first (brew install --cask powershell, or the .pkg from the PowerShell GitHub releases page), then open Terminal, type pwsh, and cd to the folder. Run a dry run:

   .\Sync-M365ToCloudRadialTokens.ps1 -DryRun

(On macOS or Linux use ./ instead of .\.)

This reads from Microsoft 365 and prints both lists without writing anything to CloudRadial. Confirm the licenses and groups look right.

4. Run it for real:

   .\Sync-M365ToCloudRadialTokens.ps1

5. Open the form as a client user. The dropdowns now show the tenant's licenses and groups.

If PowerShell refuses to run the script, run this once and try again:

Set-ExecutionPolicy -Scope CurrentUser RemoteSigned

Options in the SETTINGS block

• $IncludeSeatCounts: show "Microsoft 365 E3 (12 of 25 available)" instead of just the name. Useful for techs, but the count is only as fresh as the last run.
• $SkipZeroSeatSkus: hide SKUs with no purchased seats, such as expired trials.
• $GroupNameFilter: a wildcard such as SG-* to include only groups that follow your naming convention.
• $IncludeSecurityGroups and $IncludeM365Groups: include or exclude either type. Distribution lists are never included.

Step 6 - Schedule it

Run the script on a schedule so the lists stay current.

1. Open Task Scheduler on the machine and click Create Task.
2. General tab: name it, select Run whether user is logged on or not.
3. Triggers tab: New, Daily, pick an overnight time.
4. Actions tab: New, Action: Start a program.
   • Program: powershell.exe
   • Arguments: -ExecutionPolicy Bypass -File "C:\Path\To\Sync-M365ToCloudRadialTokens.ps1"
5. Save. Right-click the task and choose Run to confirm it works.

Alternatives such as Azure Automation or your RMM's script scheduler work the same way.

Step 7 - Scaling to multiple clients

The script is written for one tenant writing to one company. To cover multiple clients:

1. For each client, create the two tokens at the company level (Step 1) and find the company's ID. The easiest way is Swagger at api.us.cloudradial.com/swagger: authorize with your API key and run GET /v2/company. Each result has a companyId and a name. Note that your own MSP company appears in this list with its own ID (often 1). That is not the same as 0, which means partner-level. Use 0 for global tokens and the client's companyId for company tokens.
2. For each client tenant, either create a separate app registration (Step 4) in that tenant, or convert the app to multi-tenant and grant consent in each client tenant. Per-tenant registrations are simpler to understand; a multi-tenant app is less to maintain at scale.
3. Save one copy of the script per client with that client's tenant credentials and $CRCompanyId, and schedule each one. Or, if you are comfortable with PowerShell, wrap the script in a loop over a list of clients.

Limitations and things to know

• Commas are replaced. Because commas separate options, the script replaces any comma inside a group or license name with -. A group named Sales, EMEA appears as Sales - EMEA.
• Values are a snapshot. Seat counts and group lists are only as current as the last run.
• Client secrets expire. Set a reminder before the 24-month expiry. When the secret expires the script fails and the dropdowns silently stop updating.
• API keys are all-or-nothing. The key the script uses can read and write everything in your portal's API. Restrict access to the machine and folder that hold the script.
• Dropdowns store the label, not an ID. The submitted ticket contains the friendly name your tech sees, which is exactly what they need to act on.
• This is a partner-built integration. CloudRadial supports the tokens, forms, and API endpoints used here. The script and the Microsoft 365 app registration are yours to maintain.

Troubleshooting

Same pattern, other lists

Nothing here is specific to Microsoft 365. Any system you can read from a script can feed a dropdown: departments or office locations from an HR system, hardware models from your distributor, products or agreements from your PSA. Create a token, point a dropdown at it, and write to POST /v2/token.