Keep the hiring team in the loop without buying them seats

Most agencies and in-house teams have three or four people who work in the recruitment system all day and fifteen who need to know things occasionally. The hiring manager wants to know when a candidate has been submitted. The delivery lead wants to know when an interview slips. The account owner wants to know when an offer goes out.

Giving all fifteen a licensed seat is expensive and, worse, it does not work: people who visit a system twice a month never learn it, so they ask by direct message anyway. The channel is where those people already are.

A Slack post that carries the fact and a link is a better fit for occasional participants than an account they will not log into. The people who need the record still get the record; the people who need the signal get the signal.

The planned event set follows the pipeline rather than the database. A submittal goes out and the channel is told which requisition and which client, with a link. An interview is booked, moved or slipped. An offer is issued, accepted or declined. A requisition crosses an ageing threshold. A placement enters or leaves its guarantee window.

Routing will be per channel, so a client-specific channel receives only that client's events and a delivery channel receives the roll-up. The mapping is configuration, because a single firehose channel gets muted within a week and then nobody sees anything.

Candidate personal data will not be pushed into a channel. Not the phone number, not the email address, not the resume, not the salary expectation, not the demographic fields, not the consent basis. A Slack channel is a wide-membership, long-retention, exportable surface, and it is the wrong place for the personal data you hold as a controller.

What the post will carry is a reference and a link. Somebody with a seat and the right permissions follows the link and sees the record; somebody without does not. This keeps the permission model in one place instead of duplicating it into a chat tool that does not know your field-level rules.

This is also why the connector will not offer a general candidate search slash command in Wave 1. Searching a candidate database from a channel sounds convenient and quietly turns the channel into an export of the database.

The connector will install as a Slack app authorised by a workspace administrator, with a scope request limited to posting into the channels you nominate. It will not request read access to your message history, because it has no reason to read anything.

Channel mapping will be configured in Surhires rather than in Slack, alongside the alert thresholds that already drive the pipeline exception view. An alert that is too noisy is turned down where the threshold lives, not by muting a channel and losing everything else with it.

Pipeline exceptions already exist in the product. They surface in the exception-first board view and in the recruiter task list, and they carry the next action rather than just the fact. The Slack connector is a delivery channel for those same events, not a second alerting system with its own rules.

That matters for a practical reason: when the connector ships, you will not be configuring alerts twice. The thresholds you have tuned in the pipeline view are the thresholds that drive the channel posts.

Wave 1 is the target. We are not publishing a date on this page, because a date on a marketing page becomes a commitment made by a writer rather than by the people building it.

What we will do is keep the shipping status page current. When the connector moves from in development to live, the state on this page changes and the evidence line names the functions that carry it, in exactly the way the WhatsApp and Twilio pages do today.