Step-by-step guide to deploying AccessPoint in your Microsoft 365 and Azure environment

Last updated: March 30, 2026 by Steve

Deployment Guide

This guide provides detailed instructions for deploying AccessPoint to your Microsoft 365 and Azure environment.

Subscription Required

Before deploying, your organization must have an active AccessPoint subscription. You can start a free trial or purchase a subscription from Microsoft AppSource:

The subscription activates your license key, which the application validates at runtime. No usage data or customer information is transmitted during license validation — only the license key and tenant ID.

What Gets Deployed

AccessPoint is composed of three components deployed into your own tenant and subscription:

Component Source Destination
SPFx Web Part Microsoft AppSource Customer's SharePoint Online
Teams App Microsoft AppSource Customer's Teams Admin Center
Azure Backend Bicep ARM template + PowerShell script Customer's Azure subscription

The Azure backend includes the following resources:

  • App Service (Linux, ASP.NET Core 10) — API and application logic
  • Azure SQL Database — Structured data storage
  • Azure Blob Storage — Document and file storage
  • Application Insights + Log Analytics — Monitoring and diagnostics

Resource names follow the pattern {type}-accesspoint-{tenantName} (e.g., app-accesspoint-contoso, sql-accesspoint-contoso).

Prerequisites

Before beginning deployment, confirm that you have:

  • An active Azure subscription with permissions to create resources (Contributor role or higher)
  • A SharePoint App Catalog provisioned in your Microsoft 365 tenant. If one does not exist, a tenant administrator can create it from the SharePoint Admin Center.
  • Global Administrator or Application Administrator access in Entra ID for Graph permission grants
  • No direct dependencies on M365 licensing tiers — any user with access to SharePoint or Teams can use AccessPoint
  • No Power Platform or Dataverse licensing required

Deployment Artifacts

Artifact Purpose
Deploy to Azure Opens the Azure Portal with the ARM template pre-loaded
Deploy-AccessPoint.ps1 Post-deployment configuration script (right-click, Save As)
AccessPoint SPFx Web Part Install from Microsoft AppSource into your SharePoint App Catalog
AccessPoint Teams App Install from Microsoft AppSource into your Teams Admin Center
AccessPoint.Api.zip API package — deployed automatically during ARM deployment (no manual download needed)

Required Roles

Role Purpose
SharePoint Admin or Global Admin SPFx web part deployment and API permission approval
Azure Owner or Contributor Azure resource deployment via Bicep template
Entra ID Global Admin or Application Admin Microsoft Graph permission grants (admin consent)

Browser Support

AccessPoint supports all modern browsers: Microsoft Edge, Google Chrome, Mozilla Firefox, and Apple Safari (latest versions).

Step 1: Deploy Azure Resources

Click the button below to pre-load the AccessPoint ARM template in the Azure Portal:

Deploy to Azure

  1. The Azure Portal opens with the ARM template pre-loaded
  2. Select your subscription and create or select a resource group
  3. Enter your tenant name (e.g., contoso from contoso.sharepoint.com) — this is used to name all resources uniquely
  4. Enter your license API key (provided by Realizer Services during subscription setup)
  5. Optionally select an App Service Plan SKU (defaults to P1v3). See App Service Plan Sizing below.
  6. Optionally enter an alert email address for monitoring notifications
  7. Optionally set Grant Graph Permissions to true (default) to automatically grant Microsoft Graph API permissions to the managed identity during deployment. This requires the deploying user to have Application Administrator or AppRoleAssignment.ReadWrite.All permissions in Entra ID. If unchecked, use Deploy-AccessPoint.ps1 to grant permissions after deployment.
  8. Click Review + create, then Create
  9. The API code is automatically downloaded and deployed into the App Service during ARM deployment — no manual API deployment needed. After deployment, the code lives entirely in your App Service with no runtime dependency on external services.
  10. Microsoft Graph permissions (Mail.Send, User.Read.All, TeamsAppInstallation.ReadForUser.All, Application.Read.All, AppCatalog.Read.All) are granted automatically via the Bicep Graph extension if the deploying user has sufficient Entra ID permissions.
  11. After deployment completes, perform a full Stop/Start cycle on the App Service (Azure Portal > App Service > Overview > Stop, wait 10 seconds, then Start) to activate the Graph permissions.

Azure Portal deployment

Graph Permissions via Infrastructure-as-Code

