A natural key, or business key, identifies a record in the source system's own terms, such as a customer number, an email address or an order id. It is what people search by and what merges match on. Natural keys can change, be reused or collide across sources, which is why models often add a surrogate key.
For example, an online shop identifies customers by an account number such as C-104233, and its order system identifies them by email address. Both are natural keys: they mean something in the source, people use them in support tickets, and they arrive in every extract. A model that combines both systems has to decide how the two keys relate, and what happens when a customer changes their email address, which breaks every join on the old one.
Good natural keys are unique, never null, never reused and stable over time, and few real ones meet all four. Composite natural keys are common, such as a store number plus a receipt number, because a receipt number alone repeats across stores. Keys from different sources can collide, so combined tables often prefix them with a source code, such as shop:C-104233.
In a model, the natural key is kept as an ordinary column next to the surrogate key, so people can still look records up the way they know them, and change data capture and merges can still match incoming rows. Uniqueness of the natural key is one of the first data quality tests worth writing. See also dimension.
When natural keys are combined across systems, a mapping table is common: one row per source key, pointing to the shared surrogate key, with the date the mapping was made. It keeps the history of how records were matched, which helps when two customers turn out to be one, or one turns out to be two. See also deduplication.
Emolysis's CDC merge, SCD Type 2 and Dedupe / conform templates take the key columns as a typed slot. A key that looks stable can still change, for example when a customer number is reissued after two accounts are combined.