Deployment Guide

AccessPoint uses a split deployment model: a lightweight SPFx web part in SharePoint, a Teams app that hosts the same web part as a personal tab, and an Azure backend that runs the API and stores all data. Every component lands in your own Microsoft 365 tenant and Azure subscription — nothing is hosted by the publisher, and no customer data leaves your environment.

This page is the operator's walkthrough. The full parameter reference, with every default and what each setting deploys, is in the product's deployment reference (the Deployment Guide section of the User Guide that ships with each release); this page covers the parameters you are most likely to need.

Overview

For sovereign/government clouds, version pinning, or scripted deployments, all artifacts are also published to https://get.realizer.io/public/accesspoint/latest/. AccessPoint is deployed from this template into your own subscription; the Microsoft Marketplace listing carries the subscription and license only.

Install order matters. Install the SharePoint solution before any user opens the Teams personal tab. The Teams app loads the SPFx web part from SharePoint in an iframe — without it, users see a SharePoint 404 inside Teams.

Prerequisites

• An active AccessPoint subscription (get AccessPoint) — the API activates its license automatically using its Entra identity, so no license key is needed unless Realizer Support provides one for your tenant
• An Azure subscription where you are Owner or User Access Administrator on the target resource group — the template creates role assignments and, by default, one custom role definition (the blob version-delete role). Contributor plus Role Based Access Control Administrator works if you set grantBlobVersionDeletion=false
• A SharePoint App Catalog provisioned in your tenant. If none exists, a SharePoint Administrator creates it from SharePoint Admin Center > More features > Apps > Open
• Global Administrator or Application Administrator in Entra ID for Graph permission grants and admin consent
• A SharePoint Administrator or Global Administrator to install the SharePoint package
• Teams Administrator (or Global Admin) to publish the Teams app
• For scripted or manual deploys: Azure CLI (signed in with az login as a user, not a service principal) and the PnP.PowerShell module

No Microsoft 365 licensing tier, Power Platform, or Dataverse dependency exists — any user with SharePoint or Teams access can use AccessPoint.

Licensing: the core product and its modules

AccessPoint is licensed per deployment and priced by covered population — the combined number of employees of every organization whose records the deployment processes. Users are unlimited on every plan. Each deployment validates its license with Realizer on its own, using its own Entra identity and no license key.

A subscription always includes the core product: the five case registers, the documents and redaction workspace, reviews, correspondence, reports, jurisdiction packs and train mode. Four modules sit beside it:

Every plan includes all four modules. A module works when three things are true: your license includes it, its Azure resource is deployed where it needs one (Azure OpenAI, the portal web app, the media worker), and it is switched on in Settings > Features. If a license leaves a module out, Settings shows its switches locked with a "Not included in your subscription" message and its actions are refused. Nothing is deleted: what was made with a module stays and comes back when the module is licensed again.

Step 1: Deploy Azure resources

This step provisions the backend: a Linux App Service (the API), Azure SQL Database, Blob Storage, a Key Vault, the document worker, and Application Insights with Log Analytics. Resources are named {type}-accesspoint-{tenantName} (for example, app-accesspoint-contoso) and are hardened by default (TLS 1.3, Entra-only SQL auth, FTPS and basic auth disabled, Microsoft Defender for SQL on by default). The SQL server is created Entra-first: the deploying user becomes the initial Entra admin and no SQL credential ever exists — there is nothing to rotate or disable.

Weekly "Vulnerability Assessment scan completed" emails showing failing checks, but nothing in the portal? Expected on a fresh deployment, not a vulnerability. Microsoft Defender for SQL runs the classic (storage-backed) Vulnerability Assessment, but the Azure portal's Defender blade now defaults to the newer express configuration view, so the email's "View results" link can land on a view with no scans in it. The failing checks are baseline checks, which fail until the current state is approved as the baseline — the template pre-approves the deterministic VA2065 (firewall rules) check, but the user-tracking check on the application database can't be pre-declared. Resolve it once: open the SQL server (not the database) → Microsoft Defender for Cloud → Vulnerability assessment → open the failing check → Approve as baseline → Scan again. Check first that every row is one of AccessPoint's own identities or a person you added on purpose.

Option A: the guided Deploy to Azure form (recommended)

Click Deploy to Azure in Settings > Setup (or from the documentation). The Azure portal opens a guided form with four pages. Each question says what it does and, for optional components, what it costs, and follow-up questions appear only when you turn their feature on.

1. Basics — your subscription, resource group and region, then:
   • Organization short name — the first part of your SharePoint address (contoso from contoso.sharepoint.com). It names every resource.
   • Installation type — mandatory, with no default. Pick New installation for a first-time deployment, or Upgrade existing installation when redeploying over a running AccessPoint. See Installation type.
   • AccessPoint version — leave latest, or enter an exact version such as 2.5.0.
   • Server size — the App Service plan. P1v3 is the recommended default; choose P2v3 when recordings will be processed without the media worker (B1 is for evaluation only).
   • Database size — leave Automatic to create S0 on a new installation and to keep your current size on an upgrade. A size you changed in the Azure portal is never undone by a redeploy.
   • Alert e-mail address — optional; creates the alert rules and adds the address to the weekly SQL vulnerability assessment e-mail.
2. Features — the optional components below.
3. Security and compliance — Defender for SQL, malware scanning, Defender for App Service, the private network options, tamper-proof evidence storage and log retention. See Optional hardening.
4. Advanced — hidden behind one Show them switch. Open it for the Front Door options, AI regions, media worker sizing and image mirrors, least-privilege database access, your own storage encryption key, or the Microsoft 365 tenant ID of a split-tenant deployment.

A setting the form does not show keeps the template's default — for example the Key Vault (on), the license key (blank: AccessPoint activates its license with the application's Entra identity) and the document worker (on). To change one of those, deploy with Deploy-AccessPoint.ps1 or az deployment group create -p name=value. On an upgrade, answer every question the way the installation was first set up; the form does not read your earlier choices back, so keep a record. The API package deploys into the App Service automatically, so after deployment there is no runtime dependency on external services.

