Microsoft 365: Hybrid Setup

this guide helps teams set up ashby's native microsoft 365 integration in a hybrid configuration keeping some access application wide for easier scheduling, while relying on individual microsoft authorization for more sensitive workflows like email syncing and sending a hybrid microsoft 365 setup in ashby can work well when your team wants the convenience of application wide scheduling coverage together with more selective user level access for email workflows the most successful setups happen when the team decides in advance which workflows should stay broad and which should move to individual microsoft authorization prerequisites to complete the hybrid setup route for microsoft 365, you'll need the following permissions organization admin access in ashby, to enable the native microsoft 365 integration with application wide admin consent microsoft entra admin access, to remove or manage granted permissions for the ashby enterprise application in your microsoft tenant what microsoft hybrid setup supports ashby's native microsoft 365 integration supports both application wide admin consent and individual user authorization in a hybrid setup, your team can keep application wide access where it reduces rollout and scheduling friction across the organization remove selected application wide permissions afterward if you prefer a more restrictive setup for specific workflows have users who need those workflows authorize microsoft individually in ashby at a high level, ashby checks for individual user authorization first and falls back to application wide access if individual authorization is not present use case for microsoft hybrid setup this approach is most useful when your team wants broad calendar coverage for scheduling, but does not want every microsoft permission to remain application wide after setup a common example is keep calendar related access application wide so recruiters and coordinators can view interviewer availability without requiring every interviewer to authorize individually move email related workflows to delegated or individual authorization so only the users who actually need to send or sync email through ashby authorize those permissions recommended hybrid setup pattern step 1 connect microsoft 365 in ashby with application wide admin consent start by enabling ashby's native microsoft 365 integration with application wide admin consent this is the fastest way to get the integration in place for your organization you can access that admin page here step 2 keep the application wide permissions you want for broad coverage many teams keep calendar related access application wide so interview scheduling works smoothly without requiring every interviewer to connect microsoft individually for example, ashby uses calendars readwrite for interview scheduling and calendar sync, and mailboxsettings read supports scheduling accuracy by reading settings like time zone and working hours it's best practice to keep both of these scopes available at the application wide level; otherwise, every user in your organization needs to authorize their microsoft account individually in personal settings step 3 remove selected application wide permissions in entra a common pattern is removing application wide email permissions such as mail send mail readwrite for native ashby microsoft 365 setups, make these changes in the granted microsoft tenant authorization for the ashby enterprise application in entra step 4 go back to ashby and refresh integration page you should see the revoked scopes on the integration with a red circle step 5 have users who need email features authorize individually in ashby users who need delegated access should go to personal settings > microsoft 365 settings in ashby and authorize their microsoft account individually this is especially relevant for users who need to send email from their own microsoft account through ashby sync recruiting related email history into ashby use microsoft teams meeting creation schedule interviews on microsoft group calendars what to expect after the change if you remove selected application wide scopes and rely more on delegated access, the experience becomes more user specific in practice, that means users who relied on the removed application wide scopes may need to complete their own microsoft authorization in ashby tenant side microsoft policies can have a bigger impact on whether a workflow succeeds some features may stop working if the required permission is no longer available application wide and the individual user has not authorized it important workflows that still require individual authorization some microsoft workflows require individual authorization even if your organization already has application wide microsoft 365 access connected in ashby the most common examples are microsoft teams meeting creation microsoft group or shared calendar scheduling if your team plans to use those workflows, make sure the relevant organizers or schedulers complete individual microsoft authorization in ashby reconnect warning if you disconnect and reconnect the native microsoft 365 integration in ashby, microsoft re requests the full application wide permission set when you reconnect if your team intentionally revoked selected application wide permissions after setup, you need to repeat that cleanup afterward for that reason, if your team is intentionally using a hybrid setup, document your expected entra side configuration internally before anyone reconnects the integration faq can my security team or other stakeholders have visibility or be notified when users authenticate with their microsoft 365 credentials in personal settings? please reach out to support\@ashbyhq com for further guidance on this