How to Connect Atlas with Microsoft OneDrive

OneDrive, and its close relative SharePoint, is the default file store for organizations standardized on Microsoft 365. The documents that matter to a project usually sit there, while the project itself, its tasks, owners, and dates, sits in Atlas. The two need a reliable join so the file and the work do not drift apart.

The aim is not to move files out of Microsoft 365. It is to make them reachable from the Atlas record that owns them, and to let file events drive work where that saves manual steps.

Where a native connection is available

If Atlas provides a native OneDrive or Microsoft 365 connection on your plan, authorize it from the integrations area and associate document libraries or folders with Atlas projects. A native connection generally manages the Microsoft identity handshake and token refresh, which are the fiddliest parts of a Microsoft integration to maintain by hand.

With the mapping in place, the right document library is reachable from the Atlas record, and Microsoft 365 permissions continue to govern access, so you are not creating a second, weaker access-control surface.

If not, use Microsoft Graph, webhooks, or Zapier and Make

Without a native connection, Microsoft exposes OneDrive and SharePoint through the Microsoft Graph API, which supports change notifications you can subscribe to. Atlas provides its own REST API and webhooks. Join them with a self-hosted integration when you need control, or with Zapier or Make when you want speed and visibility.

A dependable pattern subscribes to Graph change notifications for a document library and calls the Atlas API when a relevant file appears or changes, and emits Atlas webhooks to create or update Microsoft 365 folders when projects begin.

• Attach a OneDrive or SharePoint document link to the Atlas record that owns it.
• Create an Atlas review task when a new file lands in a monitored library.
• Provision a standard SharePoint folder set when an Atlas project is created.
• Notify the assignee when a monitored document is updated.

Common workflows worth building

File-to-work triggers deliver the clearest value. A signed proposal saved to SharePoint can advance the associated Atlas deal. A final deliverable uploaded to OneDrive can create and assign the client-review task in Atlas.

For document-heavy delivery, a library-per-client or library-per-project convention mapped to Atlas keeps everyone working from the same materials and reduces the search time that fragmented storage creates.

Governance and reliability

Pass links and metadata rather than duplicating files, so Microsoft 365 stays the single store and its permissions remain authoritative. This matters more in Microsoft environments, where document governance is often centrally managed and duplication undermines it.

If you build your own bridge, handle Graph subscription renewals and throttling deliberately, since Graph change subscriptions expire and must be renewed. Prefer a native connection or a managed platform when you would rather not own that upkeep, and begin with a one-directional flow.

Application versus delegated permissions

Microsoft integrations force an early decision that shapes everything after it: whether the connection acts as an application with its own broad access, or on behalf of individual users with their own permissions. Application permissions let a background integration run without a signed-in user but grant it wide reach that your security team will rightly scrutinize. Delegated permissions keep access scoped to what each user can already see, which is safer but requires a user context to operate.

For a file-linking integration that only needs to resolve and attach documents, prefer the narrowest permission set that does the job, and document why each granted scope is necessary. In centrally governed Microsoft 365 environments, an integration that requests more than it needs is often the reason a connection is refused approval, so scoping conservatively is both a security and an adoption decision.