Productivity integration guide
Microsoft 365 + UbiGrowth workflows
Microsoft 365 is Microsoft's productivity and identity suite, where documents, mail, calendar, and directory data underpin enterprise work. This guide covers the records that matter, how the connection should be scoped, and what the first bounded workflow should be.
Introduction
Make Microsoft 365 part of the workflow, not another silo.
Validate connector availability for your workspace
This guide covers how a team designs a productivity workflow around Microsoft 365 with UbiGrowth: which records stay authoritative, how the connection should be scoped, what the first bounded workflow should be, and how to tell whether it worked.
The records that matter are User, Mail Message, Calendar Event, OneDrive Item, SharePoint Site, Team, and Group. Microsoft 365 resolves everything through Entra ID, and a Microsoft 365 Group simultaneously backs a Team, a SharePoint site, and a shared mailbox. The same group id therefore means four different containers depending on which endpoint you ask.
Microsoft 365 is not currently on UbiVibe's verified connector list. This page is an implementation design reference: use it to specify the workflow, then validate whether the connection is available and correctly scoped for your workspace before you make it a dependency. The verified UbiVibe connections today are Salesforce, HubSpot, Gmail, Google Drive, Slack, and GitHub.
The platform layer is the usual destination for this connection, because the value shows up as governed context and execution shared across more than one team.
Why teams evaluate this connection
Integrations create value when they remove operating friction.
The first design decision is not which API endpoint to call; it is which system owns the record, what event should trigger work, who owns the exception path, and what successful completion means.
Productivity platforms are where a company's real operating context lives, and also where it becomes unusable. Microsoft 365 accumulates the documents, decisions, and working state that describe how the business actually runs, in a structure nobody designed and nobody maintains.
The consequence is that answering an ordinary operational question means searching, opening several files, and reconstructing something that was already written down. The information was captured; it was just never made usable.
You're likely here because
- Operating knowledge is spread across documents nobody can search across
- Core processes run on a spreadsheet with one maintainer
- The same status question is answered manually several times a week
Record model
What a Microsoft 365 integration actually reads and writes.
Integration design starts from the objects the system really exposes, not from a generic connector diagram. These are Microsoft 365's.
Identity and matching
Microsoft 365 resolves everything through Entra ID, and a Microsoft 365 Group simultaneously backs a Team, a SharePoint site, and a shared mailbox. The same group id therefore means four different containers depending on which endpoint you ask.
Start here
Read one SharePoint document library's change history and route stale-but-referenced documents to their owners for review.
What this will not do
It will not be interchangeable with Teams-only access. Teams is one surface on the Microsoft 365 group model; a mail or SharePoint workflow needs its own scopes.
The constraint to plan around
Graph permissions come in delegated and application flavours with materially different reach, and application permissions are tenant-wide by default. Getting this wrong grants access to the entire tenant rather than to one workflow.
Build notes
What you actually have to reason about in Microsoft 365.
The fields that carry meaning, how the connection authenticates, and whether the event surface can be trusted. This is the part that decides whether the integration works in month three.
| Field | Why it matters |
|---|---|
| group id | one id backs a Team, a SharePoint site, and a shared mailbox simultaneously |
| driveItem id vs path | ids are stable, paths change on rename or move |
| event / onlineMeeting | calendar events and the meeting object behind them are separate resources |
| userPrincipalName vs id | UPN changes on rename; the object id does not |
| delta token | the supported incremental mechanism across Graph resources |
Authentication
Entra ID app registration with delegated or application Graph permissions. Application permissions are tenant-wide by default and require admin consent — Mail.Read as an application permission means every mailbox in the organisation, which is rarely what was intended. Application Access Policy narrows it and is frequently skipped.
Events and delivery
Graph change notifications are subscription-based with an expiry requiring renewal, and they carry a change signal rather than the content. Rich notifications with resource data need encryption configured, which is additional setup.
Workflow
How the Microsoft 365 workflow runs.
The operating sequence, from reading the source system through to the result landing back where it belongs.
Step 01
Scope the working set
The specific Microsoft 365 content the workflow needs is identified and connected, rather than the whole account.
Step 02
Read what is already written down
The workflow reads the current, owned version of the content instead of asking anyone to re-enter information that already exists.
Step 03
Structure the operating state
The information becomes records with owners and status, so the process has state rather than living in a document nobody maintains.
Step 04
Build the surface in Launch
The intake, tracker, or dashboard the team actually needs gets built, so the output has somewhere to live beyond a chat response.
Design decisions
The productivity decisions this connection forces.
Each of these has to be settled before the Microsoft 365 workflow is allowed to write anything.
Step 01
Scope to the working set
Connect the specific Microsoft 365 folders, spaces, or workspaces the workflow needs. Broad access is easier to configure and much harder to defend later.
Step 02
Decide what stays authoritative
A document that is being read by a workflow should have one owner and one current version, otherwise the workflow will confidently use the wrong copy.
Implementation path
How to implement the Microsoft 365 workflow.
- 01
Identify the specific Microsoft 365 content the workflow needs and scope the connection to it rather than to the whole account.
- 02
Confirm the content is current and owned. Automation reading a stale document produces confident, wrong output.
- 03
Start with a read-only workflow that answers a question people currently answer by hand.
- 04
Once stale-document review works, extend to external sharing across SharePoint sites, which is the same question at organisational scope.
Governance
Controls that matter.
Control 01
Access is scoped to the folders, spaces, or drives the workflow needs, and reviewed when the workflow changes.
Control 02
Sensitive content — personnel, legal, and financial documents — is excluded deliberately rather than by omission.
Control 03
Documents that feed a workflow have a named owner and a current version.
Failure modes
How a Microsoft 365 integration breaks in production.
Not generic integration advice. These follow from how this system actually behaves, which is why they look nothing like the list on the next guide over.
Symptom 01
An application permission grants access to every mailbox in the tenant.
Cause
Application permissions are tenant-wide by default and no Application Access Policy was applied.
Fix
Apply an Application Access Policy scoping the app to a security group, and verify it before going live.
Symptom 02
Change notifications stop after a few days.
Cause
The subscription expired without renewal.
Fix
Renew subscriptions on a schedule and treat renewal failure as a page-worthy event.
Symptom 03
Removing someone from a group also removes their file access.
Cause
The group backs a Team, a SharePoint site, and a mailbox simultaneously.
Fix
Understand what a group backs before changing membership programmatically.
What changes at scale
Graph throttling is per app, per tenant, and per resource, with different limits per workload. Honour retry-after and use delta queries rather than repeated full reads.
Examples
What a working Microsoft 365 workflow looks like.
Bounded scenarios rather than a feature list. Each one can be verified against work the team already does.
Document workflows
With Microsoft 365 connected, Launch can read the structured content the team already maintains instead of asking anyone to re-enter it into a new system.
Spreadsheet to operating tool
A high-risk spreadsheet in Microsoft 365 becomes a Launch-built tool with owners, status, and history, removing the single-maintainer dependency.
Limitations and considerations
What to validate before you depend on this.
- Graph permissions come in delegated and application flavours with materially different reach, and application permissions are tenant-wide by default. Getting this wrong grants access to the entire tenant rather than to one workflow.
- Because a Team, a site, and a mailbox share a group identity, a permission change intended for one surface can affect all three. Removing a member from a group removes their file access too.
- When only Teams messaging is needed. Chat message content requires protected permissions Microsoft gates behind justification and, for application access, per-message metering.
- Content quality determines output quality. A workflow reading an out-of-date Microsoft 365 document will produce confident, incorrect results.
- Broad access is a security decision, not a convenience decision. Scope the connection to the working set the workflow needs.
FAQ
Microsoft 365 integration questions.
What records does a Microsoft 365 integration actually work with?
The primary records are User, Mail Message, Calendar Event, OneDrive Item, SharePoint Site, Team, and Group. Microsoft 365 resolves everything through Entra ID, and a Microsoft 365 Group simultaneously backs a Team, a SharePoint site, and a shared mailbox. The same group id therefore means four different containers depending on which endpoint you ask.
What should the first Microsoft 365 workflow be?
Read one SharePoint document library's change history and route stale-but-referenced documents to their owners for review.
What will a Microsoft 365 integration not do?
It will not be interchangeable with Teams-only access. Teams is one surface on the Microsoft 365 group model; a mail or SharePoint workflow needs its own scopes.
What is the main constraint to plan around?
Graph permissions come in delegated and application flavours with materially different reach, and application permissions are tenant-wide by default. Getting this wrong grants access to the entire tenant rather than to one workflow.
What changes about a Microsoft 365 integration at scale?
Graph throttling is per app, per tenant, and per resource, with different limits per workload. Honour retry-after and use delta queries rather than repeated full reads.
How does authentication work for Microsoft 365?
Entra ID app registration with delegated or application Graph permissions. Application permissions are tenant-wide by default and require admin consent — Mail.Read as an application permission means every mailbox in the organisation, which is rarely what was intended. Application Access Policy narrows it and is frequently skipped.
Does Microsoft 365 support webhooks, and can they be trusted?
Graph change notifications are subscription-based with an expiry requiring renewal, and they carry a change signal rather than the content. Rich notifications with resource data need encryption configured, which is additional setup.
What is the risk of writing to Microsoft 365?
Because a Team, a site, and a mailbox share a group identity, a permission change intended for one surface can affect all three. Removing a member from a group removes their file access too.
When is connecting Microsoft 365 the wrong call?
When only Teams messaging is needed. Chat message content requires protected permissions Microsoft gates behind justification and, for application access, per-message metering.
What should a Microsoft 365 integration automate first?
Start with one bounded workflow that removes a measurable handoff, duplicate-entry step, reporting delay, or follow-up gap. Expand only after the first workflow is reliable.
Does UbiGrowth require Microsoft 365 to be replaced?
No. The operating model is designed around connecting to systems that should remain authoritative and building workflows around them rather than forcing a wholesale replacement.
Is connector availability identical for every workspace?
No. Availability can depend on provider configuration, authentication, scopes, workspace setup, and deployment state. Validate the required connection before treating it as an operational dependency.
Does connecting Microsoft 365 expose everything in it?
It should not. Scope the connection to the specific folders, spaces, or drives the workflow needs, and exclude sensitive content deliberately.
Can the workflow write files back?
Write and file-creation steps should be added after the read path is trusted, and should have a clear owner for what gets created and where.
What if the document is out of date?
The workflow will use it. Content that feeds a workflow needs a named owner and a current version, or the output will be confidently wrong.
How this access is governed
What ARIA is allowed to do in Microsoft 365, and who decides.
Connecting Microsoft 365 is a permission decision, not just a setup step. These are the controls that decide what ARIA can reach, what it can change, what gets recorded, and how you take the access back.
Required permissions
ARIA works through the scopes the connection was granted, and no others. Authorization happens at the provider, so the permissions being requested are shown by the system itself before anything is connected.
What it can reach
Reachable systems are the intersection of what your organization approved in the connector registry and what the requesting identity is permitted to use. Identity resolves before execution, not after.
What it can do
Actions run through explicit execution paths with state, spend, and failure boundaries — a bounded worker path rather than an open-ended agent loop with a credential.
Credential handling
Credentials live in the governed connection layer and are resolved through canonical connection identity. They are not pasted into individual workflows, prompts, or generated artifacts.
Action logging
Execution carries state and traces: what triggered the work, which connection it used, and what came back — including an explicit failure when something did not run.
Approval and revocation
Consequential actions can be made to require a person to approve them. Access can be changed or revoked at the connection, and ARIA loses that reach without unpicking the work already completed.
Start with ARIA
Ask ARIA to run this integration.
Describe the outcome you need across this system. ARIA works out the scopes, data, and actions the job requires, and operates inside the access you grant — which you can change or revoke.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Turn the integration into a working business outcome.
Start with ARIA to describe the outcome, then continue into the product path that fits the workflow. Connector availability and required scopes should be validated for the specific workspace before production use.