Finish Setup (Graph permissions). The template itself never grants Graph permissions. After deployment, open the finishSetupUrl link from the deployment's Outputs and sign in as a Global Administrator. The page shows the identity it is about to grant to — name, type and Azure resource id — and grants nothing until you choose Grant these permissions; check that the resource id is the App Service your deployment created. Revisit the same link after an upgrade to pick up newly introduced permissions. Then perform a full Stop/Start cycle on the App Service (not Restart) so the permissions take effect.

Option B: Bicep + PowerShell

For custom pipelines or strict change control, run the deployment script against the published ARM template:

Invoke-WebRequest -Uri "https://get.realizer.io/public/accesspoint/latest/Deploy-AccessPoint.ps1" -OutFile "Deploy-AccessPoint.ps1"

# End-to-end: infrastructure, configuration, and both apps
.\Deploy-AccessPoint.ps1 `
    -SharePointSiteUrl "https://contoso.sharepoint.com/sites/accesspoint" `
    -TemplateUri "https://get.realizer.io/public/accesspoint/latest/main.json" `
    -DeploySharePointApp -DeployTeamsApp

The script auto-detects the deployment type (new installation vs. upgrade) and runs up to seven steps — infrastructure, SQL Entra-only authentication (a backstop: current templates create the server Entra-first), Graph permission grants (the scripted equivalent of the Finish Setup page), an App Service stop/start cycle, the optional SharePoint storage entity (API URL), SPFx API permission approvals, and optional app installs. Each is independently skippable (-SkipInfrastructure, -SkipGraphPermissions, -SkipSharePoint). Pin a version with -ArtifactBaseUrl "https://get.realizer.io/public/accesspoint/2.5.0" for reproducible, integrity-verified deploys: the script checks the published checksums and signatures and aborts on any mismatch (see Signed releases).

To run the infrastructure pieces yourself instead:

$TenantName    = "contoso"
$ResourceGroup = "rg-accesspoint-$TenantName"

az group create --name $ResourceGroup --location "canadacentral"

# deploymentType is required: "New installation" for a first deploy,
# "Upgrade existing installation" to preserve operator app settings.
# Add any other parameter as name=value (for example deployAiAssist=true).
$deployment = az deployment group create `
    --resource-group $ResourceGroup `
    --template-uri "https://get.realizer.io/public/accesspoint/latest/main.json" `
    --parameters tenantName=$TenantName appServiceSku=P1v3 "deploymentType=New installation" `
    --output json | ConvertFrom-Json

$appName     = $deployment.properties.outputs.appServiceName.value
$apiUrl      = $deployment.properties.outputs.appServiceUrl.value
$principalId = $deployment.properties.outputs.appServicePrincipalId.value

An array parameter such as hybridConnectionEndpoints goes in a parameters file (--parameters @params.json).

Installation type: New or Upgrade

Installation type has no default on purpose. A redeploy from the portal that silently ran as a fresh install would wipe every operator-added application setting.

• New installation — SQL is created Entra-first with the deploying user as initial admin, and application settings are written from the template alone.
• Upgrade existing installation — the site's current settings are read first and merged: operator-added settings carry over, and template-managed settings win on conflict. Database access is left untouched. A component you turn off leaves its old setting in place until you remove it by hand. Use this for every later deployment: version updates, adding an optional component, changing a parameter.

Deploy-AccessPoint.ps1 picks the value itself (an existing SQL server for the tenant means upgrade). Every deployment ends with a settings write that restarts the App Service onto the new package. On an upgrade, the restarted API first brings the database schema up to date, which on a large database can take several minutes before the site answers.

What a deployment creates

The template never grants Microsoft Graph permissions (Finish Setup does that) and never installs the SharePoint or Teams packages.

Optional components

None of these is required to run AccessPoint. All are off unless you enable them at deploy time, except the document worker and the Key Vault (on by default) and the Copilot capture and directory permissions (granted by default, with an opt-out). Every optional resource is deployed into your own Azure subscription with managed-identity-only authentication and key access disabled — no customer data leaves your tenancy, and Microsoft does not train models on it.

• Deploy AI Assist (Azure OpenAI) — adds an Azure OpenAI resource with managed-identity auth (no API keys). Billing is pay-per-use, so an idle tenant pays about $0 and a busy department typically spends single-digit dollars per month. Each AI feature is individually switchable under Settings > Features. Every AI output is a suggestion or an editable draft — a person always decides. Choose the data-zone deployment type when AI processing must stay within the EU or US.

• Deploy AI Search (deployAiSearch=true) — adds Azure AI Search so the Documents search box matches words inside documents in addition to names, types, and tags; with AI Assist also deployed it supports semantic search. The basic tier is about USD $75 a month. An Administrator sweep (Settings > Setup > Document content search) indexes documents that predate it.

• Deploy Document Intelligence (deployDocumentIntelligence=true) — adds Azure AI Document Intelligence for OCR of scanned, image-only documents, and for on-screen text detection in video. Billing is pay-per-page (roughly USD $1.50 per 1,000 pages).

• Deploy Speech (deploySpeech=true) — adds Azure AI Speech for transcripts and captions of video and audio records. Billing is per audio hour (roughly USD $0.18) and about $0 when idle.

• Deploy Defender for Storage (deployDefenderForStorage=true) — turns on on-upload malware scanning for the documents account. The API mirrors each verdict onto the document and blocks preview, playback, download, and release of anything flagged. Billed per GB scanned, capped by malwareScanCapGBPerMonth (default 5,000). Register the Microsoft.EventGrid provider on the subscription first (once per subscription); without it the deployment succeeds but the scanner stays off and every upload waits on "Scanning for malware…". Deploy-AccessPoint.ps1 registers it for you.

• Deploy media processing (deployMediaProcessing=true) — the production-scale media executor: two Storage Queues and a scale-to-zero Container Apps job running the publisher's media worker image, so transcodes, thumbnails, and release rendering leave the App Service. Without it, recordings are processed in-process on the App Service (choose P2v3). Billed per vCPU-second while a job runs; about $0 idle. The job pulls a code-only container image — no customer data ever transits the registry. For production, mirror the image into your own Azure Container Registry once per version and point mediaWorkerImage and mediaWorkerRegistryResourceId at it, so media jobs never depend on the publisher registry being reachable:

  az acr create --name <yourregistry> --resource-group <rg> --sku Basic
  az acr import --name <yourregistry> --source realizer.azurecr.io/accesspoint/media-worker:<apiVersion> --image accesspoint/media-worker:<apiVersion>
  # deploy with: mediaWorkerImage = <yourregistry>.azurecr.io/accesspoint/media-worker:<apiVersion>
  #              mediaWorkerRegistryResourceId = $(az acr show --name <yourregistry> --query id -o tsv)
  

  Re-run the import when you upgrade — the tag follows the API version. Egress-restricted subscriptions must use this path. The document worker and the accessibility checker have the same image, digest and registry parameters.

• Check response packages for accessibility (deployAccessibilityCheck=true) — an event-driven job in the same Container Apps environment that checks response packages against the PDF/UA-1 standard before release.

• Public intake portal (deployPublicPortal=true) — see Public intake portal.

• Reach systems inside your network (deployHybridConnections=true) — see Reaching on-premises connector hosts.

• SharePoint origin (sharePointOrigin=https://contoso.sharepoint.com) — adds a blob CORS rule for your SharePoint origin and lets recordings play directly from Blob Storage through one-hour user-delegation links instead of streaming through the API. Leave it empty under network isolation.

• Copilot capture permission (AiEnterpriseInteraction.Read.All) — granted by default so custodians can capture Copilot interaction history via Documents > Add from Microsoft 365 out of the box. It is application-only (Microsoft Graph offers no delegated variant), but AccessPoint only ever reads the signed-in user's own Copilot history. Opt out with Deploy-AccessPoint.ps1 -DisableCopilotCapture or on the Finish Setup page, and revoke the app role in Entra ID at any time.

Optional hardening

The security-related settings default to the secure, turnkey value. The ones operators most often adjust:

• Firewall rules for the API. Put the API behind Azure Front Door (frontDoorForApi, under Advanced): its origin is then locked to Front Door, which adds a web application firewall (WAF) with custom rules on every tier, a per-address flood ceiling, and the caller's real address in the audit trail. Premium adds Microsoft's managed rule sets and bot protection.
• Private network. Private network for the database and storage (deployNetworkIsolation) places the API in a virtual network. Choose it on a new deployment; enabling it on a live tenant briefly severs the App Service from SQL and storage. Two modes: service endpoints (the default; SQL, storage and the Key Vault accept traffic only from AccessPoint's subnets) or private endpoints (networkIsolationMode=PrivateEndpoints; each service gets a private endpoint and public network access is turned off). With public access off you cannot browse blobs, keys or the database from outside the network — use a machine inside it.
• Defender for App Service (enableDefenderForAppService; the form's Microsoft Defender for App Service) — traffic- and sandbox-level threat detection for the API and portal. It is a subscription-wide plan billed per App Service instance, so it also covers other App Services in the subscription.
• Tamper-proof evidence storage (deployEvidenceWormContainer) — a separate evidence container with a time-based immutability policy for exported evidence packages and audit-ledger anchors. The policy is created unlocked; locking it is irreversible and deliberate (Deploy-AccessPoint.ps1 -LockEvidenceImmutabilityPolicy asks you to type LOCK).
• Least-privilege database access (sqlLeastPrivilegeRuntime) — the API connects as a contained user that cannot update or delete the audit ledger. Opt in after validating on a non-production deployment.
• Mail.Send scope. By default the managed identity can send as any mailbox. Deploy-AccessPoint.ps1 -ConfigureMailPolicy -NotificationMailboxGroup <group> restricts it to the notification mailbox with an Exchange Online application access policy (see Multi-tenant deployment for the manual commands).
• Logs. Log retention (logRetentionDays, 30–730) and resource log shipping (deployDiagnosticSettings) are on the Security and compliance page. Turn off the resource logs only if Azure Policy already sends the same categories to the workspace.

Customer-managed encryption keys

Data is encrypted at rest from the first deployment, under keys Microsoft manages. If your policy requires keys that you create, hold and can revoke, you can put the documents storage account and the database under your own keys in Azure Key Vault. Name the storage key when you deploy (storageEncryptionKeyUri, plus storageEncryptionIdentityId on a new installation, both under Advanced) or add it afterwards; the database key is always added afterwards.

Things to know before you do:

• Every Upgrade existing installation deployment keeps the keys you set. (Before 2.5.0 each deployment put the storage account back on Microsoft-managed keys.) So once AccessPoint is installed, always redeploy as Upgrade existing installation.
• AccessPoint then depends on your key. If the key is disabled, deleted or expires, or the storage account or database server loses its permission on it, AccessPoint stops working for everyone. A deleted key is recoverable for 90 days; once purged, everything encrypted under it is lost, including backups.
• The Key Vault the template creates already holds the dataprotection key and can also hold your storage and database keys. Use a vault of your own when your policy requires HSM-protected keys, when key administration must sit with different people, or when you need network rules of your own on the vault (the template rewrites the template vault's firewall on each deployment).
• Use one key for storage and a different one for the database.

The step-by-step commands (creating the keys, assigning roles, enabling auto-rotation, checking the result, and recovering if access to a key is lost) are in the deployment reference. Contact support if you want help planning it.

Reaching on-premises connector hosts (Hybrid Connections)

Connectors that sit next to an on-premises records system — a network file share, Hyland OnBase, OpenText Content Server (GCdocs) — usually have no public endpoint, and the App Service has no route into your data centre. App Service Hybrid Connections close that gap without a VPN, ExpressRoute or inbound firewall rule: an Azure Relay namespace in your subscription carries a TCP tunnel, and a small agent on your side — the Hybrid Connection Manager — makes an outbound HTTPS connection to the relay. The tunnel carries the API's own TLS session end to end, so the relay never sees plaintext.

1. Deploy with deployHybridConnections=true and list each host in hybridConnectionEndpoints, for example [{"host":"onbase.corp.contoso.ca","port":443}] (on the form: Reach systems inside your network, with an editable host and port grid; script: -HybridConnectionEndpoints 'host:port',…). Each entry is exactly one TCP host:port. Use a DNS name that the machine running the manager can resolve — not an IP address, never localhost. The name must also be one the connector's TLS certificate covers.
2. Install the Hybrid Connection Manager on a machine that can reach every configured host (Windows or Linux x64; download it from the Hybrid connections blade of the App Service). It needs outbound TCP 443 to *.servicebus.windows.net only. Run it on two machines for redundancy. The status on the App Service blade changes from Not connected to Connected.
3. Register the connector under Settings > Foundations > Repository connectors > Add connector > Remote with https://<host>:<port>/, switch on Reached through a Hybrid Connection, and run Test connection. See Connectors.

Relay bills per listener (about USD $10 a month, with 5 GB of traffic included); an empty namespace is free. Entries you remove later are not deleted by a redeploy — delete them in the portal. Anything with an HTTPS endpoint the App Service can already reach needs no relay.

Public intake portal and Azure Front Door

The public intake portal is a second web app on the same App Service plan as the API, with its own managed identity and no access to your case documents. It is the only part of AccessPoint that faces the internet: requestors submit and track requests, collect secure deliveries and pay fees there without an account, protected by an e-mailed one-time code at every step. The API's hostname never appears on a public page.

Deploy it with deployPublicPortal=true (script: -DeployPublicPortal). The follow-up questions on the form are the custom domain, the web sites that may embed the request form, and Protect the portal with Azure Front Door (deployFrontDoor, with a Standard or Premium tier). Front Door adds a web application firewall with a per-client rate limit on the anonymous intake and verification routes, and locks the portal's web app so it accepts traffic only through Front Door.

Custom domain:

• Without Front Door — deploy once and note portalCustomDomainVerificationId; add a TXT record asuid.<domain> with that value and a CNAME to the portal web app; then redeploy as Upgrade existing installation with portalCustomDomain=<domain>. The template binds the host name and issues a managed certificate.
• With Front Door — note portalFrontDoorEndpoint and portalFrontDoorDomainValidationToken; add a TXT record _dnsauth.<domain> with the token and a CNAME to the endpoint host name. Do not also bind the domain to the web app.

Then, inside AccessPoint, switch on Settings > Features > Public portal, configure Settings > Foundations > Public portal (allowed host origins, languages, reference prefix, delivery and retention days) and publish the intake form. The portal's e-mails go out through the API's notification mailbox, so notifications must be configured in Settings > Setup first. Deploying the portal switches nothing on by itself. See Public portal and the public intake portal overview.

Registering a payment provider

Online fee payment rides on the portal, so deploy and enable the portal first. Then:

1. Switch on Settings > Features > Payments (off by default; offline Record payment works without it) and set the prepayment threshold, deposit percent and waive-below amount under Settings > Requestors > Requestor fee categories.
2. Under Settings > Foundations > Payment providers, choose Add, pick the provider (Stripe Checkout, Paymentus, or a generic hosted page), fill in the fields, keep Test mode on with sandbox credentials, save, and copy the notify URL from the row. The provider posts payment results to that address on the portal host.
3. For Stripe, create a webhook endpoint for that URL in the Stripe Dashboard (test mode), paste its signing secret into the registration, and run Test connection. Make one sandbox payment end to end, then go live with a live key, a live-mode webhook and Test mode off.
4. If Front Door fronts the portal, its firewall must allow the provider's posts to the notify URL.

Payment details are entered with the payment provider, never in AccessPoint. See Payment providers and online fee payments.

Step 2: Install the AccessPoint apps

Install the SharePoint solution first, then the Teams app.

SharePoint solution

Install from your browser (recommended for a new installation). There is no package to download or upload. Open the sharePointPackageInstallUrl link from the deployment's Outputs (the Finish Setup results page links to the same page):

1. The page shows the AccessPoint version it will install, the package's checksum and the fingerprint of the key Realizer signed it with — it has already checked that signature. Confirm the SharePoint address is yours.
2. Choose Sign in to Microsoft 365 as a SharePoint Administrator or Global Administrator. The first time, Microsoft asks you to approve the AccessPoint Installer app. Its one permission is delegated: it acts only while you are on the page and only with your own SharePoint rights.
3. The page reads your tenant app catalog and shows what is installed now and what will happen. Nothing has changed yet.
4. Choose Install AccessPoint. Your browser downloads the package, checks the signature again, uploads it to the app catalog, waits until SharePoint reads it as AccessPoint at that version, deploys it to all sites and confirms.
5. Then approve the pending permission requests (Step 3), install the Teams app, and optionally delete the AccessPoint Installer app under Microsoft Entra ID > Enterprise applications. Later updates do not need it.

Your Microsoft sign-in stays in your browser tab; it is never sent to Realizer or to your AccessPoint deployment. The page will not replace a newer AccessPoint that is already installed, will not install anything whose signature does not check out, and cannot create a missing app catalog (it tells you how). It covers commercial Microsoft 365 only — sovereign clouds use the script or a manual upload. For a split-tenant deployment the link names your Microsoft 365 tenant.

Other ways. Click Get it now on the AppSource listing and approve it into your app catalog; run Deploy-AccessPoint.ps1 -SkipInfrastructure -SkipGraphPermissions -DeploySharePointApp; or upload manually (SharePoint Admin Center > More features > Apps > Upload, check "Make this solution available to all sites").

Teams app

From the AppSource listing, click Get it now and approve it in Teams Admin Center, or install it with the script (the signed-in user needs SharePoint admin plus Teams admin or Global admin):

.\Deploy-AccessPoint.ps1 `
    -SharePointSiteUrl "https://contoso.sharepoint.com/sites/accesspoint" `
    -SkipInfrastructure -SkipGraphPermissions `
    -DeployTeamsApp

