How Open WebUI users attach OneDrive and SharePoint files in chat
Users attach OneDrive for Business and SharePoint files to Open WebUI chats through a company-wide integration, which is built from a Microsoft Entra ID app registration and a set of Open WebUI environment variables. Once it is configured, a signed-in user can pick documents from Microsoft 365 in the chat interface and send them to the model without downloading and re-uploading copies. This is a shared, administrator-controlled setup. It is not the personal OneDrive option, where each user connects their own account, and the two should be scoped and approved separately.
The administrator work starts in the Microsoft Entra admin center, where the app registration defines the tenant, redirect address, client secret or certificate, and the Microsoft Graph permissions the application will request. Each permission determines what file content the application can read on behalf of users, so the set should be the narrowest one that supports the chat workflow. Decide early whether users will see only their own OneDrive content, specific SharePoint sites, or both, because that decision changes the permission type and whether admin consent is needed. Confirm these choices with your Microsoft 365 administrator and your identity team before anyone edits the Open WebUI configuration.
The Open WebUI side is a set of environment variables that point the server at your tenant, the application, and the file sources it may offer. Exact variable names, accepted values, scope strings, and consent steps change between releases and between Microsoft identity documentation updates. Take them from the current Open WebUI documentation for the version you run, and from Microsoft's identity documentation at build time, not from this page. Pin the Open WebUI version you tested against, because the integration behavior and the required settings may differ between releases.
Plan for the risks before rollout. Users will expect the same access they have in Microsoft 365, so test with accounts that hold different site permissions and confirm that a user cannot attach a file they could not open in SharePoint. Check how the client secret is stored and rotated, and where tokens live when Open WebUI runs with more than one replica. Ask your provider to document the consent flow, the test accounts used, and the expected behavior for expired or revoked access. Those checks belong in the acceptance criteria, not in a later review.
What you need in place before configuring the connection
Each item below is a dependency for the connection, and most of them sit with a different team. Confirm them in this order before anyone edits configuration, because a missing admin consent or a mismatched address will block sign-in even when the environment variables are correct.
A release that documents the connector
Open WebUI must run a release whose documentation covers the OneDrive and SharePoint connection. Check the Open WebUI release notes on the project's GitHub releases page to find the version that introduced this connector, then compare it with the version your team runs. The latest published release at the time of writing was v0.12.3, published October 16, 2026, but confirm the connector's first supported version separately before planning an upgrade. The platform owner usually holds this check.
Entra ID rights to register and consent
Someone with rights to register applications in Microsoft Entra ID must create the app that Open WebUI uses to request file access. A tenant administrator, or a delegate with a suitable directory role, must then grant admin consent for the Microsoft Graph permissions the connector requests. Confirm this early, because consent requests often wait in approval queues. The identity team usually owns this step, and the platform owner should agree the permission scope in writing.
Microsoft 365 licensing for target users
Every user who attaches files needs OneDrive for Business and SharePoint access through a Microsoft 365 license, and their account must belong to the same tenant as the Entra app. List the user groups that need the feature and check their license assignments. File access follows each user's existing SharePoint and OneDrive permissions, so confirm with the vendor documentation how the connector handles shared libraries before you promise access to any team. The Microsoft 365 administrator usually owns this check.
HTTPS public URL matching the redirect URI
Open WebUI must be reachable at an HTTPS address that both users and Microsoft sign-in can reach. The redirect URI registered on the Entra app must match that address exactly, including scheme, host, port and path. Choose the public hostname before registration, because changing it later means editing the app registration and retesting sign-in. The network or platform team usually owns the DNS record, reverse proxy and certificate.
Named owner for the app and secret
The Entra app authenticates with a client secret or certificate that expires, so someone must track its expiry date, rotation and storage location. Name one primary owner, usually from the identity team, plus a backup who can act during an absence. Record where the credential is stored and who can read it. Without a named owner, sign-in failures tend to appear only after the credential lapses. Confirm the owner in writing before configuration starts.
Which Microsoft file source fits which group of users
The first decision is whose files the chat should be able to read, because that determines which Microsoft source fits. SharePoint document libraries belong to a team site, so access follows site membership and groups, and the content stays with the team when individuals change roles or leave. OneDrive for Business belongs to one employee, so that person's own sign-in and sharing choices shape what Open WebUI can reach. The separate personal OneDrive option works per user, with each person connecting their own drive instead of a tenant-wide source. Match the source to the group that owns the content and to the person who will answer for it.
Consent is where the three options diverge most. For SharePoint and OneDrive for Business, the Entra ID app registration and its requested permissions decide who must approve access. Confirm whether the permissions your Open WebUI release needs can be granted by individual users or must be approved by a tenant administrator for the whole organization. A tenant-wide grant lets the application act on behalf of users across many sites and drives, which is a larger governance decision than individual consent. Personal OneDrive connections move consent to each employee, which reduces central control but makes it harder to prove who approved what. Record the approver for each source before any pilot starts.
Visibility and audit need separate checks for each source. A SharePoint library should show users only what they already can open in SharePoint, so confirm that site permissions and any sensitivity labels are respected through the integration and not bypassed. OneDrive for Business content depends on each owner's sharing links and folder choices, so offboarding must include reviewing or transferring those files. For audit, Microsoft 365 logs record file access and sharing activity for both SharePoint and OneDrive. Ask whether requests made from Open WebUI appear under the signed-in user's identity, under a service identity, or both, and check that your retention settings keep those records long enough for your review cycle.
Before rollout, check the Open WebUI documentation for the release you run, because supported file sources and their settings change between versions. Then map each user group to one source and name an owner for each connection. Organizations with mixed needs often end up with two or three connection types, each with its own consent path and audit trail, so plan for that rather than assuming one source covers everyone. Ask your implementation partner for a written list of permissions, consent steps and audit fields for each source, and confirm that list against your own tenant before any user is enabled.
Configuration sequence for OneDrive and SharePoint in Open WebUI
This sequence takes an Open WebUI instance from a standard install to one where a pilot group can attach files from OneDrive for Business and SharePoint in chat. Each step closes with a check, so a failed step is found before the next one starts. Confirm every setting name and value against the connector documentation for your release, because this page does not repeat them.
Confirm the supported release and connector documentation
Before changing anything, the platform owner checks which Open WebUI release the instance runs and reads the OneDrive and SharePoint connector documentation for that exact release on the project's documentation site. Record the version, the documented prerequisites and the license terms that apply to that version, since releases from v0.6.6 onward use the Open WebUI License. Done when the version and the documentation page you will follow are written into the change ticket. If the documentation for your release does not describe this connector, stop and confirm the approach with the project or your vendor before continuing.
Register the application in Entra ID
An Entra ID administrator creates an app registration for Open WebUI in the tenant that holds the OneDrive and SharePoint content. Set the redirect URI exactly as the connector documentation specifies, including scheme, host, port and path, because any difference from the URI Open WebUI sends will block sign-in. Add the Microsoft Graph permissions the documentation lists, choose the delegated or application permission type it requires, and record whether administrator consent is needed. Done when the registration shows the expected redirect URI, the permission list matches the documentation, and an administrator has granted consent.
Store the client secret outside the repository
Create a client secret for the app registration and record its expiry date in your certificate or secret tracker. Place the value in your secrets manager or the platform's secret store, never in a Compose file, Helm values file or Git repository, and limit read access to the people and service accounts that deploy Open WebUI. Confirm the rotation process before go-live, because sign-in through this connector will stop working when the secret expires. Done when the deployment pipeline can retrieve the secret and a search of the repository for the value returns no results.
Set the environment variables the docs list
Using the variable names and value formats from the connector documentation for your release, set the Entra tenant, client and secret references, plus any scope or feature flags the connector requires. Pass the secret through your secret mechanism rather than a plain value in a shared file. Do not carry variable names over from other integrations or older releases. Done when the running container or pod lists the expected variable names in its configuration with values masked, and the startup log shows no error about the connector and no copy of the secret.
Redeploy the instance with the new configuration
Redeploy Open WebUI so the new variables load, using the same method your team uses for routine releases, whether Docker Compose, Helm or pip. If the instance runs several replicas, the scaling guide requires Redis for shared sessions, websocket connections and application state, and PostgreSQL instead of SQLite, so confirm both are in place before a rolling restart. Plan for users to sign in again after the restart. Done when every instance reports healthy and the logs show the connector initialized without errors.
Enable the feature for a test group
In the admin settings, turn on the OneDrive and SharePoint option for a single pilot group. If your release lets you scope the feature by group or role, use that control so only pilot users see it; if it does not, confirm with the documentation how to limit exposure before enabling it. Keep the feature off for everyone else until verification passes. Done when the pilot group shows the feature enabled in the admin view and a user outside the group does not see the option in the chat attachment menu.
Verify the path with one named user
Have one named pilot user sign in through Entra ID, start a new chat and open the OneDrive and SharePoint file picker. Check that the picker lists the personal OneDrive for Business and the SharePoint libraries that the test account can access, then attach one small file and ask a question about it. If the documentation treats personal OneDrive as a separate option, test it separately. Done when the file attaches, the model answers from its content, and the sign-in and consent records are saved in the change log.
How identity and file access map between Entra ID and Open WebUI
This table traces each Entra ID value that Open WebUI receives at sign-in and each Microsoft Graph permission used for file listing and attachment to its Open WebUI counterpart. Read each row left to right to see where the value comes from, where it lands, who decides it and what to check in the current Open WebUI SSO and connector documentation before you configure the tenant. The main takeaway is that file access depends on both the Graph consent granted to the app and the signed-in user's own access in OneDrive and SharePoint.
| Item | Microsoft-side source | Open WebUI-side field | Owner and what to confirm |
|---|---|---|---|
| User identity | Identifier and email claims in the Entra ID token for the signed-in user | User record matched or created at OIDC sign-in, using the claim set in Open WebUI's OIDC settings | Owner: identity team. Confirm the exact claim names and which claim Open WebUI uses to match existing local accounts in the current SSO docs. |
| Group membership | Security groups or app roles emitted in the token, or groups provisioned through Entra provisioning | Open WebUI groups used for role-based access control, set by group claim mapping or SCIM 2.0 provisioning | Owner: IAM team with the Open WebUI admin. Confirm whether groups arrive as token values or through SCIM, and how the token handles large group lists in the Entra docs. |
| Tenant identifier | The tid claim and the issuer URL for your Entra tenant | OIDC issuer and client settings that limit sign-in to your tenant | Owner: platform team. Confirm the issuer URL pattern for your tenant and whether guest or other-tenant sign-in must be blocked in Entra. |
| Open WebUI role | App role or group membership that signals administrator or standard user status | Open WebUI role assigned at first sign-in and updated on later sign-ins | Owner: Open WebUI admin with IAM approval. Confirm the default role for new SSO users and whether role sync overwrites roles changed locally. |
| File listing scope | Delegated Microsoft Graph permissions on the app registration for OneDrive and SharePoint reads, with consent status | Connector setting that enables OneDrive and SharePoint listing for signed-in users | Owner: Microsoft 365 admin for consent. Confirm the exact scope names and whether admin consent is required in the current connector docs. |
| File attachment access | The signed-in user's own permission on the chosen file or site, enforced by Graph at request time | Chat-level attachment of retrieved content, subject to Open WebUI per-resource permissions | Owner: content owner and Open WebUI admin. Confirm who can view attached content later in shared chats and whether copied content is stored in Open WebUI. |
| Personal OneDrive versus SharePoint | Separate Graph resources: the user's OneDrive drive and SharePoint sites the user can reach | Separate connector options for personal OneDrive and for SharePoint | Owner: Microsoft 365 admin. Confirm whether personal OneDrive uses its own setting and consent path, and whether enabling it changes the scopes requested. |
| Session lifetime and sign-out | Token lifetime set by Entra and the token Open WebUI holds after sign-in | Open WebUI session tokens, which stay valid until expiry without Redis | Owner: security team. Without Redis, signing out does not revoke tokens, which remain valid until they expire, by default after 4 weeks (Scaling Open WebUI docs). Confirm your token lifetime policy. |
Why file access should follow each user's Microsoft permissions
A user should reach a file through Open WebUI only when their own Microsoft 365 identity can already open that file in OneDrive or SharePoint. That rule makes the access model a decision to settle before rollout, not something to check after the connection is live. When the connection authenticates with a broad application-level permission, the Open WebUI service can read far more content than a chat user needs, and every user who can invoke the connection inherits that reach. Start in the Entra ID app registration and review the API permissions. Delegated permissions act on behalf of the signed-in user, so Microsoft still evaluates each user's access. Application permissions act as the app itself and carry no user context. Confirm which type is granted, whether admin consent was given, and which sites or libraries the granted scope covers.
Test the design with a user who lacks access to a restricted library before any pilot group uses the connection. Choose a library with unique permissions that the test account cannot open in SharePoint, then try to attach a file from it inside an Open WebUI chat. The attempt should fail with an authorization error and return no content. Repeat the check with a user who has access, which confirms the connection works and that the failure comes from permissions. Also check whether the file picker lists the restricted library or its file names, since a hidden entry is not proof of denial. Paste a direct reference to a restricted file as well. Record the account, library, time and result for each test so the evidence can go to your security reviewers.
Open WebUI role-based access control decides who can enable or use the connection, and that decision should be made separately from general chat access. Open WebUI documents role-based access control with groups and per-resource permissions, so grant the feature to a named group and keep it out of the default role. Restrict configuration of the connection to administrators, and check that newly provisioned users do not receive it automatically. If you provision groups from Entra ID through OIDC claims or SCIM 2.0, confirm that a group membership change removes the grant as well as adding it. Review these settings after each Open WebUI upgrade, because role defaults and option names can change between releases. Confirm the exact location and behavior of each control in the documentation for the version you run.
Access that follows identity also needs a plan for what happens after a file is fetched. Once a user attaches a document, its content may be stored, indexed or cached inside Open WebUI, and the retention of those copies determines how long a removed permission still matters. Confirm with the vendor documentation how fetched files are stored, where they sit, whether vector indexes are created and removed when chats are deleted, and how backups handle them. Token lifetime is related. Without Redis, signing out does not revoke tokens, which stay valid until they expire, by default after 4 weeks. Ask your team to decide whether that window is acceptable for users whose group membership changes, and to test the full offboarding path before go-live.
Security settings to decide before rollout
Six settings decide who can bring OneDrive and SharePoint content into Open WebUI and how that access can be shown later. Assign each one a decision owner before users see the connection, and keep the evidence listed on each card with the rollout change record.
Least-privilege Graph permissions
Choose delegated Microsoft Graph permissions so each user reads only the files that user can already open, and avoid application-wide read access unless a documented need exists. Have an approver review every permission and admin consent grant on the Entra ID app registration, and record who approved it and why. Keep the exported permission list and the consent record with the rollout ticket. Confirm the exact scope names against current Microsoft documentation before you request them.
Client secret storage and rotation
The app registration uses a client secret or certificate to request tokens, so where that credential is stored matters as much as its scope. Keep the value in your secrets manager and inject it into the container environment at runtime. Never store it in compose files or images committed to source control. Name one owner for rotation, set the expiry date in your calendar, and keep a record of each rotation date and the person who performed it.
Restricting access to an approved group
Limit the connection to a Microsoft Entra ID group made up of people approved for document access, so the feature is not available to every account that can sign in. Confirm which Open WebUI control enforces this in your configuration, and use SCIM 2.0 provisioning or role-based groups to keep membership current. Test with an account outside the group. Removing a user from the group does not revoke tokens already issued. Without Redis, those tokens stay valid until they expire, by default after 4 weeks. Keep the group ID, its owner and the test result.
HTTPS and the redirect URI
Serve Open WebUI only over HTTPS, and register the redirect URI in the Entra ID app registration exactly as the deployed public address and path, including scheme and port. A mismatch causes sign-in failures, and extra or wildcard redirect URIs widen where authorization responses can be sent. Remove unused entries from the list. Keep the registered URI list, the certificate source and the reviewer's sign-off in the change record.
Audit logging of sign-ins and consent
Entra ID records sign-in activity for the app and records consent grants, which together show who used the connection and who authorized its access. Confirm which log categories your tenant provides, how long they are retained, and whether the team that reviews them can export or query them. Check that the Open WebUI side also logs the authentication events you need. Keep sample exports and the retention setting as evidence.
Data handling for copied files
Files attached from OneDrive or SharePoint are copied into Open WebUI storage, so the copies live in your deployment and outside the source library's permissions and retention controls. Decide where that storage sits, who can read it, and how long copies are kept. Check whether copies are included in backups and in your deletion procedures, and whether deleting the source file changes the copy. Record each decision and the test that confirms a deleted chat file is removed from storage.
Testing the connection before users depend on it
Test the connection with a small pilot group before any wider rollout, and decide in advance what a pass looks like. The pilot needs at least two users: one who has access to the SharePoint document library and OneDrive folder you plan to expose, and one who does not. The second user is the important check. If that person can attach or see content from the library, the problem sits in the Entra ID app registration permissions, the site or folder scope, or the way Open WebUI resolves the signed-in identity, and the rollout should stop there. Record the account, the expected result and the actual result for every test case so the outcome can be reviewed later.
Use test content that you control: a SharePoint library and a OneDrive folder with at least three files. Include one ordinary document, one file restricted to a small group, and one large file close to the upper size you expect users to attach. The restricted file tests whether item-level permissions are enforced, not only folder access. Ask the user with access to attach it and confirm the content reaches the chat. Ask the user without access to attempt the same thing and confirm the attempt fails with a clear error and that no content enters the model context. The large file exercises upload limits and timeouts along the path from Microsoft Graph to the Open WebUI backend. Confirm the size limit in your configuration before the test starts.
Include a sign-out and token-expiry check. After signing out, try to reuse the previous session in another tab and confirm that file access is refused. On a single replica without Redis, sign-out does not revoke tokens, so they stay valid until they expire, by default after 4 weeks. Record the expiry value your deployment actually uses and confirm it with your own settings instead of assuming the default. Then check that the OneDrive connection refreshes correctly for an active user and that a pilot user removed from the group loses file access at their next attempt. Note how long each step takes so the results can be compared across runs.
A single-replica test tells you little about a multi-replica production setup. The Open WebUI scaling guide requires Redis as a shared store for sessions, websocket connections and application state, shared file storage so uploads stay reachable from every replica, and PostgreSQL in place of SQLite. Run the test plan only after those components are in place, or label the results clearly as single-replica. Save the evidence in your change record: the test matrix with user, file, expected and actual results; timestamped logs or screenshots; configuration values with secrets redacted; the app registration permissions and admin consent record; sign-out and expiry observations; and the Open WebUI version under test. Operations and your auditors can then see exactly what was verified and when.
Why OneDrive and SharePoint attachments fail in Open WebUI
This table lists the failures that most often stop users from attaching OneDrive or SharePoint files in Open WebUI, with the likely cause, the first check and the document or setting to confirm. Work through the identity and tenant rows first, because one app registration or licensing problem can cause several symptoms. Most attachment failures trace back to identity settings, tenant licensing or how the deployment stores session and file state.
| Failure | Check first | Confirm in |
|---|---|---|
| Redirect URI mismatch | Compare the redirect URI in the app registration with the exact callback URL Open WebUI sends, including scheme, host, port and path. | Redirect URI list in the Entra ID app registration and the public URL set for your Open WebUI deployment. |
| Missing or unconsented Graph permission | Confirm the Microsoft Graph delegated permissions for file access are added and that admin consent is recorded where your tenant requires it. | API permissions in the Entra ID app registration and your tenant's admin consent policy. |
| Expired or wrongly stored client secret | Check the secret's expiry date, then confirm the secret value, not the secret ID, is what the deployment loads. | Certificates and secrets in the app registration and the environment or secret store that feeds Open WebUI. |
| User without a license or OneDrive | Sign in as the affected user and confirm they hold a Microsoft 365 license that includes OneDrive and that their OneDrive is provisioned. | License assignment for the user in the Microsoft 365 admin center and the user's OneDrive for Business page. |
| Personal OneDrive option enabled when business files were intended | Check which OneDrive option is enabled, since a personal source will not return files stored in your organization's tenant. | The personal OneDrive setting and the business OneDrive and SharePoint settings in this topic's configuration steps. |
| Replica without shared file storage | Upload a file through one replica, then open the chat through another. If the file is missing, uploads are not on storage shared by every replica. | The scaling guide requirement for shared file storage and your volume or object storage mounts for each replica. |
| Sessions valid after sign-out without Redis | Sign out in one browser, then test the old session. Without Redis, tokens stay valid until they expire, by default after 4 weeks. | The scaling guide section on Redis as shared state and the token expiry setting in your deployment. |
Questions buyers ask before hiring help with this integration
What does it cost to connect Open WebUI to OneDrive and SharePoint?
Cost is set by the written scope, because DeployOpen does not publish a price list. The main components are the time to register the Entra ID application, configure environment variables, test attachments from OneDrive and SharePoint, and hand over documentation. Ask the quote to separate one-time work, such as the initial integration and pilot, from recurring work, such as support, upgrades or secret rotation under a retainer. Also confirm what is excluded, including personal OneDrive access, which is a separate option, and any hardening your Open WebUI deployment needs first. Open WebUI licensing is a separate line. If you exceed 50 users in any rolling 30-day period, Open WebUI branding must stay intact unless you hold an enterprise license or written contributor permission. Enterprise licenses are quoted by Open WebUI's enterprise sales team after you share an expected seat count.
How long does a pilot take and what makes it longer?
No single duration fits every tenant, so the written scope sets the timeline. The biggest drivers are how quickly your Microsoft 365 owner and Entra admin can decide and grant access, whether a test group of users is ready, and how many SharePoint sites and libraries users must reach. The starting state also matters. A multi-replica Open WebUI deployment needs Redis and shared file storage before the pilot can rely on it, and a single instance using SQLite is only suitable on locally attached SSD or NVMe storage. An unready platform stalls the pilot before the integration work begins. Ask for milestones with named owners on both sides, and a stated plan for what happens if an access request waits.
What must our internal team provide for the integration?
Four roles need names before work starts: an Entra admin, a Microsoft 365 owner, a test group and a named secret owner. The Entra admin creates the app registration and grants consent under your tenant policy. The Microsoft 365 owner decides which SharePoint sites and OneDrive accounts are in scope and approves how the data is handled. The test group is a small set of users who try attachments before wider rollout. The secret owner holds the client secret or certificate, records its expiry date and handles rotation. If any of these roles is unfilled, the work waits. Confirm each person's time commitment in writing, and name a backup for each role so the pilot does not depend on one person.
Can a capable internal team do this integration without outside help?
Yes, if the team includes people comfortable with Entra ID app registrations, OAuth permissions, Open WebUI environment variables and the platform where Open WebUI runs. The configuration steps are documented, but the judgment calls are the hard part. Your team must decide which permissions to request, how secrets are rotated, how multi-replica state is shared, and how to prove that users reach only the files their Microsoft 365 permissions allow. Build capacity by assigning named owners, writing down the configuration, and running a test group before rollout. Outside help makes more sense when the team has no Entra or Open WebUI experience, or when the deadline cannot absorb a first attempt. Whichever route you choose, ask for the verification steps so your team can repeat them.
What is the difference between a fixed-scope engagement and a retainer?
A fixed-scope engagement agrees on scope, deliverables and timelines in writing before work starts, and it ends when those deliverables are handed over. A retainer covers ongoing work, such as support, upgrades and continuous testing, over an agreed period. For this integration, a fixed-scope engagement fits a defined set of sites, a test group and a handover. A retainer fits continuing needs, such as upgrading Open WebUI between releases, rotating secrets on schedule or adding SharePoint sites later. Both need written scope. Ask which tasks recur, who approves changes, and what response expectations apply, and write each expectation into the agreement so nothing depends on assumptions.
Do we need an Open WebUI enterprise license to run this integration?
The answer depends on your user count and branding needs, and the OneDrive and SharePoint integration does not change it. Under the Open WebUI License, deployments exceeding 50 users in any rolling 30-day period may not alter or remove Open WebUI branding unless the operator holds an enterprise license or written contributor permission. Enterprise licenses allow white-labeling, custom branding and dedicated support options. Pricing is not published. You contact Open WebUI enterprise sales with an expected seat count and receive a quote. DeployOpen's integration quote is separate and follows the written scope. Confirm with Open WebUI which license covers your user count before you plan the rollout.
What usually breaks when OneDrive attachments fail in Open WebUI?
Most failures trace to four areas: an expired or unrotated client secret, admin consent that was never granted for the required permissions, a multi-replica deployment without Redis or shared file storage, and a single-replica database on network storage. Without Redis, signing out does not revoke tokens. They stay valid until they expire, by default after 4 weeks, so a user who has left may keep access longer than your policy allows. Test each path with a test group. Have each tester attach a file from OneDrive, a file from a SharePoint library the account can reach, and a file from a library it cannot reach. Record the secret expiry date in a shared calendar, assign the secret owner, and ask the partner for its verification checklist and the logs it reviews during rollout.
How DeployOpen scopes, delivers and supports this integration
DeployOpen plans, builds and hands over Open WebUI with OneDrive and SharePoint inside infrastructure you control, with the Entra ID app registration, environment configuration and user access decided before any change is made. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts.
How we scope
- The written scope names which OneDrive for Business and SharePoint sites and libraries users may attach files from.
- Scope also decides whether personal OneDrive access is included, since it is set up as a separate option.
- Scope records the Open WebUI version, deployment method and user count, including whether the license branding clause applies.
How we build
- Register the Entra ID application with only the permissions the agreed file access model needs, reviewed with your identity team.
- Set environment variables and secrets through your deployment method, with values kept out of images and version control.
- Test sign-in and file attachment with a pilot group, covering permission denials and sites outside the granted scope.
How we hand over
- Written documentation of the app registration, configuration values, permission rationale and the steps to rotate secrets.
- A test record showing which sign-in, attachment and denial cases were checked, and the outcome of each.
- Runbook notes for a SharePoint site or user who needs access added or removed later.
How we support
- Support can be retained for ongoing upgrades, testing and review of Open WebUI release changes.
- Upgrades are reviewed against the Microsoft Graph permissions and Entra ID settings the integration depends on.
- Confirm with your Microsoft 365 administrators how tenant policies, sharing settings and conditional access apply before go-live.