The Bicep template includes a graph.bicep module that uses the Microsoft Graph Bicep extension to grant Graph application permissions to the App Service managed identity during deployment. This is enabled by default (grantGraphPermissions=true).

  • The deploying principal must have Application Administrator or AppRoleAssignment.ReadWrite.All permissions in Entra ID
  • If the deploying principal lacks sufficient permissions, the deployment will fail on the Graph module — re-deploy with grantGraphPermissions=false and use Deploy-AccessPoint.ps1 as a CLI fallback
  • The deploy script automatically detects whether Graph permissions were granted by Bicep (via the graphPermissionsGranted output) and skips the CLI fallback step if so

Option B: PowerShell Script

For organizations with custom deployment pipelines or strict change control, run the deployment script directly:

# Download the deployment script
Invoke-WebRequest -Uri "https://get.realizer.io/public/accesspoint/latest/Deploy-AccessPoint.ps1" -OutFile "Deploy-AccessPoint.ps1"

# Run the deployment (tenant name is derived from the SharePoint URL)
.\Deploy-AccessPoint.ps1 -SharePointSiteUrl "https://contoso.sharepoint.com/sites/accesspoint"

You can also provide the tenant name explicitly and choose a different App Service Plan:

.\Deploy-AccessPoint.ps1 -TenantName contoso `
    -SharePointSiteUrl "https://contoso.sharepoint.com/sites/accesspoint" `
    -AppServiceSku S1

Remote template deployment: If you downloaded the script separately (without local Bicep files), use the -TemplateUri parameter:

