Personal data

Each pipeline decides what happens to personal data, in the Tables step (and later from Change → Tables and columns or the Data tab's Tables and personal data). When you pick a table, every column whose name looks like personal data (email, phone, address, birth date, card, IBAN, passport, tax or national ID numbers) is protected at once, and the Personal data card lists them with one choice each:

• Mask: replaced by a salted SHA-256 hash, unique to the pipeline, so equal values still match for joins. Debezium hashes text columns only, so Mask is offered only for those (MongoDB can't hash at all).
• Remove: left out of every event. Columns that can't be hashed are removed by default.
• Keep as is: sent unchanged, on purpose; the choice is recorded in the spec (keep).

Protect another column masks or removes any other column of the captured tables; Choose for all sets every row at once. Choices you made are never changed when you come back to the step.

Final checks (Configuration) back this up: a masked column that can't be hashed blocks the deploy (it would leak), personal-data columns nobody decided on (pipelines made through YAML, the API or MCP) are a warning naming them, and a rule on a column that was renamed or dropped is a warning. A new column that looks like personal data shows as looks like personal data · sent as is in the Data tab's schema changes until you choose. In YAML:

columns:
  public.customers: {mask: [email], exclude: [birth_date], keep: [phone]}

Earlier releases had a project policy, "Require masking personal data"; it was replaced by these per-pipeline choices and is accepted but ignored when sent to the API.