Do NOT use SharePoint "Sync to Teams". It silently overrides the manifest's webApplicationInfo.id, which breaks Teams activity feed notifications. Upload the Teams app directly to Teams Admin Center.

Verify: the solution appears in the app catalog without errors, and AccessPoint shows as Allowed under Teams Admin Center > Manage apps.

Connector packages (optional)

If you use repository connectors, the connector framework is published beside the app packages in the connectors/ folder of every release path. The connector version is the API version, so an API upgrade is the cue to redeploy connectors from the same path. The folder holds:

• the connector protocol and SDK packages, for building your own connector in .NET;
• the publisher's ready-to-run connectors for network file shares, Hyland OnBase, OpenText Content Server (GCdocs), Laserfiche and Axon Evidence — each a package you deploy to an Azure App Service or Azure Functions app, or run as a Windows service next to a source the cloud cannot reach;
• a command-line tool that runs the protocol self-test against any connector before you register it;
• a checksum for every package, and the protocol specification and a guide for each connector.

Connectors are covered by the flat-rate license; there is no per-connector fee. Deploy a connector where it can see its source, then register it under Settings > Connectors > Add > Remote and run Test connection. Nothing in the template creates the "AccessPoint Connectors" app registration that a remote connector validates tokens against: an administrator registers it in Entra and enters its Application ID URI as the tenant default audience.

