Source field

What is a source field?

A source field is a field exactly as it exists in the system that produced it, with its own name, data type, length and encoding, before anything has been mapped or transformed. It can be a column in an operational database, an attribute in an API response, or a column in a CSV export.

The source field is where data lineage starts. When a figure turns up in a report, you should be able to trace it back to the source field it came from and every step in between. A source field is also the counterpart of a target field: one is where the value is read, the other is where it lands after mapping.

Its name rarely means anything to the business. An ERP might call a customer number KLANT_NR, a CRM acc_no and a webshop customerRef. Part of the job of a data dictionary is recording which source field answers to a business term such as customer number.

How a source field is captured in mapping

Integration work is written down in a source-to-target mapping, sometimes called an STTM or an ETL specification. Each row of that document describes one source field and where it goes.

For the source side, a mapping row usually records:

• the source system, table or file, and the exact field name.

• its data type and length, such as char(10) or date.

• a plain-language description of what the field holds.

• constraints: whether it can be empty, and whether its values come from a code set.

From there a mapping rule connects the source field to a target field, a derivation rule builds a value out of more than one source field, a validation rule checks the incoming values, and a data transformation reshapes them. Tools encode the same pattern. The AWS Glue ApplyMapping transform, for example, takes tuples of source column, source type, target column and target type, and casts the source type to the target type.

A worked example

Take an ERP field KLANT_NR, defined as char(10). Because it is text, a value like 0000012345 keeps its leading zeros. In the data warehouse the target field is customer_id.

How you map the source field decides whether that identifier survives. Cast KLANT_NR to an integer and 0000012345 becomes 12345; the leading zeros are gone, and a join back to the ERP no longer matches. Keep it as text and the identifier stays intact. The exact type and encoding of the source field, recorded before any mapping, are what let you make that call correctly.

What to watch out for with source fields

Source systems change. When someone renames KLANT_NR or switches it from text to a number, any mapping tied to the old name or type breaks. This is schema drift, and integration pipelines are exposed to it because they read fields by name. Some tools cushion it: in Azure Data Factory mapping data flows, a newly appeared column arrives as a string until you ask the tool to infer its type.

One more point worth keeping straight is that a source field is not automatically the authoritative value. The same customer number can live in several systems, and master data management decides which copy wins. A source field tells you where a value was read, not that it is right.