> ## Documentation Index > Fetch the complete documentation index at: https://deepline.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Understanding sales operations automation > Why enrichment evidence, sales policy, and customer-facing actions need different decision boundaries. Sales operations automation acts on records that people use to sell and serve customers. A faster update is useful only if it preserves the meaning of those records: who owns the account, what the team knows, and what action is justified. The key distinction is between gathering evidence and exercising commercial judgment. ## A job change is evidence, not an automatic routing decision Suppose a known contact appears at a new company. A source observation can suggest that employment changed. It does not by itself establish whether the old opportunity should close, whether the new account belongs to another rep, or whether the team should contact the person. A Play can evaluate the source identity and proposed update, then apply an explicit team policy. A Monitor can supply supported change events. Neither component infers the team's territory, opportunity, or outreach rules. This distinction lets the automation remain useful even when the correct outcome is a proposal for review rather than an immediate CRM change. ## Low-risk transformations and commercial fields differ Normalizing a domain or preserving a verified source value can often follow a deterministic rule. Changing ownership, stage, or communication may depend on context outside the enrichment response. The boundary should follow the consequence and policy, not whether a tool exposes an update endpoint. A connected integration establishes technical access; it does not establish that a particular Play has business approval to exercise every capability. ## Existing records matter to the interpretation Creating a contact is different from updating one. A missing email does not prove that the person has no existing CRM record. Matching on a weak signal can create a duplicate or modify the wrong object. A stable destination ID helps connect the write to the intended record. Where identity remains ambiguous, retaining candidates and their evidence is more informative than selecting one silently. The workflow must implement that policy; the platform does not supply universal customer ground truth. ## A completed action can still need verification An update response may not describe every property that the destination ultimately stores. Mapping, permissions, or concurrent edits can affect the observed state. The useful outcome is therefore the accepted change and its verification, not just a request count. A timeout after submission is uncertain. Repeating it can create another task or message unless the destination's idempotency contract or a reconciliation process protects the intended action. A run ID identifies Deepline work, but is not automatically an idempotency key recognized by the CRM. ## Human review should resolve a specific uncertainty A review request is most useful when it supplies the original record, proposed change, evidence, and reason the rule could not decide. Sending every raw response to a person merely moves the interpretation problem downstream. For example, a rep could decide whether a job change warrants a relationship handoff while the Play has already resolved the person and company evidence. That keeps the commercial judgment distinct from the data-gathering work. ## Apply this understanding * [Job changes and CRM cleanup](https://deepline.com/docs/plays/play-job-change-alerts.md). * [CRM repair guide](https://deepline.com/docs/guides/crm-data-quality-automation.md). * [HubSpot enrichment](https://deepline.com/docs/guides/hubspot-enrichment-workflows.md). * [Production integration](https://deepline.com/docs/sdk-v2/production-integration.md): verify and reconcile destination actions. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.