Record Outcome
What It Is
Record outcomes describe what happened to the input of a data job. The first planning draft treated them as a broad concept of their own. This examination folds that explanation into Data Job because an outcome has no independent staff purpose outside the requested operation. This superseded artifact keeps its permanent identity and historical references; active feature and capability declarations use the parent concept.
The distinction still matters when staff inspect work. A job can contain several kinds of result, and its summary alone does not explain every input row. The outcome facet supplies that detail. It gives administrators a way to connect a position in submitted input with an application, refusal or other processing result without creating another domain record for staff to maintain.
What It Is Not
Outcome evidence does not replace a contact’s version history or an organization’s current values. It describes the job’s handling of input. A job state describes the overall processing phase, while an individual outcome explains one part of that work. These views answer related questions and should not be treated as interchangeable measures of success.
How It Is Used
Staff inspect the parent job’s result and refusal views when a bulk operation finishes or needs attention. Integrations use the same evidence to decide whether input should be corrected or a missing dependency loaded. Restoration planning uses committed work to assess what can be put back.
The useful question is what follow-up the result calls for. Correcting an invalid value, reviewing another person’s edit and waiting for a parent record are different tasks. Retaining those distinctions helps staff choose the appropriate capability instead of sending every unsuccessful input through the same retry.
Its Facets
Applied and skipped input. These distinguish successful processing from input that did not need another application. Where a domain supports unchanged detail, staff can tell that successful handling did not necessarily create another record revision.
Refusals and conflicts. These identify input problems or destination changes that require review. Their safe explanations support follow-up while keeping record values outside the refusal account.
Dependency blocks and unattempted work. These explain input waiting for a prerequisite or never reached after interruption. They should not be interpreted as equivalent to malformed input.
Receipts and aggregate protection. Committed evidence supports deduplication and restoration assessment. Aggregate outcomes also inform the parent job’s guard against unsuitable input.
How It Relates
The active home is Data Job. Producer identity mappings help explain duplicate and stale delivery outcomes, while destination history helps restoration planning inspect later changes. Migration runs summarize their child jobs without becoming an alternative ledger for each input record. Those relationships remain useful even though this separate concept is retired.
What It Could Become
Future result search and server-built exports belong with the job’s inspection capabilities. Product can also improve explanations for unchanged work and restoration exclusions. Any extension should develop the parent’s outcome facet rather than revive a separate concept merely because receipts and refusals have physical storage of their own.