Data Job
What It Is
A data job is the continuing account of work requested across a set of records. It connects the request to its processing and results, so staff can inspect a bulk change after the screen that launched it has closed. A contact update, a file import and a supported catalogue change can all produce this kind of account. The records affected by the request still belong to their own product areas.
Submission gives the job an identity and retains its input context. Some input is stored with the request, while file processing starts from a completed upload. Staff can therefore distinguish the requested work from later edits to the source material or destination records. Progress and record outcomes remain attached to the job, including when only part of the input is eligible.
What It Is Not
A job does not establish a new identity for every contact it changes. Nor does it replace those contacts’ history. An export serves a different purpose: taking information out. A migration run coordinates several datasets and relies on the individual jobs beneath it. Background execution machinery drives processing but is not the account staff inspect.
How It Is Used
Administrators launch supported changes from list dialogs or file-import tools and follow their jobs in Data Imports. Integrations submit work through the API and inspect its outcome. Implementation staff encounter jobs as the dataset work beneath migration runs.
Good use includes reviewing available impact information, checking refusals and understanding which recovery action fits the problem. A malformed input value needs correction, while a missing dependency may need another dataset first. A job’s overall state is useful context, but its individual outcomes explain what actually happened.
Its Facets
Record kind and operation. These identify the domain contract responsible for the target records and the requested change.
Processing lane and review mode. Together they describe how input is supplied and whether the chosen surface supports a preview before application. A file is not automatically eligible for every review mode.
Progress state and batch organization. They let staff distinguish waiting from active processing and understand why interruption can leave earlier changes intact.
Impact fingerprint and submission identity. One connects approval to a retained preview; the other lets a caller distinguish a repeated request from new work.
Available controls and related work. These explain how inspection, correction and restoration remain separate operations linked to the original request.
Record outcomes. These are a facet of the job rather than a separate broad concept. They retain the evidence needed to inspect individual input, including successful work and reasons that other work did not proceed.
How It Relates
Uploads supply file input, producer identities support reconciliation, and migration runs coordinate related datasets. Capacity protection influences admission of bulk work. Record-owning modules provide their own validation and write behavior. The job connects these participants into an inspectable operation without taking ownership of their domain records.
What It Could Become
Product still needs to review large-file previews, retention enforcement and the planned tools for investigating very large result sets. A richer account of excluded restoration records would help staff understand recovery. Those extensions should continue to distinguish a requested operation, its individual evidence and the destination records it affects.