Content Onboarding Checklist: From Source File to Production Catalog
A gate from an incoming source file to a production record: intake, validation, missing assets, and a written readiness rule.
- 01 Accept the source
- 02 Validate the record
- 03 Resolve the gaps
- 04 Mark readiness
Treat intake as a gate, not a folder
Onboarding is the controlled path from a source file to a record the production catalog is allowed to hold. A drop folder is not that path. If every file that lands in the folder becomes a record, the catalog’s boundary is whatever a partner chose to send.
Name the source before you open the columns. Source means who sent the file, when it was sent, and which record type it claims to fill. A file with no sender is not ready to parse. Store it aside and ask. Guessing the sender creates a record nobody can correct later.
This gate sits inside the workflow that names the catalog. Onboarding does not redraw that boundary. It asks whether this file is inside a boundary that already exists.
This diagram scrolls sideways on a narrow screen.
Accept the file only with a minimum header
The minimum is operational, not a universal schema. For this publication’s method, do not parse a file into candidate records until you can answer:
- Which partner or internal system sent it?
- Which record type does it claim to create or update?
- Which field in the file is the identifier you will compare with the catalog?
- What should happen to a row that fails: stop the file, or stop only that row?
Write those answers on the intake record. If the fourth answer is missing, people will improvise during the first failure, and two files from the same sender will be treated differently.
A row that fails does not enter the production catalog “temporarily.” Temporary records become the catalog. Either the row waits outside, with the failure attached, or it meets the readiness rule.
Validate before you enrich
Validation checks the row against rules you already published: identifier present, required fields present or explicitly empty where empty is allowed, controlled values in the current vocabulary, and dates in the agreed form. Enrichment adds or rewrites values. If you enrich first, you can no longer see what the source actually sent, and a later dispute becomes a guess.
Keep the source values when policy allows it. When policy does not allow a copy of the raw file to remain, record the hash or the file name and the list of fields you accepted. The point is to be able to say “this value came from the source” or “this value was written here during onboarding.”
Which fields have to be filled is the metadata half of validation. Do not invent a second required-field list for onboarding. Point at the same list, and name the version. A file checked against last quarter’s list will pass and then fail at release.
Separate missing assets from missing fields
A missing image, document, or media file is not the same failure as an empty metadata field. The metadata field might be optional. The asset might be required for a particular channel and irrelevant for another. Write that down per asset type.
When an asset is required and absent, the record is not ready for the channel that requires it. You can still hold the record outside production, with the gap named. Do not publish a placeholder asset that looks like a real one. A stand-in image teaches every downstream system that the asset exists.
W3C Best Practice 22, in the Data on the Web Best Practices recommendation of 31 January 2017, says that for data that is not available, provide an explanation of how the data can be accessed and who can access it. The recommendation is about datasets on the web, including gaps in what was published. The narrower lesson for a catalog file is: if an asset or a field will not be available, say so, and say whether anyone can obtain it. Do not leave a blank that could mean “not supplied,” “not applicable,” or “lost.”
This table scrolls sideways on a narrow screen.
| Gap | What to record | Can the record become ready? |
|---|---|---|
| Missing required field | Field name and rule version | Only after a value passes that rule |
| Invalid controlled value | The value and the vocabulary version | Only after it maps to a current concept or is removed |
| Missing required asset | Asset role and channel | Not for that channel, until the asset arrives |
| Missing optional asset | Asset role and the fact that it is optional | Yes, if no channel requires it |
| Unknown identifier | The identifier and that no catalog record matched | Only after create-versus-update is decided |
Decide create, update, or stop
An identifier match is not automatically an update. The row might be a duplicate, a conflict, or a new record that reused a code. Those cases are easy to smash together and expensive to undo. The guide on how duplicate and conflicting records are separated is the decision procedure. Onboarding’s job is to stop and hand the row to that procedure instead of picking the newer timestamp.
If there is no match, the row is a candidate create. It still needs the readiness rule. “No match” is not readiness. It only means you are not about to overwrite someone else’s record by accident.
Write the readiness rule in advance
Readiness is a list of conditions, not a feeling that the row looks complete. A useful rule names:
- the metadata checks that must pass
- the assets required for the channels in scope
- the duplicate and conflict checks that must be clear
- the owner who is allowed to move the record into the production catalog
If any condition fails, the record stays out. Say which condition failed. “Not onboarded” is not a status a release owner can act on.
What onboarding does not include
It does not negotiate a contract with the sender, choose the commercial terms, or design the taxonomy. It does not promise that a complete file is factually right. It does not set a service level for how fast a partner must reply. Those are local agreements. Publishing a made-up turnaround time would be a false operational claim.
The checklist is the publication’s method for keeping unready rows out of the production catalog. Teams can rename the gates. They should not collapse them into a single import button.
When a row may move on
When can a partial file enter production?
When every failed condition is optional for the channels you are about to publish, and the gaps are recorded. A partial file is not a temporary production record.
When needed: After the readiness list is scored, not when the deadline is close.
When should the whole file stop?
When you cannot name the sender or the identifier field, or when the agreed rule says one bad row fails the batch. Otherwise stop the row and continue.
When needed: At intake, before rows are turned into candidates.
When is enrichment allowed?
After validation has stored what the source sent. Enrichment that rewrites the only copy of a source value destroys the audit of the gate.
When needed: On rows that already have a pass or a named failure.