Identity joins the lifecycle
A company domain, person profile, provider ID, and CRM object ID may identify related things without being interchangeable. A record needs enough identity evidence to connect the observation to the intended operating entity. Consider a company that changes its domain. Treating the new domain as a wholly new customer can fragment history. Treating every similar name as the same company can merge unrelated businesses. The match policy must represent the actual identity boundary. Deepline tools and prebuilt Plays expose their own identity inputs. They do not supply one universal cross-system identity rule for every customer’s records.Working data and operating data have different roles
Source observations and intermediate comparisons can remain in customer working tables. A run dataset describes a particular execution. Approved CRM properties serve the people and processes that operate from them. These roles allow a later Play to reconsider evidence without immediately changing the operating record. A proposal can have a pending state while the CRM continues to show the last accepted value. Where data lives explains the storage boundaries. The platform’s own configuration, credentials, run status, and billing remain managed control state; customer SQL is not an alternative way to edit them.Policies connect one run to the next
Field ownership defines who may write. Provenance explains which observation supports a value. Freshness determines whether that observation remains useful. Acceptance rules decide which proposals can become operating facts. Those policies must be coherent across workflows. Two well-tested Plays can still disagree if they apply different precedence rules to the same CRM field. Versioning makes the disagreement inspectable, but does not choose the team’s preferred rule.Events and schedules supply different kinds of continuity
A Monitor contributes supported incoming events. A schedule supplies recurring execution at a configured time. Both can support ongoing work, but one is a source-data boundary and the other is an execution trigger. For example, a job-posting stream can support immediate account review, while a scheduled Play compares accumulated changes for a weekly report. Neither requires the authoring agent to remain in a conversation after remote work is accepted.Repair must preserve the original question
When a run fails, starting fresh without its input, version, and evidence can change the problem being investigated. When a business result is unresolved, blindly retrying the same sources may repeat usage without resolving the policy or identity gap. Execution recovery, data correction, and policy revision are therefore distinct operations. A repair should identify which one it is performing. This helps avoid turning an uncertain external write into another untracked attempt.Explore each boundary
- CRM governance: authority and competing writers.
- Provenance: evidence and observation time.
- Revenue data quality: fitness for a decision.
- Workflow observability: execution evidence.