Step 3: Approve API permissions

The SPFx package requests delegated permissions that a SharePoint admin must approve. In the SharePoint Admin Center, go to Advanced > API access and approve each pending AccessPoint request: access_as_user on the AccessPoint API, plus Graph scopes for the people and group pickers and the Add-from-Microsoft-365 capture sources — User.Read.All, GroupMember.Read.All (the group picker behind group-based roles), Sites.Read.All, Files.Read.All, Mail.Read and Mail.Read.Shared (own and shared/intake mailboxes), Calendars.Read and Calendars.Read.Shared, Chat.Read, ChannelMessage.Read.All, Team.ReadBasic.All, Channel.ReadBasic.All (Teams chats and channels), Notes.Read and Notes.Read.All (OneNote), and OnlineMeetingRecording.Read.All, OnlineMeetingTranscript.Read.All, and OnlineMeetings.Read (recordings and transcripts of Teams meetings the user organized). The .Shared scopes never broaden access on their own — Graph still enforces each user's existing Exchange mailbox permissions.

Or approve via PnP PowerShell:

Connect-PnPOnline -Url "https://contoso-admin.sharepoint.com" -Interactive

$spfxPermissions = @(
    @{ Resource = "ed19c96c-a7c5-4dca-8b47-0899c406329f"; Scope = "access_as_user" }
    @{ Resource = "Microsoft Graph"; Scope = "User.Read.All" }
    @{ Resource = "Microsoft Graph"; Scope = "GroupMember.Read.All" }
    @{ Resource = "Microsoft Graph"; Scope = "Sites.Read.All" }
    @{ Resource = "Microsoft Graph"; Scope = "Files.Read.All" }
    @{ Resource = "Microsoft Graph"; Scope = "Mail.Read" }
    @{ Resource = "Microsoft Graph"; Scope = "Mail.Read.Shared" }
    @{ Resource = "Microsoft Graph"; Scope = "Calendars.Read" }
    @{ Resource = "Microsoft Graph"; Scope = "Calendars.Read.Shared" }
    @{ Resource = "Microsoft Graph"; Scope = "Chat.Read" }
    @{ Resource = "Microsoft Graph"; Scope = "ChannelMessage.Read.All" }
    @{ Resource = "Microsoft Graph"; Scope = "Team.ReadBasic.All" }
    @{ Resource = "Microsoft Graph"; Scope = "Channel.ReadBasic.All" }
    @{ Resource = "Microsoft Graph"; Scope = "Notes.Read" }
    @{ Resource = "Microsoft Graph"; Scope = "Notes.Read.All" }
    @{ Resource = "Microsoft Graph"; Scope = "OnlineMeetingRecording.Read.All" }
    @{ Resource = "Microsoft Graph"; Scope = "OnlineMeetingTranscript.Read.All" }
    @{ Resource = "Microsoft Graph"; Scope = "OnlineMeetings.Read" }
)
foreach ($perm in $spfxPermissions) {
    Grant-PnPTenantServicePrincipalPermission -Scope $perm.Scope -Resource $perm.Resource
}