.\Deploy-AccessPoint.ps1 -SharePointSiteUrl "https://contoso.sharepoint.com/sites/accesspoint" `
    -TemplateUri "https://get.realizer.io/public/accesspoint/latest/main.json"

If neither a local Bicep file nor -TemplateUri is provided, the script automatically skips infrastructure deployment and proceeds with the configuration steps only.

The script executes the following steps:

  1. Deploys Azure infrastructure via Bicep (App Service, SQL, App Insights, Storage)
  2. Configures SQL Entra-only authentication (sets the deploying user as Entra admin, disables SQL password auth)
  3. Grants Microsoft Graph permissions to the App Service managed identity (Mail.Send, User.Read.All, TeamsAppInstallation.ReadForUser.All, Application.Read.All, AppCatalog.Read.All) — skipped automatically if Bicep already granted them
  4. Performs a full stop/start cycle on the App Service to clear the managed identity token cache
  5. Configures SharePoint tenant storage entities (API URL)
  6. Approves SPFx API permission requests

Each step can be skipped independently (-SkipInfrastructure, -SkipGraphPermissions, -SkipSharePoint). Infrastructure deployment is automatically skipped when neither local Bicep nor -TemplateUri is provided.

Deploy-AccessPoint.ps1 output

Option C: Step-by-Step Manual Deployment

For organizations that prefer to run each step individually rather than using the automated script, the steps are:

  1. Deploy Azure infrastructure — Run the Bicep template via az deployment group create with the published ARM template
  2. Enable SQL Entra-only auth — Run az sql server ad-only-auth enable to disable SQL password authentication
  3. Grant Graph permissions — Grant each application permission to the managed identity via az rest calls to the Graph API (or rely on the Bicep Graph extension)
  4. Cycle the App Service — Full stop/start (not restart) to clear the managed identity token cache
  5. Configure SharePoint storage entity — Use PnP PowerShell to set the API URL via Set-PnPStorageEntity
  6. Approve SPFx API permissions — Use PnP PowerShell to approve permission requests via Grant-PnPTenantServicePrincipalPermission

Using Existing Infrastructure

Organizations that want to add AccessPoint to an existing App Service Plan or SQL Server can customize the Bicep modules, deploy individual resources selectively, or use the templates as a reference for their own pipeline. The provisioned resources are:

  • Azure App Service (with system-assigned managed identity)
  • Azure SQL Server and Database (Entra-only authentication)
  • Azure Blob Storage (Microsoft-managed AES-256 encryption by default)
  • Application Insights and Log Analytics Workspace
  • Metric alerts (only when an alert email address is provided)

Optional: Customer-managed key (CMK) encryption for Blob Storage can be added post-deployment using an existing or new Key Vault.

What Gets Provisioned

Resource Default SKU Purpose
App Service + App Service Plan P1v3 (Linux) Web API hosting
Azure SQL Server + Database Basic (2 GB) Application data
Storage Account LRS Document file storage (Microsoft-managed AES-256 encryption)
Application Insights + Log Analytics PerGB2018 Monitoring and diagnostics
Metric Alerts (optional) — HTTP 5xx and latency alerts (only when alert email provided)

All resources are created in the customer's Azure subscription. The customer retains full ownership of the resource group. Security is hardened by default: TLS 1.3, FTPS disabled, SCM/FTP basic auth disabled, HTTP/2 enabled.

App Service Plan Sizing

SKU Tier Best For Key Capabilities Approx. Cost
B1 Basic Evaluation, testing, small departments (<50 users) No auto-scale, no staging slots ~$13 USD/month
S1 Standard Production workloads (recommended) Auto-scale up to 10 instances, staging slots, custom domains ~$73 USD/month
P1v3 Premium v3 Large organizations, high-volume processing Faster CPU/memory, VNet integration, up to 30 instances ~$138 USD/month
P2v3 Premium v3 Very large organizations, CPU-intensive document processing Double CPU/memory of P1v3, VNet integration ~$276 USD/month

Customers can scale up or down at any time in the Azure Portal without redeployment.

Step 2: Install the SPFx Web Part

Install the AccessPoint web part from Microsoft AppSource:

  1. Go to the AccessPoint SPFx Web Part on AppSource and click Get it now
  2. Follow the prompts to add it to your tenant's SharePoint App Catalog
  3. In the SharePoint Admin Center, verify the solution appears under More features > Apps > App Catalog
  4. Ensure the solution is deployed tenant-wide

Step 3: Approve API Permissions

After deploying the SPFx package:

  1. In the SharePoint Admin Center, go to Advanced > API access
  2. Review and Approve each pending permission request from the AccessPoint package

Step 4: Add Web Part to a SharePoint Page

  1. Navigate to the SharePoint site where you want to add AccessPoint
  2. Edit a page (or create a new page)
  3. Click + to add a web part and search for AccessPoint
  4. Add the web part and publish the page

Step 5: Configure the API URL

  1. Open the AccessPoint web part
  2. Navigate to Settings > Setup
  3. Enter the API URL — this is the App Service URL from Step 1 (e.g., https://app-accesspoint-contoso.azurewebsites.net)
  4. Enter the Client ID of the API's Entra ID app registration
  5. Click Save

The system validates that the URL uses HTTPS and that the Client ID is a valid GUID before saving.

Post-deployment Setup

Step 6: Import a Configuration Pack

  1. Go to Settings > Configuration Packs
  2. Browse the available configuration packs for your jurisdiction (e.g., Canada ATIA, US FOIA, EU GDPR)
  3. Select the appropriate pack and click Import
  4. The system creates request types, extension reasons, choice fields, notification templates, and translations
  5. Review and customize the imported items as needed

Step 7: Assign User Roles

  1. The first user to access AccessPoint is automatically granted both Administrator and SAO roles
  2. Go to Settings > Manage Users
  3. Click Add User and search for users in your organization's directory
  4. Assign appropriate roles: at least one Administrator and one SAO
  5. Add additional roles (Custodian, Contributor, Reviewer, Reader) as needed

AccessPoint is now ready for use.

Teams Notifications (Optional)

Teams activity feed notifications are disabled by default and require additional setup. See the Initial Setup page for details on configuring email and Teams notifications, including the Realizer enterprise app consent and Teams app deployment.

Multi-Tenant Deployment

This section covers deployments where the Azure backend is hosted in a different Entra ID tenant than the customer's Microsoft 365 tenant. This is common when:

  • A shared services team operates centralized Azure infrastructure on behalf of multiple business units, each with their own M365 tenant
  • A managed service provider (MSP) hosts AccessPoint infrastructure for multiple client organizations
  • An organization has separate Azure and M365 tenants for governance or procurement reasons

Shared Infrastructure for Multiple M365 Tenants

A single AccessPoint Azure deployment (App Service, SQL Database, Blob Storage) can serve multiple M365 tenants simultaneously. The API isolates each tenant's data using the Entra ID tenant ID extracted from each user's JWT token. All database queries and blob storage paths are scoped by tenant ID automatically.

Requirements for shared infrastructure:

  • Each M365 tenant must have its own AccessPoint license
  • Each M365 tenant must complete its own SPFx package deployment and API permission approvals
  • Each M365 tenant must configure its own Graph API credentials (see steps below)
  • Each M365 tenant configures its own notification mailbox and Teams notifications independently

Data isolation: Tenants sharing the same infrastructure cannot see each other's data. The API enforces tenant isolation at the database query level using global query filters on the tenant ID. Blob storage paths are prefixed with the tenant ID.

Shared Azure Subscription
┌─────────────────────────────────────────────────┐
│ App Service (single API instance)               │
│ Azure SQL Database (tenant-scoped data)         │
│ Azure Blob Storage (tenant-prefixed paths)      │
└──────────┬──────────────────┬───────────────────┘
           │                  │
    M365 Tenant A       M365 Tenant B
    (own SPFx app,      (own SPFx app,
     own license,        own license,
     own Graph creds)    own Graph creds)

Step 1: Create an App Registration in the M365 Tenant

In a multi-tenant deployment, the App Service managed identity cannot call Microsoft Graph in the M365 tenant — managed identities only have permissions in their home tenant. Instead, create an app registration in the M365 tenant:

  1. Go to Entra ID > App registrations > New registration
  2. Name it descriptively (e.g., AccessPoint Graph Connector)
  3. Set Supported account types to Accounts in this organizational directory only (single tenant)
  4. No redirect URI is needed
  5. Click Register and note the Application (client) ID and Directory (tenant) ID

Step 2: Grant Graph API Permissions

On the newly created app registration:

  1. Go to API permissions > Add a permission > Microsoft Graph > Application permissions
  2. Add the following permissions:
Permission Purpose
Mail.Send Send email notifications from the shared mailbox
User.Read.All Validate mailbox addresses, resolve user profiles
TeamsAppInstallation.ReadForUser.All Pre-check Teams app installation before dispatching notifications
Application.Read.All Teams setup validation — verify publisher enterprise app consent
AppCatalog.Read.All Teams setup validation — check Teams app in org catalog
  1. Click Grant admin consent for [tenant] (requires Global Administrator)

Step 3: Create a Client Secret

  1. Go to Certificates & secrets > New client secret
  2. Set an appropriate expiry (e.g., 24 months)
  3. Copy the Value (not the Secret ID) — this is only shown once
  4. Store the secret in Azure Key Vault in the Azure subscription hosting AccessPoint

Step 4: Configure App Service Settings

Add the following App Service configuration settings (Azure Portal > App Service > Settings > Environment variables):

Setting Value
Graph__TenantId The M365 tenant's directory ID (from Step 1)
Graph__ClientId The app registration client ID (from Step 1)
Graph__ClientSecret A Key Vault reference to the client secret (from Step 3)

The Key Vault reference format for the client secret is:

@Microsoft.KeyVault(SecretUri=https://<vault>.vault.azure.net/secrets/GraphClientSecret)

Security: Always use a Key Vault reference for the client secret. Never store secrets directly in App Service configuration or source code. The App Service managed identity needs the Key Vault Secrets User role on the vault.

When all three Graph settings are present, the API authenticates to Microsoft Graph using the M365 tenant's app registration. When any are missing, it falls back to the managed identity for same-tenant deployments.

Step 5: Create the Shared Mailbox

In the Microsoft 365 Admin Center (the M365 tenant):

  1. Go to Teams & groups > Shared mailboxes
  2. Click Add a shared mailbox
  3. Name it appropriately (e.g., accesspoint-noreply@contoso.com)
  4. The mailbox does not need a license assigned

To restrict the app registration so it can only send from the designated shared mailbox, create an Application Access Policy in Exchange Online:

  1. Create a mail-enabled security group and add the shared mailbox to it
  2. Create an Application Access Policy scoping the app registration to that group
  3. Test the policy (may take up to 30 minutes to propagate)

Step 7: Deploy SPFx and Teams Apps

Each M365 tenant needs its own SPFx and Teams app deployment:

  1. Install the AccessPoint SPFx Web Part from AppSource into the M365 tenant's SharePoint App Catalog
  2. Approve API permissions in the SharePoint Admin Center
  3. Add the web part to a SharePoint page
  4. Configure the API URL in Settings > Setup — the same API URL is used for all tenants sharing the infrastructure

Step 8: Configure Teams Notifications

Teams activity feed notifications require the Realizer enterprise app to be consented in each M365 tenant:

  1. Grant admin consent for the Realizer enterprise application (consent URL is in Settings > Setup)
  2. Install the AccessPoint Teams App for users via the Teams Admin Center
  3. Enable Teams notifications in the Setup panel

See the Initial Setup page for detailed Teams notification configuration.

Troubleshooting

API Connection Fails

  • Verify the App Service is running in the Azure Portal
  • Confirm the API URL uses HTTPS and matches the SharePoint tenant storage entity value
  • Check the health endpoint: GET https://<api-url>/api/health
  • Check Application Insights for error logs

Permission Errors

  • Verify Microsoft Graph permissions have been granted with admin consent
  • Confirm the App Service managed identity is correctly configured
  • Check that SQL Entra-only authentication is enabled and the managed identity has database access
  • After granting Graph permissions, perform a full stop/start cycle on the App Service to clear the token cache

SPFx Web Part Does Not Load

  • Ensure the solution is deployed tenant-wide in the App Catalog
  • Verify API permissions have been approved in the SharePoint Admin Center
  • Clear browser cache and reload the page

Getting Help

If you encounter issues during deployment:

←
Previous Administrator Guide
Next Settings Overview
→