IT setup guide for Teams and Enterprise

This guide is for the person who administers Microsoft 365 for a medical group, an MSO or a staffing agency that wants to run a MedLicense shared workspace. A workspace is a folder in your own SharePoint or OneDrive for Business, and everything in it is encrypted before it is uploaded, so Microsoft stores only ciphertext and the MedLicense company never receives any of your data. There is no MedLicense server to configure, and the steps below are all that is needed.

Pre-release note: the Microsoft 365 (Graph) storage backend is implemented to specification but has not yet been tested against a production tenant. Until it has been, we suggest piloting with one site and a few users. The synced-folder option described in section 3 uses the same encrypted layout without any Graph permissions, and it is a supported fallback.

1. What you are approving

MedLicense is a single multi-tenant application registration in Microsoft Entra ID with this client ID:

f20aa8ef-ae5e-4193-834e-89639e805944

When someone creates or joins a shared workspace, the app signs them in against https://login.microsoftonline.com/organizations and requests these delegated permissions:

No application (app-only) permissions are requested, so MedLicense can never act without a signed-in user. The app does not request mail, calendar, Teams or directory permissions.

Personal OneDrive sync for an individual's own vault uses a narrower permission (Files.ReadWrite.AppFolder) with a separate token, and it does not touch your SharePoint sites.

2. Grant admin consent in Entra

A user without admin rights will see a message that their organization needs to approve MedLicense. You can approve it for everyone in one step.

1. Sign in as a Global Administrator, Cloud Application Administrator or Application Administrator.
2. Open this URL in a browser, replacing {tenant} with your tenant ID (a GUID) or your verified domain, for example contoso.onmicrosoft.com:

   https://login.microsoftonline.com/{tenant}/adminconsent?client_id=f20aa8ef-ae5e-4193-834e-89639e805944

3. Review the permissions listed on the consent screen, which should match the table in section 1, and choose Accept.
4. In the Entra admin center, open Enterprise applications and find MedLicense. You can restrict who may use it by setting "Assignment required" to Yes under Properties and then assigning a security group under Users and groups.

If your organization uses the admin consent workflow, users can instead request approval from the sign-in screen, and a reviewer approves it from Enterprise applications under Admin consent requests.

If your conditional access policies require compliant or managed devices, MedLicense sign-in is evaluated like any other app, so the devices running it must satisfy those policies.

3. Create the workspace folder in SharePoint

We recommend a dedicated SharePoint site or a dedicated library so that the permissions are easy to review.

1. Create a team site or communication site, for example "Credentialing". A private site with its own owners and members works well.
2. Create a folder in the document library for the workspace, for example MedLicense Workspace. The app creates its own files inside this folder (workspace.json, workspace.hlv, blobs/, members/, join/, audit/, intake/ and keys/), so the folder should start empty.
3. Set the permissions on the folder or site. SharePoint permissions are the hard boundary around the data, because they decide who can open the files at all.

   Person	SharePoint permission	What they can do in MedLicense
   Owners, admins and coordinators	Edit (Members group)	Read and change records, as their MedLicense role allows.
   Viewers	Read (Visitors group)	Read only. Their devices cannot write to the folder, which is what makes the viewer role a real boundary.
   Everyone else	No access	Cannot see the folder.

4. Copy a sharing link to the folder for the person who will create the workspace. In SharePoint, select the folder, choose Copy link, choose "People with existing access" and copy the link. The workspace creator pastes this link into MedLicense when asked where to keep the workspace.
5. In MedLicense the creator chooses Set up a workspace for my organization, signs in with Microsoft 365, pastes the folder link and becomes the workspace owner. New members choose Join a workspace, sign in, paste the same link and read a six-digit code to an owner or admin, who approves them by typing it.

Two layers of access apply. SharePoint decides who can open the folder, and MedLicense roles (owner, admin, coordinator, viewer) decide what the app shows and lets each person do. Keep both in step: someone who is removed in MedLicense should also be removed from the SharePoint folder.

Synced folder alternative

