Run an in-house hiring loop inside the tool your company already runs

An agency desk has a recruiter, a client contact and a candidate. An in-house requisition has a hiring manager, a second interviewer, a panel, a finance approver for the headcount, sometimes a legal reviewer for an offer, and a talent coordinator holding it together.

Most of those people will never open a recruitment system. They will approve a requisition in a chat message, give interview feedback in a hallway, and ask the coordinator where things stand. The information the process needs is generated outside the system and then typed back into it, badly, by whoever has time.

The Teams connector is aimed squarely at that gap: put the event where the people are, and put the link back to the record next to it.

The part of this connector that is not just notifications is meeting generation. When an interview is scheduled in Surhires, the planned behaviour is that a Teams meeting is created against the organiser's calendar and the join link is attached to the interview record, the panel invitations and the candidate confirmation.

That closes the most common coordination failure in corporate hiring, which is a confirmed interview with no working link, discovered four minutes before it starts. It also means a reschedule updates one meeting rather than creating a second one and leaving the candidate holding two links.

Recordings and transcripts, where a tenant enables them, stay in Microsoft 365 under your retention policy. The product will link to them rather than copying them.

Channel posts will follow the same rule as the Slack connector. Events and links, not personal data. A requisition opened, a candidate submitted to a hiring manager, an interview booked or slipped, an offer issued or accepted, a start date confirmed.

Candidate contact details, resumes, salary expectations and any demographic data will stay inside the product. Demographic data used for equal-opportunity reporting is stored separately from the hiring record and is not visible to recruiters at all, which makes it categorically unsuitable for a chat channel that half the department can read and export.

The link in the post resolves against the product's permission model. A person without a seat, or with a seat but without rights to that requisition, follows the link and sees nothing.

The connector will install as a Microsoft Teams app, authorised by a Microsoft 365 administrator, with a permission scope limited to posting into nominated channels and creating meetings for consenting organisers. Corporate IT will be able to review the scopes before approving, which is the normal gate for anything entering a Microsoft 365 tenant.

For organisations that restrict third-party apps, the connector will be optional rather than load-bearing: the product works without it and the notifications fall back to email digests and the in-product task list.

The Teams connector and the Outlook connector are separate build items with separate permissions, and both are in development for Wave 1. Meeting creation touches the calendar, and calendar access is requested as its own consent rather than bundled into a mailbox permission.

That separation is deliberate. A talent team frequently wants interview scheduling on the calendar without granting mailbox access, and an IT administrator is far more likely to approve two narrow scopes than one broad one.

It will not be an approval workflow engine. Requisition approval chains that live in a corporate finance system stay there; the connector announces the state, it does not become the system of record for a headcount sign-off.

It will also not import your Teams chat history or read messages. There is no product reason to read a corporate chat archive, and asking for that scope would fail the first IT review it met.