Planned capability

Recruiting workflow

Connect candidate communication without automating judgment

Plan a recruiter workspace that joins authorized sourcing context, candidate conversations, and interview coordination while leaving hiring decisions with accountable people and the ATS. DewEngine should carry communication evidence and account state; it should not rank candidates, infer protected traits, or decide who advances.

Illustrative product surface. The workflows below are planned, not a live connector.

Talk to us ↗Read technical guides →

Planned boundary

The recruiting solution has no released workflow

This recruiting scenario is planned and not callable. There is no customer candidate inbox, professional-profile connector, recruiter messaging path, ATS synchronization, interview workflow, or automated candidate action in DewEngine.

Current evidence: Development code proves tenant-scoped account and command primitives plus one feature-flagged Calendar create path against fake-provider evidence. It does not implement Calendar availability or updates, messaging providers, mail synchronization, candidate identity, interview state, recruiting roles, or production Google access.
Target contract: Associate authorized provider identities and threads with an ATS candidate through reviewable source evidence rather than irreversible name matching; Require recruiter role, job context, outreach purpose, candidate preference, and channel eligibility before any communication command; Represent interview requests and provider-confirmed changes as scheduling evidence while the ATS remains authoritative for hiring stage and decision
Known limits: DewEngine will not evaluate candidate suitability, infer sensitive attributes, recommend a hiring outcome, verify résumé claims, or guarantee identity matches; Employment law, retention, accommodation, consent, provider terms, candidate experience, and bias controls remain responsibilities of the recruiting product and employer
Release gates: Release qualified mail, calendar, and approved professional messaging capabilities with candidate-safe retention and deletion; Implement recruiter roles, job-purpose scoping, identity-review provenance, communication preference, approval, and accommodation-safe audit controls; Prove interview lifecycle, reply handling, duplicate prevention, reconnect, export, and candidate erasure with recruiting design partners

Candidate experience

Keep the job and acting recruiter visible

Before contact, the product should show which recruiter account will act, which job provides the purpose, how the candidate identity was associated, and whether prior preference or suppression blocks the channel. This context reduces duplicate approaches and makes a handoff between recruiters understandable to the candidate and the hiring team.

Record the requisition and recruiter behind each approved action
Do not reuse candidate contact data for an unrelated opening automatically

Implementation mapping

Keep ATS stage outside the communication adapter

The ATS submits a tenant-scoped candidate reference, requisition, acting user, connected account, and approved operation. DewEngine returns resource and command identifiers that the ATS can attach to its timeline. Provider events carry the same correlation, but they do not change application stage until the ATS evaluates its own workflow and permissions.

Minimize candidate fields copied into provider job payloads
Reject callbacks that cannot resolve the original tenant and account

Interview coordination

Treat calendar creation as one step, not scheduling proof

A useful interview flow also needs calendar discovery, organizer rights, availability, time zones, recurrence limits, conferencing, attendee notifications, updates, cancellations, and provider-originated changes. The repository's isolated timed-event create evidence covers none of that complete lifecycle, so the solution must remain behind its release gates.

Show notification behavior before an invitation is approved
Reconcile attendee-facing writes after ambiguous provider outcomes

Decision boundary

Use communication data for coordination, not hidden scoring

Response time, writing style, calendar availability, or profile completeness can reflect disability, location, caregiving, language, access, and many unrelated circumstances. DewEngine should not convert those observations into candidate rankings. If a product derives decision features, that separate system needs explicit governance, explanation, testing, and accountable human review.

Exclude inferred hiring scores from the connector contract
Keep protected and sensitive data out of routine diagnostics

Release proof

Test privacy and recovery from the candidate's side

Qualification should cover duplicate profiles, shared recruiter mailboxes, withdrawn applications, preference changes, access requests, erasure, rescheduled interviews, expired authorizations, and messages arriving after a stage closes. Reviewers should verify both operational recovery and what the candidate sees, including sender identity and correction paths.

Run deletion through source observations, attachments, and derived indexes
Make every automated hold or refusal explainable to the recruiter

Illustrative contract

Preview the intended integration boundary.

This shape documents the intended account and resource boundary. It is not callable, and it does not generate provider traffic.

Explicit connected-account ownership
Stable public resource identifiers
Truthful provider outcome state
Release status beside every capability

Illustrative shapePlanned · not callable

const unreleasedContract = {
  resource: "message",
  account_id: "acc_example",
  provider: "target_provider",
  availability: "not_implemented"
} as const;

No live connector · no provider request

Questions

Before you build.

Will DewEngine score or rank applicants from their communication data?+

No. The planned integration boundary transports authorized communication and scheduling state. Candidate evaluation, employment decisions, explanations, and any legally required human review remain outside DewEngine.

Is the Calendar development slice enough to run interview scheduling?+

No. It proves one isolated timed-event create path only. Discovery, availability, updates, cancellation, conferencing, recurrence, attendee lifecycle, notification semantics, production OAuth, and real-account conformance remain open.

Build with us

Does this match the workflow your users need?

DewEngine is in development. Real use cases decide what ships first.

Share your use case ↗