How OpenProject connects work packages to OneDrive and SharePoint files
OpenProject connects work packages to OneDrive and SharePoint files by attaching files and folders from Microsoft 365 to a work package, and by creating managed project folders that OpenProject can organize around the project structure. Project teams keep their documents in Microsoft 365 but plan their work in OpenProject, so the link lets a work package point to the right file without copying that file into a second store. The Enterprise plan is required for this integration, so the licensing decision belongs at the start of the project, before any architecture or permissions work begins. Community edition users should not expect to set up this connection.
This section is based on the topic brief. Official connector documentation for OneDrive and SharePoint was not available when this page was prepared. Before you commit, confirm the exact supported connection method, the Microsoft Entra app permissions (scopes) the connector requests, and whether those permissions are delegated to each signed-in user or granted at the application level. Also confirm the OpenProject version that first includes the feature. Check the current OpenProject documentation and the release notes for the version you plan to run, and ask your OpenProject contact to confirm each point in writing.
Two decisions shape the design. The first is whether users attach existing files and folders to work packages, or whether OpenProject creates and manages a project folder for each project. Attaching existing items fits teams with established SharePoint libraries and minimal change. Managed folders give consistent structure and reduce manual setup, but they give OpenProject a role in a Microsoft 365 location that your records or compliance team may already govern. The second decision is who authorizes the connection: one administrator-consented app identity, or each user signing in with their own account. That choice determines what a user can see through a work package, so document it before rollout.
Plan for three risks. Permissions broader than the work requires can expose documents across SharePoint sites. Renamed folders or changed site paths can break links on work packages. A user who loses access in Microsoft 365 may still see a link in OpenProject if the connection does not re-check access on each request. Run a pilot on one project with a test site. Confirm that a user without SharePoint rights cannot open the file from the work package, and record the results before wider rollout. Ask any implementation partner to quote the Entra app setup, the folder mode configuration and the test plan as separate line items so each can be reviewed.
What you need in OpenProject and Microsoft Entra before linking storage
Five prerequisites decide whether storage linking works on the first attempt. They span licensing, the OpenProject version, Microsoft tenant rights, storage ownership and network reachability, and each one may need an owner outside the project team. Confirm every item against the current integration documentation before you schedule the work.
Enterprise subscription and plan
The OneDrive and SharePoint link is documented as an Enterprise feature, so confirm which plan tier includes it before you plan the rollout. Enterprise on-premises plans are licensed per named user, so your user count shapes the quote. Ask OpenProject or DeployOpen to confirm the required tier in writing for the version and deployment type you intend to run.
Supported OpenProject release
Check the minimum OpenProject version for the storage integration in the release notes and the integration documentation. The latest release listed in the release notes at the time of writing is 17.9.2, released October 15, 2026, so plan against a version your upgrade path covers. Record the exact build on the staging host so that upgrade testing matches production.
Entra tenant and app consent
You need a Microsoft Entra tenant where you can register an application, define its API permissions and grant admin consent. A user with the right directory role must approve the permissions the integration requests, which is often not the project team. Confirm the exact permission set in the current integration documentation before requesting consent, so the administrator reviews the correct scope the first time.
SharePoint and OneDrive ownership
Decide where project folders will live: a SharePoint document library per project or program, or OneDrive folders tied to a named account. Settle who owns the site or drive, who manages its membership, and what happens to linked folders when a person leaves. Folder management modes assume a clear owner, so make this decision before any work package is linked to a file.
Outbound HTTPS to Microsoft
The OpenProject host must reach Microsoft sign-in and file service endpoints over outbound HTTPS, which means firewall rules, proxy settings and DNS resolution must allow the traffic. Egress filtering is a common cause of linking failures discovered after deployment. Get the endpoint list from the current integration documentation and test connectivity from the production host, not from a workstation.
Choosing a folder management mode for each project
The first decision is who creates project folders in SharePoint. In one mode, OpenProject can create and manage a folder for each project automatically, so the integration decides where the folder sits and what it is called. In the other, the team links folders that already exist, and the integration attaches files and work packages to them without generating structure. Confirm the exact mode names and their behavior in the current OpenProject documentation before you design around them, since option sets and defaults can change between releases. Treat this as a structural choice, because changing modes after files exist usually means reconciling folders by hand.
Ownership follows permissions. Automatic management needs an Entra app registration with rights to create and manage folders in the target SharePoint sites, and those rights set what the integration can change. Manual linking needs narrower access, mainly to the folders people choose to link, but the team still has to confirm that each linked folder grants the right people access. SharePoint access is governed by site and library permissions and by any sharing links already in use, so OpenProject project membership does not replace them. Ask your Microsoft 365 administrator which permission scopes the app receives in each mode, and record who may approve a new folder.
Naming and clean-up are where automatic management tends to surprise teams. An automatic mode applies a naming pattern, so confirm whether that pattern can include the project identifier, whether it changes when a project is renamed, and what happens to the folder when a project is archived or deleted. Some integrations leave folders in place and others remove them, and the answer determines how many stale folders and how much storage you inherit. Manual linking avoids generated names but leaves naming to convention, so write one before the first link is made. Test renaming, archiving and deleting on a pilot project and keep the results.
The mode should follow how your organization already structures SharePoint. If each department has a site with a document library per program, automatic folders may fit inside that library cleanly. If project work is spread across many sites with their own owners, manual linking often keeps existing ownership intact. Before deciding, list the sites and libraries in scope, the owner of each, any retention or labeling policies, and any folder conventions already in use. Then run one pilot project in each mode, check the results against that inventory, and record the decision with its owner so later projects follow the same path.
Configuring the Entra app and linking storage in OpenProject
This sequence connects a Microsoft Entra app registration to OpenProject so that project folders and linked files live in OneDrive or SharePoint. Each step produces a value or a check that the next step depends on. Confirm the exact permission names, menu paths and field labels against the OpenProject documentation for your version before you start.
Register the application in Entra
An Entra administrator creates an app registration in the tenant that holds the OneDrive and SharePoint content. Record the application (client) ID and the directory (tenant) ID from the overview page, because OpenProject needs both during storage setup. Set any redirect URI and supported account type exactly as the OpenProject storage documentation specifies for your version, and confirm those values with the vendor documentation before you rely on them. Done when the app appears in the tenant's app registrations and both IDs are saved in your secrets inventory.
Add the required API permissions
Under API permissions, add the Microsoft Graph permissions that the OpenProject storage documentation lists for file access and folder creation. Add only the entries that list requires, and record each scope with the reason it is needed so your security reviewer can trace it. Choose delegated or application permissions as the documentation specifies, since that choice changes what the app can reach and who must consent. Confirm the exact scope names against the current documentation before you add them. Done when the permission list matches the documented set with nothing extra.
Grant admin consent and confirm status
A tenant administrator selects the option to grant admin consent for the directory on the API permissions page. The check is that every permission shows a granted status for the organization, not only for the person who clicked the button. If any permission still shows pending, the connection test in a later step will fail, so resolve it here. Keep a record of who granted consent and when, because auditors often ask for that evidence. Confirm which role your tenant policy requires to grant consent, since the request may need a different approver.
Create and store the client credential
Create a client secret or upload a certificate under the certificates and secrets section of the app registration. A secret expires on the date you set, so record that date, assign an owner and add the renewal to your calendar before it lapses. Copy a secret value once, because Entra does not display it again. Store the value only in your approved secrets manager, and keep it out of tickets and shared documents. If you use a certificate, keep the private key in a controlled store and confirm that OpenProject's storage form accepts that credential type. Done when the credential is stored and its expiry date has an owner.
Enter storage details in OpenProject administration
In OpenProject, an administrator opens the administration area, finds the file storage section (confirm the menu path for your version) and adds a OneDrive or SharePoint storage. Enter the tenant ID, client ID and the credential from the previous step, along with any site or drive details the form requests. Confirm each field label against the current documentation, since labels can change between releases. Run the connection test that the form provides. Done when the storage shows as connected and the test reports success. If the test fails, check consent, the credential and the tenant ID before changing anything else.
Choose the folder management mode
Select how OpenProject creates and manages project folders in the storage. Decide whether folders are created automatically when a project is linked or whether users create and link them manually, and decide who holds the rights to change that setting. Automatic management requires the app to create folders in the expected parent location, so agree the parent folder and naming pattern with the document owners first. Changing the mode later can leave existing folders in a different state, so test the choice on a non-production project. Done when the chosen mode is saved and visible in the storage configuration.
Link a test project and verify files
Pick a test project, confirm that your plan includes the file storage features (the topic requires the Enterprise plan), enable the storage module there and link the storage to it. Open SharePoint or OneDrive in a browser and confirm that the project folder appears in the expected location with the naming your chosen mode produces. Then open a work package in that project, attach or link a file from the storage and confirm that it displays and opens from the work package. Record the results and configuration so the production rollout repeats the same sequence. Done when the folder exists in the right place and a linked file is visible from a work package.
How OpenProject projects, work packages and files map to SharePoint and OneDrive
This table maps each OpenProject object to the Microsoft 365 object it becomes in the integration, and names who should decide each mapping. Read each row with the tenant question in the last column, because most mapping problems start in the tenant's site and permission design, so answer those questions before configuring the integration.
| OpenProject object | Microsoft 365 counterpart | Who owns the mapping decision | What to confirm in the target tenant |
|---|---|---|---|
| Project to folder | A folder in a SharePoint document library on a team or project site, created per project when managed folders are enabled | Project sponsor with the platform owner | Site naming, library location, and whether the integration app can create folders in that site |
| Work package to linked file or folder | A link from the work package to an existing file or folder in the library, so the document stays where it is stored | Work package owner with the document owner | Whether links resolve for everyone on the project, and how sensitivity labels apply to linked files |
| OpenProject user to Entra identity | The Entra ID user matched to the OpenProject account through the sign-in identity both systems share | Identity or IAM lead | Which attribute links the accounts, and whether guest or external users are in scope |
| Project membership to permissions | Site or library permissions granted to the matching Entra identity, usually through a group | Project manager with the Microsoft 365 administrator | Whether the app permissions can reach beyond project folders, and how removals from a project propagate |
| Storage scope: SharePoint or OneDrive | Project sites in SharePoint for shared work; OneDrive holds each person's personal files | Information governance owner | Whether OneDrive personal storage is in scope at all, since those files belong to individuals rather than projects |
| Folder management mode | Automatic project folder creation and naming, or links to folders your team already maintains | Platform owner with the project manager | Which management modes the installed release offers and how each behaves when a project is renamed or archived |
| Entra app registration | An application registration that grants Microsoft Graph access to the chosen sites or libraries | Microsoft 365 administrator | Consent scope, the least-privilege permission set, and who rotates the client secret or certificate |
Who can open linked files: identity and permission boundaries
The file a user sees in OpenProject depends on two permission layers working together: the user's OpenProject role in the project, and the Microsoft permissions that the integration holds on the underlying SharePoint site or OneDrive library. A user whose OpenProject role lets them view a work package but who has no access to the library will see the link but cannot open the file in Microsoft. The reverse also holds. A user with broad Microsoft access does not gain access to a linked file through OpenProject if their project role does not allow that work package to be viewed. Map each project role to the libraries it should reach before rollout, and confirm in the OpenProject documentation which permission governs viewing linked files and which governs creating or managing the storage connection, since these are configured separately.
The Entra app registration that OpenProject uses to call Microsoft Graph is the largest lever in this design. If the app is granted tenant-wide access where the integration only needs a small set of project sites, every user who reaches a linked file is effectively relying on an identity with far more reach than any project needs, and a leaked client secret exposes the same breadth. Scope the app to the specific sites or libraries used for managed project folders, choose the least permission level that supports the folder management mode you select, and record the admin consent decision with its justification. Ask your Microsoft administrator to confirm the exact permission types the OpenProject release you deploy requests, and repeat that review after every upgrade.
Identity mapping decides whose Microsoft permissions a file request is checked against. Each OpenProject account must correspond to the correct person in Entra, usually through a shared identifier such as the email address or an identity provider link. If the mapping is wrong or missing, a user may see links they should not, or see none at all. Confirm with OpenProject whether file access is evaluated against the signed-in user's own Microsoft permissions or performed by the application on the user's behalf, because that choice changes which permission check actually applies to each request. Also define what happens when someone leaves or changes roles: removing their Entra access and their OpenProject membership should be part of the same offboarding step, so that neither layer keeps access the other has revoked.
Verify the boundaries with a standard, non-administrator test user before any team relies on the integration. Create one Entra test account that holds no Global Administrator, SharePoint administrator or similar directory role, because administrator accounts can see content that ordinary users never will and will hide a misconfiguration. Add the test user to one project with a defined role and to a second project without access to the same library. In each project, confirm that the work package links appear only where expected, open each visible link, and check that the user cannot browse beyond the managed project folder. Record the results, then repeat the test after any permission change, role change or OpenProject upgrade.
Hardening the Entra app permissions and client secrets
Six settings decide how much damage a leaked secret, a misconfigured app or an over-privileged administrator can cause in an OpenProject and Microsoft 365 integration. Each card covers one control, and together they cover the app's permissions, its credentials, the people who configure it and the evidence you keep.
Least-privilege Graph permissions
Grant only the Microsoft Graph and SharePoint permissions that the integration documentation lists for file linking and folder management. Each extra permission widens what a leaked secret or a compromised OpenProject administrator can reach. Before approving anything, list every permission on the app registration, match each one to a feature you enabled, and remove any you cannot explain. Confirm the exact permission names against the current OpenProject and Microsoft documentation for your release.
Site-scoped access where supported
Where your tenant and Microsoft's documentation allow it, limit the app to the SharePoint sites that hold project folders. Name those sites in the design document with their owners, and test that a project folder cannot be created on a site outside that list. Broad tenant-wide access is simpler to set up, but it lets the integration read or write content unrelated to OpenProject. Ask your Microsoft 365 administrator which scoping options your licensing and tenant configuration support.
Client secrets in a managed vault
Store the Entra client secret in a managed secrets vault that your platform team controls, and give the OpenProject service only the read access it needs at startup. Record the expiry date and a named owner for each secret, and set a rotation date well ahead of expiry so the integration does not fail during a busy period. Confirm whether your Entra configuration supports certificate credentials and which credential type your security standards prefer.
Restricted storage setting changes
Storage settings decide which tenant, sites and folder behavior OpenProject uses, so changes should sit with a small group of OpenProject administrators. Limit the global administrator role to named people, review that list on a fixed schedule, and require a change record for every edit to the OneDrive or SharePoint configuration. OpenProject roles and Entra roles are managed separately, so an Entra administrator does not automatically gain OpenProject administration rights.
Audit logging in Entra and SharePoint
Turn on sign-in and audit logging in Microsoft Entra and the SharePoint audit log for every site in scope, then assign a reviewer and a review interval. Look for sign-ins by the integration's app identity from unexpected locations, changes to the app registration, and file activity on project folders outside working hours. Confirm the log retention your license provides, because logs that expire before anyone reviews them offer little value.
Consent review on version changes
Review the app's granted permissions whenever the Entra app configuration changes or you upgrade OpenProject to a new release. Compare the permissions requested in the release notes and integration documentation with what is currently granted, and approve only the difference. Test the link and folder actions in a non-production tenant or test site before rollout, and record who approved the consent and when.
How to test the link before project teams rely on it
Test the OneDrive and SharePoint link in a sandbox before any project depends on it. Create a sandbox OpenProject project and a dedicated SharePoint test site, separate from the document libraries that hold live project files. That separation lets you create, rename and delete test files and folders without touching real records. Use the same Entra app registration design you plan for production, including the same permission scope, because a test against a more generous app predicts nothing about production. Ask your Microsoft 365 administrator to confirm which site collection and document library the test uses, and record the site address in the test log.
Run the file checks with a test user who has no tenant or site administrator rights. Administrator accounts can see and fix things that regular users cannot, which hides permission gaps. As this user, link an existing file to a work package, open it from the work package, rename it in SharePoint or OneDrive, check that the new name appears in OpenProject, then remove the link and delete the file. Repeat the steps from the OpenProject side, and record the exact step and error message for every failure. Also confirm that the user sees only the files that the work package permissions allow.
Check folder creation against the folder management mode you chose. Create a sandbox project with that mode set, then confirm the folder name, its location in the document library and whether OpenProject writes to the expected path. Repeat with a second project to check how the integration handles a name that already exists. Test any mode change only in the sandbox, and confirm in the administration guide for your release what happens to folders created under the previous mode. Then run the permission-removal test: remove the test user from the project and from the SharePoint site, and confirm that access ends in both systems.
Rehearse secret rotation in the sandbox. Generate a new client secret for the Entra app, update the OpenProject configuration, and confirm that file linking still works and that the old secret no longer authenticates. Time the steps and note every manual action, so the runbook reflects what the operations team will actually do. Record all results in a test log that lists the OpenProject version, test date, tester, and a pass or fail entry for each check. Repeat the full test after each OpenProject upgrade, including patch releases, and compare the new log with the previous one before the upgraded instance goes back to project teams.
Common failures when linking SharePoint and OneDrive folders
This table lists the failures teams most often hit when linking OneDrive and SharePoint folders to OpenProject work packages, with the likely cause and a fix for each. Work through the rows in order, because consent, credentials and permissions must be correct before the folder path and identity checks matter. Confirm every fix against the current OpenProject documentation, Microsoft's documentation and your tenant's policies before you change production settings.
| Failure | Cause | Fix |
|---|---|---|
| Admin consent missing | The Entra app registration requests permissions that no tenant administrator has approved. | Have a tenant administrator grant consent for the application permissions listed in the setup guide, then confirm the consent status in Entra before retesting. |
| Expired client secret | The client secret that OpenProject uses to call Microsoft has passed its end date, so sign-in fails. | Create a new secret, update the OpenProject configuration, and schedule rotation before expiry under your tenant's secret lifetime policy. |
| Insufficient site-level permissions | The app identity can authenticate but has no rights on the specific SharePoint site or document library. | Grant access on the target site or library using the permission model your tenant allows, then test with one work package. |
| Folder path does not exist in the target library | The configured path differs from the real folder in spelling, letter case or structure, or the folder was renamed or moved. | Create the managed project folder in the library first, or correct the configured path, and verify it with a single test link. |
| User without a matching identity | An OpenProject user has no matching Microsoft identity, often because the email address or identity attribute differs between the two systems. | Align the user's identity attribute across both systems, confirm the person can open the folder in Microsoft 365, then link the work package. |
| Outbound network blocked to Microsoft endpoints | A firewall, proxy or DNS policy stops the OpenProject server from reaching Microsoft sign-in and file service endpoints. | Allow the required Microsoft endpoints from the OpenProject host through your egress controls, using the endpoint list in Microsoft's current documentation. |
| Plan does not include the feature | The instance runs a plan or edition that does not include the OneDrive and SharePoint integration, so the option is missing or disabled. | Confirm with OpenProject that the integration is included in the plan and user count you license before design, and check the current pricing page. |
What the Enterprise plan adds and what it costs before you start
The OneDrive and SharePoint integration requires the Enterprise plan, and the Community edition does not include it. The Community edition is free and covers work packages, Gantt charts, agile boards, time tracking and dashboards, with community support, but it does not link Microsoft 365 files to work packages or manage project folders in SharePoint. Decide the licence before the build starts, so the Entra app permissions and folder design are not built around a plan you have not bought. Ask OpenProject to confirm in writing that the Enterprise tier you intend to buy includes this integration, because the pricing page is the reference for what each tier contains.
The pricing page sets Enterprise on-premises prices per named user per month. Basic costs 5.95 euros and Professional costs 10.95 euros, with a 25-user minimum on Professional. Premium costs 15.95 euros with a 100-user minimum, and Corporate is quoted on request for 250 or more users. Minimums can change the effective cost of a small team. For example, an illustrative team of 12 users on Professional would be counted against the 25-user minimum, so confirm how the minimum is applied to your order. Licence fees recur for as long as you hold the subscription, and they grow as named users are added. The Entra app registration, folder configuration and any DeployOpen implementation work are separate costs that appear in the written scope.
Enterprise also lists single sign-on and LDAP group synchronization among its features. The pricing page names SSO protocols including SAML, OIDC, CAS, Kerberos and Okta, along with LDAP group synchronization. These features matter for this integration because your identity setup determines who can sign in to OpenProject, which project roles they receive, and therefore who can reach a linked SharePoint file from a work package. Confirm with OpenProject which of these features are included in the tier you select, whether your Entra ID or on-premises directory is a supported source for groups, and whether any identity feature is priced as an add-on. The Nextcloud integration documentation describes OpenID Connect SSO for that integration as an Enterprise add-on, so check whether a similar add-on applies here.
Before you request a quote, write down the named user count for the next 12 months, the tier that matches it, and the identity features you need on day one. Ask the vendor for a written list of what each tier and add-on includes, the support level, the currency and tax terms, and any minimum term. Ask DeployOpen to show costs as separate lines in the written scope: licence fees paid to OpenProject, one-time implementation work for the Entra app registration and folder management, and recurring operations work after go-live. Compare these figures with the effort of keeping the same workflow on Community with manual file links. Record the licence decision in the scope document so it is reviewed alongside the Entra permissions and folder design.
Questions teams ask before linking OneDrive or SharePoint to OpenProject
Can the Community edition link OneDrive or SharePoint to OpenProject?
No. The OneDrive and SharePoint integration requires the Enterprise plan, so a Community installation cannot use it. The Community edition is free and includes work packages, Gantt charts, agile boards, time tracking and dashboards, with community support. Its Nextcloud integration is also available there, which is a different file storage option. If you run Community today, the decision is between moving to an Enterprise plan and choosing another file storage approach. Confirm the current feature list on OpenProject's pricing page before you budget, because editions and features can change. Ask the vendor in writing which edition each module requires in the version you plan to run.
How does the effort change with the number of sites, folders and identity sources?
Effort rises with each site, folder structure and identity source the integration must cover, because each one adds configuration, permission testing and mapping decisions. A single SharePoint site with one folder pattern is a short, contained configuration. Multiple sites, document libraries with different owners, and users who sign in through more than one directory add more app registrations, permission checks and rules about which folders are created automatically and which are linked by hand. Effort also grows if your existing folder naming is inconsistent, because that cleanup has to happen before the links are built. Ask the provider to list each site, library and identity source in the written scope, and to state which folder management mode applies to each one.
Can our internal team set up the OneDrive and SharePoint link alone?
Often yes, if your team already runs OpenProject Enterprise and has administrators for Microsoft Entra ID and Microsoft 365. The work combines three skills: OpenProject administration, app registration and permission design in Entra, and a clear decision on folder management for each project. Teams missing one of these skills usually spend more time on trial and error, and that work tends to land in production-like settings. Before you decide, confirm who will register the Entra application and grant consent, who owns the SharePoint sites, and who will test folder creation and access for each role. A fixed-scope engagement can cover the parts your team lacks time or experience for, and the written scope should state which tasks stay with your staff.
What do our Microsoft 365 administrators need to provide?
Your Microsoft 365 administrators handle the identity and permission side of the work, so their requirements should be settled before the build starts. Typically this means an Entra administrator who can register an application and approve the permissions it needs, a SharePoint administrator who confirms which sites and libraries the integration may access, and a named owner for the Entra tenant and any conditional access policies that could block the connection. Ask for the exact permission list in writing, the tenant and site identifiers, a test account for each role, and a scheduled window for consent. Check each permission and its scope against Microsoft's current documentation and your own security policy, because your administrators make the final decision on what the tenant grants.
How long does a OneDrive or SharePoint pilot take?
The length depends on the scope of the pilot, so no fixed duration applies until the sites, projects and identity sources are listed. The main drivers are how many sites and folder structures the pilot covers, how quickly administrators can approve the Entra app registration and permissions, and whether your OpenProject installation already runs on the Enterprise plan. Testing also takes time: you need to confirm that folders are created or linked correctly for each role, that access is denied where it should be, and that files open from work packages as expected. Ask any provider for a timeline tied to written milestones, and mark the approval steps that sit with your own teams. Consent can be the longest dependency, so schedule it first.
What changes after an OpenProject upgrade for SharePoint links?
The integration can behave differently after an upgrade, so each upgrade needs a planned check before and after the change. OpenProject publishes release notes for each version, and the 2026 releases in the 17.x line include 17.7.0, 17.8.0 and 17.9.0, followed by 17.9.2. Read the notes for every version between your current release and the target, looking for changes to storage integrations, Enterprise features or database requirements. Then test folder linking, permission behavior and sign-in in a staging copy before you touch production. Confirm that your PostgreSQL version still falls within the supported range, since OpenProject supports PostgreSQL 16 or later. Plan a rollback path, and record the Entra app settings your links depend on so they can be checked after the upgrade.
Which folder management mode should we choose for project folders?
Choose the mode for each project based on who creates and maintains its folders, and confirm which modes your installed version offers before you design the naming scheme. In general, the choice separates setups where OpenProject creates and manages project folders from setups where it links to folders that users already maintain. Automatic management reduces manual setup but requires agreed naming rules and clear permissions for the folders it creates. Linking existing folders keeps current structures but makes it easier for links to break when someone renames or moves a folder. Test both modes with a sample project, and check the exact options in the current OpenProject documentation before you commit to one pattern across all projects.
How DeployOpen scopes, delivers and supports the OpenProject and Microsoft 365 link
DeployOpen approaches the OpenProject and OneDrive and SharePoint link as a planned part of your own infrastructure, scoped in writing before any configuration starts. We work with your identity team, your Microsoft 365 administrators and your project owners so that file access, folder management and sign-in follow your existing controls. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- The written scope names the Enterprise plan this link requires and the Microsoft 365 tenants involved.
- Scope records which OneDrive and SharePoint sites, libraries and project folders OpenProject may reach.
- We agree in writing who approves the Entra app registration and which permissions it is granted.
How we build
- We register the Entra app and configure its permissions in the order your tenant administrators approve.
- We choose one folder management mode per project after confirming how your teams store project files.
- Each file link, folder and work package relationship is tested with a named user account before handover.
How we hand over
- Handover includes configuration records, the Entra app settings and the folder structure we deployed.
- Your administrators receive runbooks for rotating app credentials and changing permissions later.
- Project owners get a short guide on linking files to work packages and on what their colleagues can see.
How we support
- Support covers the OpenProject upgrade path, so the integration is retested against each release you adopt.
- Ongoing support is available as a retainer for changes to permissions, folder modes and Microsoft 365 policy.
- Microsoft-side changes, such as conditional access or tenant policy updates, are reviewed with your administrators first.
