Article last updated on the 17th of February, 2026.
This article is intended for customers with an existing WorkPoint 365 installation configured with Full Control permissions over all SharePoint sites in their Microsoft 365 tenant, who wish to transition to the more restrictive Sites.Selected permission model.
Background
Installing WorkPoint
During the installation of WorkPoint 365, administrators must grant consent for WorkPoint Services to access SharePoint within the Microsoft 365 tenant. These permissions allow WorkPoint to manage and interact with WorkPoint-managed sites hosted in the customer’s SharePoint Online environment.
WorkPoint supports two distinct permission models for accessing SharePoint Online.
As part of the installation process, administrators are prompted to select which permission model WorkPoint should use for the tenant, as shown in the installer screenshot below.
Option 1: Full Control
If customers would like WorkPoint to create SharePoint sites as needed for WorkPoint content - the administrator can consent to the WorkPoint Enterprise Application registration having Application level Full Control to SharePoint Online.
This allows WorkPoint Services to access, create and manipulate ALL SharePoint sites in the M365 Tenant.
While WorkPoint Services only ever access WorkPoint managed sites, technically this permission does also allow access to sites and content outside the WorkPoint solution.
Option 2: Limited Access
For customers who want to restrict WorkPoint Services to only WorkPoint Solutions and Entity Sites - and prevent access to all other sites in the tenant - WorkPoint supports a restricted access model. In this model, WorkPoint uses the SharePoint and Microsoft Graph Sites.Selected permission. This treats the WorkPoint Services Entra application like a regular user, meaning it must be explicitly granted Full Control on each SharePoint site it is intended to manage.
Comparing Permission Models
Once the administrator selects a permission model and grants consent, the WorkPoint Installer registers an Enterprise Application in the customer’s Microsoft 365 tenant.
To illustrate the differences between the two permission models, the screenshots below from the Microsoft Entra admin center compare WorkPoint installations configured with Full Control permissions versus those using the Limited (Sites.Selected) permission model.
Note: In the"Full Control Mode", the WorkPoint API has "Application" Sites.FullControl.All in both SharePoint and Graph scopes (shown as 1). With this model, WorkPoint Services can access and manipulate any existing site or create new sites in the SharePoint tenant with or without a signed in user.
By comparison, with the "Limited" permissions model, the WorkPoint Application only has "Sites.Selected". This means that WorkPoint Application is treated much like a SharePoint user and has to be granted access to specific SharePoint sites. WorkPoint can no longer create sites of its own and when they are created by an external process (described below), WorkPoint must be explicitly granted full control in order to use them for WorkPoint Entities.
Downgrading Permissions
In the sections that follow, we guide you through each step of the process, including how to validate and test the transition. We also outline options for automating the workflow and implementing a scalable site provisioning strategy.
At a high level, the process for downgrading permissions from the Full Control model involves the following steps.
-
Step 1. Re-Run the WorkPoint Installer and select the "Limited Access" permissions model.
- Use the WorkPoint installer to grant the additional Sites.Selected permissions for the WorkPoint API.
-
Step 2. Grant the WorkPoint application Full Control over all existing WorkPoint Solution and Entity Sites.
- Use the WorkPoint API to grant the WorkPoint API application Full Control over only WorkPoint sites (and not unrelated sites).
-
Step 3. Implement a Site Provisioning Automation
- Since, after the permissions downgrade, WorkPoint will no longer have access to create sites on demand, you must implement your own process to...
- a) Create new sites for WorkPoint Entities.
- b) Grant WorkPoint access to each new site.
- c) Registers the site with WorkPoint for use in new Entity creation events.
- Since, after the permissions downgrade, WorkPoint will no longer have access to create sites on demand, you must implement your own process to...
-
Step 4. Revoke the Full Control permission from the WorkPoint API
- Use the Microsoft Entra Admin portal to remove the Full Control permission from the tenant.
- Use the Microsoft Entra Admin portal to remove the Full Control permission from the tenant.
-
Step 5. Refresh the Entra App Consent
- Access the WorkPoint Admin Portal and use the "Force Refresh Consent" function on the App Management page to make WorkPoint update the cached permissions model.
- Going forward, all WorkPoint Services will use the Limited Access permissions to access and manipulate WorkPoint Entity sites.
Since the downgrade process is a multi-step procedure. Before continuing, we suggest that you verify the current permissions settings on your M365 Tenant to confirm that the existing installation is running in Full Control mode.
For existing solutions, you can verify which permission model your WorkPoint Solution is running in by viewing the permissions of the Enterprise Application in as follows:
1. Access the Microsoft Azure Entra Admin Portal (https://entra.microsoft.com).
2. Expand Applications and select "Enterprise applications"
3. From the options blade, select "All applications"
4. In the search box, enter "WorkPoint365 WebApi"
5. Select the appropriate Application Registration for your solution.
- There are distinct application registrations for solutions in Production vs. Test rings.
- Production solutions will only have "WorkPoint365.WebAPI". (this tenant has both test and production solutions).
6. In the Options blade, select "Permissions".
7. With the "Admin consent" tab selected (default), enter "Site" in the search terms and observe the existing permissions.
8. If the API permissions includes "Sites.FullControl.All" with type "Application" (as shown as 8) for both Microsoft Graph and Office 365 SharePoint Online scopes, then your solution is running in Full Control mode.
Proceed to the section below and follow the steps to regress permissions to the Limited Access mode.
Note that the other permissions in your Enterprise Application may differ slightly from the screenshots above based on which WorkPoint Features and Services are enabled in your tenant. Here, we focus on the core SharePoint and MS Graph Sites permissions only to highlight the difference between the Full Control and Limited Access models.
If your WorkPoint365 WebAPI Enterprise Application does not have Sites.FullControl.All claim in either SharePoint or MS Graph scopes, there is no further action required - your solution is already running in Limited Access Mode.
Downgrading WorkPoint 365 API Permissions to Limited Access Mode.
Prerequisites
To complete this process you will need to have a user account in the tenant that has (at a minimum)
- Entra Roles: SharePoint Administrator and Privileged Role Administrator.
- SharePoint permissions: Site Collection Administrator in the SharePoint Application Catalog, the WorkPoint Solution Site and every WorkPoint Entity Site in SharePoint on the Tenant.
Step 1: Run the WorkPoint Installer
Launch the WorkPoint Installation wizard at https://install.workpoint365.com.
On the Welcome splash, click "Run WorkPoint Installation Wizard".
On the "Welcome to WorkPoint" options page, in the "Applications" section, click on the menu next to "Install WorkPoint 365 App" and select "Reinstall" as shown as steps 1 and 2 in the image below.
On the "API Permission" screen, select "Continue" to progress the installation.
On the Job Permissions screen, select the option "No I'm not - I'm going to do it the manual way" as shown with step 4 in the image below.
You will then be prompted to consent to the restricted permissions requested by WorkPoint in this Limited Permission model. Acknowledge and consent by clicking "Accept".
The WorkPoint installer will then use this consent to modify the SharePoint and Graph permissions on the Enterprise Application the Limited permissions scope...
After the Entra Application Registration permissions have been granted, the installer will re-install the Application in the SharePoint Application Catalog in the tenant to complete the installation.
Step 2: Grant WorkPoint Permission on existing Sites
At this stage, the Entra Enterprise Application Registration will have both the previous Full Control claims (from the previous install) and the new Limited Permissions granted through the installation process.
Before we revoke the Full Control permissions, we need to ensure that the WorkPoint Application has been granted Full Control permission to the WorkPoint Solution site and all Entity Sites in the solution.
To grant the WorkPoint API Application Full Control over specific sites, we can use the WorkPoint API /api/Consent/WorkPoint/Permissions/SelectedSite endpoint.
The API parameters are shown from the screenshot of the WorkPoint Swagger UI below.
Here, we can see that the parameter structure is relatively simple - requiring only a WorkPoint365Url solution URL (1) and the specific site to grant access to (2). The response is a simple boolean (true/false) indicating success or failure.
As with all WorkPoint API, it is possible to invoke the API directly from the Swagger UI as shown in the UI screenshot above.
This is done by first authorizing the UI using the current User's credentials (labeled 1 in the image below), then supplying the required WorkPoint365Url and siteUrl as parameters.
Note: This WorkPoint API uses the "Delegated" permission of the current user to grant the WorkPoint Application "Sites.Selected" Full Control of a specific site.
To use this API, the current user must have Full Control over each site in the WorkPoint solution.
The response is a simple boolean true/false value indicating the success of the consent operation. If required, the section below (optional) shows you how you can verify that the application has been granted Full Control over the specific site.
Although a successful boolean (true) response from the WorkPoint API confirms that permissions have been granted, administrators may wish to independently verify that the application has the expected access. This can be done using the Microsoft Graph permissions APIs. Note that SharePoint does not currently provide a user interface for inspecting which applications have permissions on a specific site.
https://graph.microsoft.com/v1.0/sites/mytenant.sharepoint.com:/sites/workpoint_solution:/permissions
An example of this API request/response structure is shown below from the Microsoft Graph Explorer UI.
Note that the tenant and site components of the API endpoint (shown as 1 and 2) require modification for your solution.
In the response section, note that the application identity (shown as 3) matches the Application ID of the Enterprise Application registration in your tenant's Entra Admin Center. (Example from WorkPoint TEST API shown).
If the permissions API returns the Application ID matching the WorkPoint API Enterprise Application for your platform, WorkPoint will now be able to use the Sites.Selected permission to access and manipulate that specific site.
Granting access to ALL WorkPoint Sites
It is important to note that the above API request grants access to one specific site only. If the solution is empty and new, then this is all that is required.
However, if there are multiple solutions in the tenant and/or Business modules with entity sites or existing Buffer Sites, we must iterate each solution and it's sites with requests to the /permissions/SelectedSite API before proceeding .
The sequence diagram below illustrates the layers of iteration required.
Note that every site collection associated with an Entity or a Buffer Site requires a specific request to /permissions/SelectedSite (shown as #1).
In larger solutions, typically, this requires some scripting or code to iterate the Entity sites within each Business Module plus Buffer Sites.
Note the above process applies to Business Modules using the OneSite Architecture (One Site Collection per Entity). For Business Modules using MultiSite architecture (Entity sites as subsites of a Site Collection), the Permissions Grant need only be executed at the Site Collection level.
The WorkPoint PostMan Project includes a collection folder 5. Grant WorkPoint Sites.Selected Permission which provides an example sequence of API requests to grant Sites.Selected permission to the WorkPoint site and all Entity Sites in a given Business Module.
With the Postman project, first refer to the "User Authentication" folder documentation on defining Postman project with your environment credentials and generating an auth-token for your requests.
Note that the user that is executing the requests must have Site Collection Admin privileges in the WorkPoint Solution site and all Entity Sites for this process to succeed.
1. Access the collection folder "5. Grant WorkPoint Sites.Selected Permission"
2. Verify your selected environment refers to the Solution and contains the name of a Business Module in the WP_SOLUTION_URL and WP_BUSINESS_MODULE environment variables.
3. Click Run.
4. Click "Run WorkPoint API".
This will execute the API requests 1.. 4 in sequence and use Postman logic to iterate over each entity sites for requests 3 and 4 to Get the Next Entity and Grant Access according to your solution.
If your Solution contains multiple Business Modules, adjust the WP_BUSINESS_MODULE name in the Environment variable and repeat steps 3 and 4.
Please review the sequence of the API requests in this PostMan folder. You can either execute in PostMan directly or export the API sequence and implement an equivalent process in the scripting language/platform of your choice. (e.g. PowerShell / Node / Python etc.).
IMPORTANT: Before proceeding, ensure that the WorkPoint Entra application has access to all WorkPoint Solutions and all existing Entity Sites in the tenant. WorkPoint strongly recommends incorporating an audit step into your automation or scripting process that calls the Microsoft Graph API (as described in the Verifying Permissions Grant section) to confirm that the Entra application has the required permissions on each site before moving to the next step.
Step 3: Implement Site Provisioning Process
Recap; So far we have added the Limited Access site scopes and granted the WorkPoint application access to manage existing solutions and entity sites. We now need to consider how WorkPoint can create new sites.
When using the Full Control Permissions mode, WorkPoint can manage site collections autonomously, creating new site collections as needed. In contrast, with the Sites.Selected Permissions mode, WorkPoint will no longer have the ability to create new SharePoint sites in the tenant.
To use the Sites.Selected permissions model, Partners must implement a provisioning automation using an account that has authority to create site collections.
WorkPoint provide a series of convenience API's that can be executed in sequence to automate site creation, permission grants and registration.
The basic process for managing the Site Provisioning Workflow involves 4 key steps as highlighted in the image below. A custom site provisioning engine must:
1. Query the Site Collection Buffer to verify if there are sufficient sites available for projected demand (varies according to customer's processes and workloads). The automation can then implement conditional logic to abort (if sufficient) or continue with the site creation and registration process.
2. The automation creates a new Site Collection.
3. Grants the WorkPoint Application Full Control over the new Site.
4. Registers the Site Collection ready for use in the next Entity or Buffer Site creation event (5)
The WorkPoint API Postman Project contains a collection of API requests demonstrating this API sequence. Refer to the Postman project for instructions for creating a fork of the project, defining an environment and authenticating as a user with Site Collection creation privileges. The folder 4. Registering Site Collections in the PostMan project can then be used as a template for your custom site provisioning workflow.
Step 4: Revoke Full Control in Entra Admin
Recap: Now that we have added the Limited Access (Sites.Selected) claims to the Entra App; Granted WorkPoint access to existing WorkPoint solutions and Entity Sites and considered how to implement a Site Provisioning Workflow, we are now ready to REVOKE the previous Full Control access - reducing WorkPoint's permissions to Limited Access.
Revoking the Full Control permissions on the M365 Tenant is performed in the Entra Admin portal.
To do this...
1. Access the Entra Admin Portal on your M365 Tenant at https://entra.microsoft.com
2. Navigate to Enterprise Applications and search for the WorkPoint365 WebAPI registration for your platform (Test example shown below).
3. Select the Permissions blade
- (1) Filter permissions by the word "Site",
- (2) identify the "Microsoft.Graph" and Office permissions that use "Sites.FullControl" with type "Application".
- select the "..." more menu and "Revoke Permission" (3 & 4)
With Full Control permissions now revoked from the Enterprise Application, WorkPoint services are operating under a site-specific permissions model.
WorkPoint no longer has the ability to create sites nor access to any non-WorkPoint sites within the tenant.
Step 5: Refresh the Entra App Consent
Since the permission model is not regularly modified, for efficiency, WorkPoint services cache the level of access to avoid unnecessary (expensive) requests against the tenant's SharePoint services.
Having removed the previously granted Full Control permissions, we must instruct WorkPoint Services that the consent model has changed.
This is done in the WorkPoint Administration Portal per the screenshot below:
1. Navigate to "App Management"
2. Click the "Force Refresh consent check" button
Process complete: Permissions have now been downgraded to the "Sites.Selected" model and WorkPoint services updated to use the restricted permissions.
Comments
0 comments
Please sign in to leave a comment.