Finally, a Global Administrator grants admin consent for the publisher's multi-tenant app by opening https://login.microsoftonline.com/common/adminconsent?client_id=ed19c96c-a7c5-4dca-8b47-0899c406329f in a browser.

Verify: the API access page shows no pending AccessPoint requests. Settings > Setup also lists any Microsoft 365 permissions still waiting for approval, with the feature that does not work until each is approved.

Graph permissions for the API (Finish Setup)

Separately from the web part's permissions above, the API's managed identity holds these Microsoft Graph application permissions, granted by the Finish Setup page:

What if you decline a permission?

User.Read.All and GroupMember.Read.All sit under one opt-out (the Finish Setup checkbox, or Deploy-AccessPoint.ps1 -DisableDirectoryReconciliation). If your tenant declines them, AccessPoint keeps working, with these limits:

• Only deleted accounts are detected overnight. A disabled account surfaces only when an administrator runs the in-app directory check.
• Roles cannot be bound to Entra groups. Roles are assigned to people directly instead.
• The people pickers fall back to the web part's own delegated scopes.

Group-based roles fail closed: if the group membership check cannot run, group membership grants nothing. An installation that ran Finish Setup before September 2026 holds User.Read.All only; revisit Finish Setup once more to add GroupMember.Read.All, which the group check requires (it also needs User.ReadBasic.All; User.Read.All alone is not enough). You can revoke either app role in Entra ID at any time.

Teams meeting transcripts need one more tenant switch. Microsoft blocks Graph access to meeting transcripts per tenant by default. In Teams admin center > Meetings > Meeting settings, turn Transcript API access (Microsoft Graph access) On and include speaker attribution, or run Set-CsTeamsMeetingConfiguration -Identity Global -EnableGraphTranscriptAccess $true -EnableAttributedTranscripts $true. Recordings are unaffected.

