Skip to content
Surhires

In development

In build

File client and candidate mail from Microsoft 365 on the record

The Outlook connector is in active build for Wave 1 and is not connected today; it will file matching mail on the record and support shared mailboxes for a desk.

The Outlook integration is in development for the Wave 1 release, built alongside the Gmail connector, and is not available yet. When it ships it will file Microsoft 365 mail against candidate and client records, support shared desk mailboxes, and treat calendar access as a separate permission.

By Surhires Editorial · Published · Reviewed

In the product: in build for Wave 1 alongside the Gmail connector

State of this integration

Outlook is in build for Wave 1 alongside the Gmail connector, and nothing described here is switchable today. The two connectors share their filing rules, their reply detection and their suppression checks; what differs is the Microsoft platform underneath and the way corporate mail is actually administered.

That administrative difference is the reason this is a separate page rather than a line on the Gmail one. A Google-first agency connects a personal work account and gets on with it. A Microsoft 365 organisation has a tenant administrator, conditional access policies, shared mailboxes and a governance conversation, and the connector has to fit that.

Microsoft 365 specifics that change the design

Access will be through Microsoft Graph with an application registration your administrator can review. Conditional access policies, multi-factor requirements and device compliance rules stay in force; the connector does not sit outside them.

Scopes will be narrow and named: mail read and mail send. Calendar is requested separately. Contacts, files and directory scopes are not requested at all, because nothing in recruitment software needs to enumerate your company directory, and asking for it would fail a governance review that any competent administrator will run.

Where an organisation restricts consent to administrators, the grant is made once at tenant level and individual recruiters then connect within it. Where user consent is permitted, a recruiter can connect their own mailbox directly.

Shared mailboxes for a desk

Agencies frequently run a desk from a shared mailbox rather than an individual one: contract-it@, healthcare@, or a client-specific address that several recruiters watch. A connector that only understands one human per mailbox breaks immediately on that pattern.

The planned support treats a shared mailbox as a first-class connection owned by the mailbox rather than by a recruiter. Mail filed from it lands on the candidate or client record with the desk as the source, so it survives a recruiter leaving. Sending from a shared address requires the send-as permission Microsoft already governs, and the connector will respect that rather than working around it.

This is one of the places where an agency and an in-house team genuinely differ, and the agency pattern is the one most often missed.

  • A shared mailbox connects as its own source rather than through one recruiter
  • Send-as rights are checked against Microsoft's own permissions
  • Filed mail survives the recruiter who sent it leaving the business
  • Per-mailbox folder scoping, so an archive folder can be left out

Calendar is a separate permission on purpose

Interview scheduling needs calendar access. Mail filing does not. Bundling the two into one consent means an organisation that wants scheduling has to grant mailbox access it did not ask for, and an organisation that wants mail filing has to grant calendar access it did not ask for.

So the calendar scope is requested by the scheduling connector, separately, and can be granted, refused or revoked on its own. The Teams connector handles meeting generation with its own scope again. Three narrow requests that an administrator can reason about beat one broad one that gets refused.

Practically, this also means a talent team can pilot interview scheduling without a mailbox governance review, which is often the difference between a pilot starting this month or next quarter.

Filing rules are the same as Gmail

A message is filed when one of its participants matches a candidate or client contact in your tenant. Unmatched mail is not stored, not indexed and not shown. A recruiter can exclude addresses and domains, scope the connection to particular folders, and detach a filed message from a record without deleting it from Outlook.

Reply detection stops a running cadence the moment a candidate answers, and classifies the reply for interest, objection or availability. Bounces mark the address; automatic out-of-office replies are classified separately so they do not halt a sequence.

Sending goes out through the connected account, so messages carry your domain's own authentication and land in a candidate's inbox looking like what they are: mail from a person.

Where the responsibility sits

The mailbox, the tenant and the retention policies are yours. The connector reads and writes within the scopes you grant, and revoking consent in Microsoft 365 stops the sync without deleting what has already been filed on candidate records.

Retention is worth thinking about explicitly. Mail filed on a candidate record inherits that record's retention window in Surhires, which may be shorter than your Microsoft 365 policy. The two systems are not synchronised on deletion, and an erasure request handled in Surhires does not reach into your mailbox. That is a limitation, and it is better named than discovered.

What this connector will not do

It will not migrate a mailbox, act as a journaling or archiving target, or serve as an eDiscovery source. Microsoft 365 has products for those jobs and recruitment software is not one of them.

It will not read the company directory, enumerate distribution lists or index files. And it will not backfill historical mail automatically on connect; any import will be an opt-in operation over a date range you choose.

What you get

Microsoft Graph access

Connected through an application registration your administrator can review.

Narrow mail scopes

Mail read and mail send only; no contacts, files or directory permissions requested.

Separate calendar consent

Scheduling requests calendar access on its own so it can be granted or refused alone.

Tenant or user consent

Works with administrator-only consent policies or individual recruiter connections.

Shared mailbox support

A desk mailbox connects as its own source rather than through one recruiter's account.

Send-as respected

Sending from a shared address checks Microsoft's own send-as permission.

Contact matching

Only mail involving a known candidate or client contact is filed on a record.

Folder scoping

Choose which Outlook folders are in scope; archives can be left out entirely.

Reply detection

An inbound reply stops the cadence before the next scheduled message sends.

Bounce classification

Hard bounces mark the address; out-of-office replies do not halt a sequence.

Thread integrity

Conversations stay as one threaded object on the candidate or client record.

Detach without deleting

Remove a message from a record while leaving the copy in the mailbox untouched.

Conditional access preserved

Your multi-factor, device compliance and conditional access rules stay in force.

Bounded backfill

Historical import is opt-in over a chosen date range rather than automatic on connect.

Questions recruiters ask

Is the Outlook connector live?

No. It is in build for Wave 1 alongside the Gmail connector and cannot be enabled today. It shares the Gmail filing rules and reply detection; what differs is the Microsoft platform underneath and the administrative model. The status here changes to live only when it ships.

Can a shared desk mailbox be connected?

That is a planned first-class case. A shared mailbox connects as its own source rather than through one recruiter, so filed mail survives that recruiter leaving. Sending from the shared address will require the send-as permission Microsoft already governs, and the connector will respect it rather than routing around it.

What permissions will our Microsoft 365 administrator see?

Mail read and mail send. Calendar is a separate request made by the scheduling connector, and meeting creation is separate again in the Teams connector. Contacts, files and directory scopes are not requested at all, because recruitment software has no reason to enumerate your company directory.

Does filed mail follow our Microsoft 365 retention policy?

No. Mail filed on a candidate record inherits that record's retention window in Surhires, which may be shorter or longer than your Microsoft 365 policy. The two are not synchronised, and an erasure carried out in Surhires does not reach into your mailbox. That is a real limitation and we would rather name it here.

Will you keep our personal or internal mail?

Only mail involving a known candidate or client contact is filed. Internal mail between colleagues, and anything to an address not in your database, is ignored at ingestion rather than stored and hidden. You can also exclude addresses and domains and restrict the connection to specific folders.

Can we use this for eDiscovery or archiving?

No, and you should not. This connector files recruitment correspondence on candidate and client records. It is not a journaling target, an archive or an eDiscovery source, and Microsoft 365 has purpose-built tooling for all three that recruitment software has no business replacing.

See it against your own reqs

Bring one live role and three resumes. In twenty minutes you will see the match scores, the shortlist and the placement invoice that comes out the other end.