If you cannot grant Graph consent, the OneDrive or SharePoint sync client can keep the folder on each person's disk. In MedLicense choose Advanced and then synced folder, and point the app at the local folder. The folder layout and encryption are identical. In this mode the tenant ID is whatever the administrator typed when creating the workspace.

4. Optional: a "Request files" link for providers

Providers who are being credentialed never receive the workspace key. A coordinator sends them a request, and they send documents back as encrypted packages. You can let providers upload those packages without giving them any access to the workspace.

1. In SharePoint, open the intake folder inside the workspace folder.
2. Choose Request files and create the link. People with the link can upload but cannot see what is already there.
3. Copy the link and paste it into MedLicense under Admin, Intake. It is then included in every request email.

Files that providers upload arrive in intake/. MedLicense opens the encrypted packages with the workspace's intake key, files the documents under "To confirm" and moves the packages to intake/processed/. Loose files that were uploaded without the app are also imported for a coordinator to assign. Because the Request files link allows anonymous or external uploads, treat anything that arrives as untrusted until it has been reviewed.

5. Deploying the apps with MDM

MedLicense is distributed as a download. There is no store listing for the desktop apps yet, so your MDM serves the file.

Mac. The Mac app runs on Apple silicon and Intel Macs with macOS 15 or later. Deliver the .app to /Applications. Jamf Pro, Intune and Kandji can deploy a .app directly by wrapping it in a package (for example with pkgbuild --component "MedLicense Signed.app" --install-location /Applications MedLicense.pkg). Please deploy the bundle unchanged, because modifying it stops macOS from opening it.

Windows, Android, iPhone and iPad. These apps are coming soon. This section will cover silent installs, managed Google Play and App Store deployment when each one is released.

6. Network endpoints

The apps contact only the following hosts, over HTTPS on port 443:

Large uploads and downloads use the temporary URLs that Graph returns, which point at Microsoft-owned domains such as *.sharepoint.com, so allow those as you would for the OneDrive sync client. If you proxy or inspect TLS, allow these hosts without inspection of the sign-in flow. Nothing is sent to any MedLicense server, because none exists, and the apps contain no analytics or crash-reporting services. The marketing website loads fonts from Google Fonts, but the apps do not.

7. Offboarding a person

When someone leaves or loses a device, do all three of these steps, because each closes a different gap.

1. Remove them in the app. An owner or admin opens Admin, Members and removes the person (or just the lost device). This stops their devices from receiving new keys.
2. Rotate the workspace key. Removal prompts a key rotation. MedLicense makes a new workspace key, wraps it to every remaining device and re-encrypts the workspace in the background, showing progress such as "340 of 1,200 files". After rotation the removed person's keys cannot open anything that is written or re-sealed from then on.
3. Remove their SharePoint access. Take the person out of the site's Members group or the folder's permissions, and revoke their sessions in Entra if the account is being closed. This step matters most, because the SharePoint permission is what stops access to the encrypted files, and it is the only protection for files that person had already downloaded.

A removed person keeps any files they had already downloaded to a device. Those files stay encrypted with the old key, so they are unreadable without that key, but a person who still holds the old key on a device could read the old copies. This is a limit of any end-to-end encrypted design and is why step 3 is required.

8. Licensing

A workspace starts as a 30-day trial for up to 10 providers, with no key needed. After that, an owner pastes a license key under Admin, License. A key is tied to your organization's name and, optionally, your Entra tenant ID, which an owner can copy from the same screen. Only providers count toward the seat total, and coordinators, viewers and admins are free. When a license ends, the workspace becomes read-only after a 30-day grace period, and everything stays viewable and exportable.

9. Quick checklist

• An administrator has opened the admin consent URL and approved the three delegated permissions.
• A SharePoint site or library folder exists, with Edit for working staff and Read for viewers.
• The creator has the folder link and can sign in with Microsoft 365.
• Optional: a Request files link exists on the intake folder and is entered under Admin, Intake.
• The Mac app is deployed to the people who need it.
• The three network hosts in section 6 are reachable.
• Your offboarding checklist includes removing the person in the app, rotating the key and removing SharePoint access.