Step 4: Use AccessPoint in SharePoint or Teams

SharePoint: edit or create a page, click +, search for AccessPoint, add the web part, and publish.

Teams: users find AccessPoint under Apps > Built for your org (search indexing can take 15 minutes to several hours after first install). Optionally pin it for everyone via Teams Admin Center > App setup policies by adding AccessPoint to Installed apps and Pinned apps.

Step 5: API URL configuration (usually automatic)

The web part discovers the API URL automatically. The AccessPoint API self-registers its address with the Realizer platform when it validates its license — within minutes of the App Service starting — and the web part fetches it from there. In most deployments there is nothing to do here.

Verify: reload the web part — the dashboard loads instead of the setup prompt. If the API was just deployed, discovery succeeds on the next page load after the first successful license validation.

Setting the API URL manually (optional)

You only need this to override discovery — for example, to pin the web part to a custom domain.

Option A — Setup panel. Open the web part, go to Settings > Setup, enter the API URL (the App Service URL from Step 1, e.g., https://app-accesspoint-contoso.azurewebsites.net), and click Save. The panel validates HTTPS before saving, and a manual URL takes precedence over discovery.

Option B — storage entity (PowerShell). Pin the URL in an AccessPoint_ApiUrl storage entity, which takes precedence over discovery. Since January 2026, SharePoint blocks property-bag writes on the no-script app catalog (message center MC1186368), so a SharePoint administrator must allow them once, tenant-wide, before the storage entity can be written:

# One-time (SharePoint admin): allow property-bag updates on no-script sites
Set-SPOTenant -AllowWebPropertyBagUpdateWhenDenyAddAndCustomizePagesIsEnabled $true

Connect-PnPOnline -Url "https://contoso.sharepoint.com" -Interactive
$appCatalogUrl = Get-PnPTenantAppCatalogUrl
Connect-PnPOnline -Url $appCatalogUrl -Interactive   # storage entities live on the App Catalog site

Set-PnPStorageEntity -Key "AccessPoint_ApiUrl" -Value $apiUrl -Description "AccessPoint API base URL"
Get-PnPStorageEntity -Key "AccessPoint_ApiUrl"       # verify

Step 6: Import a jurisdiction pack

Go to Settings > Jurisdiction packs, pick the pack for your jurisdiction (Canada ATIA, US FOIA, EU GDPR, and others), and click Import. The pack is a starting point built from public information about the legislation, not legal advice — your legal counsel validates and adjusts it. It creates request types, extension reasons, choice fields, notification templates, and translations. Review and customize the imported items afterwards.

Step 7: Assign user roles

The first user to open AccessPoint is automatically granted the Administrator role — the only built-in role, which always resolves to every permission. Every other role is tenant-defined: importing a jurisdiction pack seeds ready-made roles (such as Request Coordinator, the de-facto access-and-privacy-officer role), and you can rename or reshape them under Settings > Roles & Permissions. Roles can be bound to Entra groups when the directory permissions above are granted. Go to Settings > Manage Users, click Add User, search your directory, and assign at least one Administrator and one coordinator; Custodian, Contributor, Reviewer, and Reader access follows automatically from the work you assign people.

AccessPoint is now ready for use.

Updating AccessPoint

AccessPoint tells you when a newer version is available — there is nothing to subscribe to or poll manually:

• During routine license validation, the Realizer Platform reports the latest published AccessPoint version. No usage or case data is involved in this check.
• When the published version is newer than the one your API is running, administrators see an Update available notice on the dashboard and in Setup, showing the current and latest version numbers. When you are current, Setup shows "Your AccessPoint API is up to date."
• The same places flag a newer SharePoint package, and, more urgently, a web part that is older than the API it talks to (features added since are hidden until the package is updated).

To apply an update:

1. In Settings > Setup, click Deploy update to Azure. This opens the Azure portal with the latest template and form. Re-enter the parameters you deployed with; the portal does not remember them.
2. Choose the Upgrade existing installation type. This preserves operator-added application settings and leaves database access untouched. The database schema upgrades automatically on API startup. Leave the version at latest, or pin the version the update notice names.
3. Update the SharePoint package (next section) and, if a new accesspoint-teams.zip was released, the Teams app in Teams Admin Center.
4. Revisit the Finish Setup page after upgrading — it grants any Graph permissions introduced since your original deployment.
5. If you mirror the media worker, document worker or accessibility checker image into your own registry, import the new version's tag before or with the upgrade; the tag follows the API version.
6. If you put the documents storage account under your own key, confirm afterwards that it still is. From 2.5.0 an upgrade keeps it.

Upgrade mode carries operator-added application settings across the redeploy — for example RateLimiting__RequestsPerMinute (the per-user API request budget, default 1,200 per minute) or a custom License__RealizerApiUrl. Template-managed settings are re-asserted to template values.

Updating the SharePoint package from Setup

The SharePoint package lives in your tenant app catalog, and updating it there updates every site at once. When it is behind, an AccessPoint administrator whose Microsoft 365 account may add files to the tenant app catalog sees Update now in Settings > Setup.

1. Choose Update now. Your API downloads the package for that version from Realizer and verifies it before anything else happens: the signature over the release's checksum list, the package's checksum, the signature over the package itself, and that it is AccessPoint at the version you asked for. The signing key is built into the API, never taken from the download site. A package that fails any check is refused with the reason.
2. A confirmation says what will happen — the package in your app catalog is replaced and deployed to all sites — and lists any new Microsoft 365 permissions with what each one enables.
3. Confirm. Your browser uploads the verified package and deploys it with your own SharePoint permissions; AccessPoint gains none.
4. When it reports Updated to the new version, choose Reload the page. Other users get it on their next refresh.
5. If the version declares new permissions, a SharePoint or Global administrator approves them under SharePoint admin center > Advanced > API access.

Every update is written to the AccessPoint audit trail. If you cannot write to the app catalog, Ask your SharePoint administrator opens a ready-made message with both ways to update. Reinstall a previous version (under Advanced) installs an older published version through the same verified path. A package acquired from the SharePoint Store is updated through Upgrade Store App in the classic app catalog, or replaced by Update now. If a permission request was rejected or deleted, an administrator can choose Re-submit the permission requests to deploy the same version again and make the requests reappear.

Sample data for evaluation tenants. For demo and evaluation environments, a separate AccessPoint DevTools web part (accesspoint-devtools.sppkg) can reset a tenant and seed jurisdiction-appropriate sample data with a one-click Rebuild demo. Not for production: the destructive reset endpoints only activate when the App Service setting DevTools:Enabled=true is set — deploy the package to dev/demo tenants only. For hands-on practice with fictional data in a live tenant, use train mode instead.

Signed releases and how to verify a download

Every release folder on get.realizer.io is published with a SHA256SUMS manifest, a detached signature for every file, the publisher's public key (cosign.pub), and an sbom/ folder of software bills of materials (CycloneDX inventories of every component in the release, for your own vulnerability tooling). A version folder is written once, when that version is promoted, and never changes afterwards.

With cosign 2.x installed, verify the manifest and then the files:

cosign verify-blob --key cosign.pub --signature SHA256SUMS.sig --insecure-ignore-tlog=true SHA256SUMS
sha256sum -c SHA256SUMS

Deploy-AccessPoint.ps1 does this for you for the API and portal packages, the template, the SharePoint package and the Teams package, and stops on any mismatch. For the strict mode add -RequireSignedArtifacts -PublisherKeyFingerprint <value>: the script then refuses a release that is not signed, or is signed by any key other than the one whose fingerprint Realizer publishes separately, and installs the exact package files it verified. Never take the fingerprint from the same folder as cosign.pub. The SharePoint install page and Update now check the same signatures in the background.

Teams notification data privacy (optional)

All request records, requestor PII, documents, and audit history live only in your own tenant. Notifications honour that too. AccessPoint delivers every notification on up to three channels, and two of them never leave your tenant: the in-app feed (served from your own API) and e-mail/Outlook (sent from your own shared mailbox via Mail.Send). The Teams activity feed is the only channel that, in its default mode, posts a small payload to the Realizer Platform API — which exists only because Microsoft Graph requires an activity notification to be sent by the app that owns the Teams manifest. The publisher stores none of it and logs only the recipient and tenant identifiers, and the same notifications still arrive by e-mail and in-app. Two controls tighten or remove even this:

Minimise (a toggle). In Settings > Setup > Teams Notifications, turn on Minimise Teams notification content (privacy). The relayed payload then replaces the notification title and preview text and the acting user's name with neutral placeholders; only the activity type, request number, and record identifiers still transit so the toast can route and deep-link. The full text still shows in the in-app feed. No manifest change is required.

Eliminate (self-host the relay). A tenant that must send no notification data to the publisher can have its own API call Graph directly with its managed identity:

1. Grant TeamsActivity.Send (application) to the API's managed identity and admin-consent it. Graph only lets the app that owns the Teams manifest send activity notifications, so the sending identity must match the manifest's webApplicationInfo.id.
2. Point the Teams manifest at your own app. In manifest.json set webApplicationInfo.id to your API's managed-identity client ID, leaving webApplicationInfo.resource as the SharePoint site domain. Upload the edited zip directly in Teams Admin Center — do not use SharePoint "Sync to Teams".
3. Switch the API to Direct relay — add the App Service setting Notifications__TeamsRelayMode=Direct (default/unset = Publisher) and restart.
4. Re-validate — send a test notification (confirm it deep-links) and confirm the Teams personal tab still signs in.

Direct relay keeps all notification content in-tenant but means maintaining a customized Teams manifest and re-consenting when the app id changes. Most tenants that only need to suppress free text and personal names should use the Minimise toggle instead.

Multi-tenant and split-tenant deployments

Use these patterns when the Azure backend lives in a different Entra ID tenant than your Microsoft 365 tenant — a shared services team serving several business units, an MSP hosting for clients, or split Azure and Microsoft 365 tenants kept apart for governance.

Split tenant: keyless sign-in to Microsoft 365

Deploy with the Microsoft 365 tenant ID set (Deploy to Azure form: Advanced > Microsoft 365 tenant; script: -Microsoft365TenantId <guid>; template: microsoft365TenantId). The App Service's managed identity lives in the subscription's tenant and cannot call Graph in your Microsoft 365 tenant, so from 2.5.0 the template attaches a second, user-assigned managed identity, and the API signs in to Microsoft 365 as a multitenant app registration that trusts that identity through a federated credential. No client secret exists and no license key is needed. The same app calls Graph, activates the license, downloads jurisdiction packs and relays Teams notifications.

1. Deploy with the Microsoft 365 tenant ID. The outputs include splitTenant, microsoft365IdentityName, microsoft365FederatedCredential (the issuer, subject and audience the app registration must trust) and sharePointPackageInstallUrl for your Microsoft 365 tenant. finishSetupUrl is empty for a split tenant.
2. In the subscription's tenant, register a multitenant app (for example, AccessPoint Microsoft 365 connection) with a Web redirect URI of https://<api-host>/api/health, and add a federated credential of the scenario Managed Identity pointing at the user-assigned identity, with audience api://AzureADTokenExchange. Do not create a client secret. Deploy-AccessPoint.ps1 -Microsoft365TenantId <guid> can do this registration for you.
3. Point the API at the app: set Graph__ClientId (and leave Graph__TenantId to default to your Microsoft 365 tenant), then restart.
4. A Global Administrator of the Microsoft 365 tenant opens https://login.microsoftonline.com/<m365-tenant-id>/adminconsent?client_id=<client-id> and accepts. Then, in AccessPoint, open Settings > Setup and follow Finish Setup (its link names your Microsoft 365 tenant); the page shows the application ID, which you confirm against Graph__ClientId before granting. Restart the App Service.

The app holds the same Graph permissions listed above plus License.Validate on the Realizer Platform app. Installations set up before 2.5.0 with a client secret and a license key keep working unchanged; you can retire both when convenient (the secret still takes precedence while set).

Shared mailbox and application access policy. Create an unlicensed shared mailbox in the Microsoft 365 tenant for e-mail notifications, and scope Mail.Send so the app can only send from that mailbox:

Connect-ExchangeOnline -Organization "contoso.onmicrosoft.com"

New-Mailbox -Name "AccessPoint Notifications" -Alias "accesspoint-noreply" -Shared

New-DistributionGroup -Name "AccessPoint Mail Senders" -Type Security -ManagedBy "admin@contoso.com"
Add-DistributionGroupMember -Identity "AccessPoint Mail Senders" -Member "accesspoint-noreply@contoso.com"

New-ApplicationAccessPolicy -AppId $appId -PolicyScopeGroupId "AccessPoint Mail Senders" `
    -AccessRight RestrictAccess -Description "AccessPoint may send only from the shared mailbox"

# Verify (propagation can take up to 30 minutes)
Test-ApplicationAccessPolicy -AppId $appId -Identity "accesspoint-noreply@contoso.com"   # expect: Granted
Test-ApplicationAccessPolicy -AppId $appId -Identity "someother@contoso.com"             # expect: Denied

Teams activity feed notifications additionally require admin consent for the Realizer enterprise application and the Teams app installed for users; see Initial Setup.

Serving several Microsoft 365 tenants from one deployment

A shared-services deployment (2.5.0) is one set of Azure resources and one database serving several Microsoft 365 tenants — for example a shared services team serving the departments of a government, each in its own tenant. Each tenant's data stays apart exactly as every tenant's always does: every record carries its tenant, and every query and file path is scoped to it. Each tenant has its own users, roles, settings, jurisdiction packs, cases, documents, training copy and license, so each needs its own AccessPoint subscription. A deployment that serves one organization behaves exactly as before.

To add a tenant:

1. List it. Deploy as Upgrade existing installation with microsoft365AdditionalTenants set to the additional tenant IDs, comma-separated (script: -Microsoft365AdditionalTenants). The list is an App Service setting that only your Azure operator can change; no AccessPoint administrator of any tenant can add one. Your own tenant is always served. The deployment must sign in through the federated app registration described above (a same-tenant installation adopts it with the same steps, and consents it in its own tenant too).
2. The new tenant's Global Administrator consents the app with the admin consent link above, using the new tenant's ID.
3. Finish Setup in that tenant, if the consent did not grant everything (for example License.Validate).
4. Install AccessPoint in the tenant: the SharePoint package from the install page (it takes the new tenant's ID), the API access approvals and the Teams app, as for any customer. The web part finds the shared deployment's API by itself.
5. Configure the tenant. Its first user to sign in becomes its Administrator, and it imports its own baseline pack. Its administrator sets the notification mailbox, which must be a shared mailbox in that tenant's own directory.

Until a tenant is ready — its administrator has not consented, or its license is missing or expired past the grace period — its users get a 402 response and nothing is written for them; Settings > Setup > System health names each served tenant whose license or Microsoft 365 connection is not working. A Microsoft 365 feature that fails for one tenant fails for that tenant alone and never falls back to another tenant's connection. The compute, database, storage, workers, AI and portal are shared by every tenant, so size them for all of them. To remove a tenant, take it out of the list; its users are refused and its data stays untouched until you remove it.

Troubleshooting

The web part shows "Token request previously failed". This is SharePoint Framework's cached token failure: the web part's first attempt to get an access token failed, and SPFx re-throws the message for the rest of the browser session without retrying — so it keeps appearing after the cause is fixed until the page session is fully refreshed. Almost always seen on a new tenant whose pending API access requests have not been approved. Fix, in order: (1) in SharePoint Admin Center → Advanced → API access, approve every pending request from the AccessPoint package — the critical one is the AccessPoint / Realizer API access_as_user scope, without which every call fails. (2) If approval succeeds but tokens still fail, check Entra admin center → Enterprise applications for the app and any Conditional Access policy blocking it, and confirm a Global or Application administrator did the approval. (3) Fully refresh the browser — close the tab and open the page again, or sign out and back in; a soft navigation is not enough. The same message appears when third-party cookies are blocked in a private window, because the hidden token iframe fails — retry in a normal window before deeper diagnosis.

The "AccessPoint X is available (you're on Y)" banner persists after deploying the update. The running App Service may keep the old package mounted until the site recycles. Restart the App Service (portal → App Service → Restart): the new build mounts on start, validates its license, and the banner clears on the next page load.

Uploads stay on "Scanning for malware…". Defender for Storage needs the Microsoft.EventGrid provider registered on the subscription. Register it once (az provider register -n Microsoft.EventGrid) and redeploy.

Office files, e-mail or generated letters will not convert to PDF. Check that the document worker was deployed (it is on by default) and that its Container App is running.

Redeploying the template fails with RoleAssignmentExists. Azure allows one role assignment per principal, role, and scope. The template's own grants are deterministically named and idempotent, so this error means the same grant was also created outside the template — typically by hand in the portal or with az role assignment create. Delete the manually created assignment named in the error, then redeploy; the template recreates the identical grant under its managed name, so no access is lost:

# The error's ID is the assignment name
az role assignment list --all --query "[?name=='<id-from-error>']"
az role assignment delete --ids <full-assignment-resource-id>

Rollback and operations

Standard Azure mechanisms cover rollback: redeploy a previous API package from the App Service Deployment Center history, restore Azure SQL with point-in-time restore, and reinstall a previous version of the SharePoint package from Settings > Setup or by uploading a previous versioned .sppkg to the app catalog. Jurisdiction pack imports are additive and are reverted via database restore. See Disaster Recovery for backup, restore and rebuild procedures. For the full operational runbook — detailed rollback procedures, monitoring, and maintenance tasks — contact our support team.

Related Pages

• Initial Setup — the Setup screen: API URL, notifications, update notices and Finish Setup.
• Public Portal — configure the public intake portal after it is deployed.
• Payment Providers — register Stripe, Paymentus or a hosted page.
• Connectors — register connectors to records systems outside Microsoft 365.
• Disaster Recovery — backup, restore and rebuild.
• Security Controls — the security controls AccessPoint applies.