Planned capability

Relationship software teams

Share connector infrastructure without merging ATS and CRM meaning

Plan one account, command, event, and provider-adapter layer beneath recruiting and customer products while keeping each product's records and permissions distinct. A candidate conversation and a sales conversation may use the same mailbox, but they do not have the same purpose, retention rule, workflow owner, or lawful basis.

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

Talk to us ↗Read technical guides →

Planned boundary

The shared publisher layer is an unreleased design

This ATS and CRM publisher use case is planned and not callable. DewEngine has no released candidate, contact, opportunity, requisition, inbox, mailbox, or messaging integration for a software publisher.

Current evidence: The repository proves a development tenant boundary, connected-account records, durable commands, canonical events, webhook delivery, and a partial SDK. It does not implement ATS or CRM entities, shared-person resolution, customer identity, application roles, or released communication connectors.
Target contract: Let a publisher map one DewEngine workspace and connected account to its own tenant, user, product, and record context without exposing provider credentials; Return communication resources with stable provider lineage while the publisher owns candidate, contact, company, job, and opportunity associations; Apply product-specific permission, purpose, approval, suppression, and retention before a shared connector accepts any write
Known limits: DewEngine will not decide that two records represent one person or that data collected for recruiting may be reused for selling; Shared infrastructure does not remove channel eligibility, provider terms, consent duties, regional employment rules, sales communication law, or separate deletion obligations
Release gates: Release authorized mailbox, messaging, and scheduling verticals with account-scoped read, write, event, reconnect, and deletion evidence; Implement publisher applications, delegated roles, product-purpose policy, record-association provenance, and cross-product isolation tests; Validate retention, export, correction, consent, suppression, and audit flows with ATS and CRM design partners separately

Architecture choice

Reuse the connector plane, not the business schema

DewEngine's planned common layer can own provider authorization, account health, native identifiers, command execution, synchronization, and webhook delivery. The publisher should keep requisitions, applications, deals, lifecycle stages, and task logic in its domain. This boundary avoids forcing two mature products into a lowest-common-denominator relationship model.

Carry publisher record references as scoped metadata, not connector authority
Keep recruiting and commercial workflow engines outside DewEngine

Implementation mapping

Resolve tenant, user, purpose, then account

An action request should arrive from an authenticated publisher application with its customer tenant, acting user, product surface, purpose, and target record. DewEngine resolves the authorized workspace and connected account before capability checks. The resulting command and event carry that correlation so an audit can explain which product initiated the provider action.

Reject account IDs owned by another publisher tenant or product context
Store immutable origin metadata for write-side investigations

Record association

Keep one provider identity linked to many contexts safely

The same email address or professional profile may appear as a candidate, customer contact, former employee, or hiring manager. Rather than collapse those records, the publisher can create purpose-bound associations to a source identity. Corrections and unlinking remain possible, and activity is shown only where the product's access and retention policy permit it.

Represent associations with source, confidence, reviewer, and effective dates
Do not copy historical content merely because identities match

Permission boundary

Evaluate the product rule before connector capability

A provider account may technically permit a reply while the ATS role, CRM territory, suppression list, or purpose rule forbids it. The publisher makes that business authorization and passes a bounded decision to DewEngine. Connector capability is the second gate; neither layer should interpret the other's approval as consent for a different workflow.

Log product authorization and provider eligibility as separate decisions
Recheck access when a queued command reaches dispatch

Adoption proof

Qualify each product with its own failure journeys

ATS testing should cover candidate erasure, shared recruiting mailboxes, interview changes, and restricted hiring roles. CRM testing needs ownership transfer, opt-out, merged contacts, territory changes, and opportunity retention. Both need duplicate events, disconnected accounts, and unknown provider outcomes, but success in one product cannot stand in for the other's acceptance evidence.

Run purpose-specific fixtures through the shared adapter contract
Measure cross-product isolation before enabling a common account

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.

Would DewEngine become the system of record for candidates and customers?+

No. The planned layer owns communication integration state. The ATS and CRM remain authoritative for their domain records, permissions, workflows, and relationship decisions, with scoped references connecting those records to provider resources.

Can recruiting communication automatically appear in the sales product?+

Not merely because an identity matches. The publisher must establish a valid product purpose, permission, retention basis, and explicit association. The safer default is isolation between recruiting and commercial histories.

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 ↗