Ultimate Forms runs in SharePoint Online as a single modern app: a collection of SPFx components installed from the app catalog, authorized through a Microsoft Entra enterprise application, and available tenant-wide without per-site installation. It integrates into the modern SharePoint interface, communicates through webhooks, and refreshes its own access tokens, so sessions never expire mid-work. This article explains that architecture: what is installed where, how the app is authorized to access your data, and the handful of configuration points administrators should know, especially if your tenant has been running Ultimate Forms since the earlier add-in era.
Understanding the moving parts takes ten minutes and saves the support ticket later.
From add-in to modern app: the short history
Ultimate Forms originally shipped under SharePoint's provider-hosted add-in model, authorized through Access Control Service (ACS), the original mechanism by which add-ins obtained short-lived tokens to access SharePoint data. Microsoft retired that entire stack, disabling ACS completely on April 2, 2026, a change that affected every vendor on the platform, and one we covered in detail in SharePoint Add-ins Retirement: What You Must Do.
Ultimate Forms moved to the modern architecture well ahead of that deadline, with version 1.4.0.0 at the start of 2024. The transition consolidated what used to be two apps into one: the old Infowise Ultimate Forms add-in was retired outright, and the Extensions app, rebuilt on SPFx components, took over its interfaces and its name. If your tenant still shows remnants of the old app, or Ultimate Forms features stopped loading around the retirement date, see Why Ultimate Forms Features May Stop Loading for the fix; tenants that never completed the authorization switch are the most common cause.
The payoff of the modern architecture is practical: the app loads faster, the UI integration is more reliable, and administration got simpler in the ways described next.
One app, installed once
The modern app installs from the app catalog and can be made available to all sites directly from there, so there is no per-site installation to repeat and no per-site version drift to chase. Both tenant and site collection app catalogs are supported; the Installation Wizard detects a site collection catalog if one is present and picks it by default, with no additional configuration.
Installation runs through the wizard (recommended) or via Microsoft Marketplace. To see which method would work best for you, see Installation Wizard vs Microsoft AppSource.
Two details administrators ask about. First, the app can optionally be installed into the Site Contents of a particular site when tenant-wide availability is not desired, but that entry serves installation purposes only; it is not a clickable access point to the app. Second, the SharePoint interface integration, the Design, Print, Add Alert, Run Actions, and Action History buttons, appears in the modern UI only. Classic pages show no buttons, which is one more nudge in the direction the platform has been heading for years.
How the app is authorized: Entra, not ACS
Data access runs through a Microsoft Entra enterprise application named Infowise Ultimate Forms Data Access. An administrator grants this application access once, and it becomes the mechanism through which the app reads and writes SharePoint data, replacing the retired ACS token flow.
Alongside the Entra grant, an app principal should be created for the app within SharePoint. It is required by the components that still rely on Remote Event Receiver (RER) technology, which currently include synchronous Actions and Signatures in classic forms. Remote Event Receivers are planned to be retired by July 1st 2027, by which time Ultimate Forms will completely stop using this technology. Note that synchronous actions will work in modern forms only.
Most Actions and Alerts now communicate through webhooks rather than RER. One behavioral consequence is worth knowing before your auditors find it: field updates performed by actions record their Modified By value as SharePoint App rather than the triggering user. That is the platform's standard behavior for app-performed writes, and processes that relied on reading the triggering user from Modified By should take it from the action's own context instead.
Finally, tokens: the access token granted when the app opens is refreshed automatically by the app itself. A user can keep a form or the designer open indefinitely without the session expiring underneath them, which quietly removed a whole category of "it stopped saving" complaints.
Smaller architectural wins worth knowing
A few changes that arrived with the modern architecture continue to matter day to day.
Custom scripting is no longer required in the majority of cases, and is left disabled by default. The exception is Classic forms: tenants still running them must enable custom scripting, and the Classic form section of the app stays disabled otherwise. If Classic forms are still in your landscape, Upgrading from Classic to Modern SharePoint Forms makes the case for finishing that migration; the architecture is clearly built for the modern side. Note that in October 2028 Microsoft will lock down the ability to enable custom scripting on all Microsoft 365 tenants. We strongly recommend convert all your classic forms until that time. Although the existing classic forms are expected to continue working, you won't be able to create new ones and might not be able to modify the eixsting ones.
Modern forms no longer require Site Pages functionality and do not generate web part pages to run on. Existing forms are untouched until the next time they are published, at which point they adopt the new mechanism automatically.
And custom field types received JSON-based rendering, which means fields render immediately when a view loads instead of waiting for a rendering component to arrive on the page. The switch happens per field, the first time its settings are re-saved (no actual changes required). It is not urgent, the old mechanism remains fully functional, but on lists users open all day, re-saving the field settings is a free performance improvement, and a reasonable item for the next maintenance pass.
What administrators should verify today
The checklist distills to five items.
- Confirm the tenant runs the current app from the app catalog, not a legacy add-in remnant.
- Confirm the Infowise Ultimate Forms Data Access enterprise application has been granted access in Entra, since ACS no longer exists as a fallback.
- Create the app principal if synchronous actions are in use.
- Expect SharePoint App in Modified By for action-performed updates, and adjust any process that assumed otherwise.
- Schedule the re-save of custom field settings to pick up JSON rendering where it helps most.
Tenants that check all five are fully on the modern architecture; anything else deserves a look before it becomes a support call, and our support resources are there when it does.
Frequently asked questions
Add your comment
