Mask PII — personal data protection | ATX AnalyticsTable Docs

Mask PII — personal data protectionScanning for personal data and masking it by redaction, partial masking, hashing or synthetic values. Replaces personal data in the columns — or the RANGE — you choose. Four methods, chosen per column: REDACT writes a fixed run of mask characters (fixed, so the mask cannot leak the length); PARTIAL keeps a fragment — the domain of an e-mail, the last four of a card, the year of a birth date — and masks the rest; HASH writes a stable token, so the same customer matches on every row and joins and distinct counts still work; SYNTHETIC writes a plausible fake of the same shape, with checksum-valid IBANs, cards and PESELs, for demos and test extracts.

Overview

Open the masking dialog: Transform → Privacy → Mask PII
Replaces personal data in the columns — or the RANGE — you choose. Four methods, chosen per column: REDACT writes a fixed run of mask characters (fixed, so the mask cannot leak the length); PARTIAL keeps a fragment — the domain of an e-mail, the last four of a card, the year of a birth date — and masks the rest; HASH writes a stable token, so the same customer matches on every row and joins and distinct counts still work; SYNTHETIC writes a plausible fake of the same shape, with checksum-valid IBANs, cards and PESELs, for demos and test extracts. Opening the dialog scans the first 200 rows and pre-ticks what it recognises — e-mail, IBAN, card, PESEL and postcode by their format, names and customer numbers by the column name in Polish or English — all set to Redact, all yours to change. Hash and synthetic derive from a random key stored in the project, which is what makes them repeat across sheets and runs and what stops the tokens being recovered by hashing a candidate list. MASKING IS ONE-WAY: nothing here brings the originals back, so keep an unmasked copy first. It is also not anonymisation — see the Privacy tab of the manual for what a masked file still gives away.
Requires: A sheet with columns. At least one column ticked. Opens on the current selection when there is one, so select the table first to mask just that block.
Grid data (typed, pasted or imported cells) — Masks in place, or writes masked copies into new columns.
Preview pin (live, paged query result) — Refuses — a live pin is a read-only sample. Switch it to static first.
Static pin (full query result loaded) — Masks the pinned values in place; a refresh restores the originals, so put the masking in a pipeline if it should be re-applied automatically.

Mask PII — what it is for

Transform tab, Privacy group, "Mask PII". It replaces personal data in the columns or the RANGE you choose with something you can safely keep looking at, so that an extract you need for analysis, a demo or a screenshot can leave your machine without the people in it leaving with it. It works on ordinary grid data, on STATIC pinned data, and as a pipeline step that re-masks every time the pipeline runs. It cannot REPLACE values under a LIVE (preview) pin: a live pin holds one page of a query and is a read-only sample, so the dialog blocks the apply and tells you to switch the pin to Static or convert it to grid data first.
It can read one, though — the third output, a masked copy written at a cell you point at, touches nothing under the pin and so is allowed there, which is how you get a safe block out of a live import without changing the import. Masking is ONE-WAY. The original values are replaced and nothing in the project can bring them back — that is exactly what makes a masked file safe to send on, and it is why you should keep an unmasked copy of anything you still need before you mask.
There is deliberately no "unmask" button and no stored map back to the originals: a project file that held that map would contain precisely the data it appears to have removed.

What gets masked: whole columns, or a range

The dialog offers two scopes and the choice matters more than it looks. WHOLE COLUMNS is the simple case: every row of the columns you tick, top to bottom. A RANGE is a rectangle — the block you had selected when you opened the dialog, which is what it starts on, or one you pick or type afterwards. Use a range whenever the sheet holds more than one thing. A sheet with three tables stacked in the same columns is completely ordinary, and masking "the name column" there reaches into the two tables you did not mean; that is data loss wearing the costume of privacy, and it is the reason the range option exists rather than a convenience.
A range also bounds the rules: a rule for a column outside the rectangle is ignored, so what you picked really is the limit of what can be reached. FIRST ROW IS A HEADER. A range usually starts at a table’s header, and a header is a column NAME, not personal data. Ticked (and it is ticked automatically when the first row looks like a header), that row is left unmasked, kept out of the scan, and — this is the useful part — its TEXT becomes what the scan reads instead of C1, C2, C3.
A table pasted onto a blank sheet has columns called C1 and C2, which tell the detector nothing; the words that would have helped, "Nazwisko" and "E-mail", are sitting in its header row, and this is what puts them to work. Check the guess before you apply. A header masked by mistake leaves a table nobody can read, and a data row mistaken for a header is one person who quietly escaped masking. The guess is deliberately cautious: it needs every cell of the first row to be non-blank text and at least one column below it to disagree in a way a header explains — numbers under a word, e-mail addresses under a label.
A block of plain text columns with no numbers and no recognisable formats gets "not a header", because nothing distinguishes "Surname / Kowalski" from "Kowalski / Nowak" and the safe guess is to mask the row. Masking a range writes in place. If you choose a masked copy in a new column instead, only the rows in the range get a value and the rest of the column stays empty — the honest rendering of "this block was masked, the rows above and below were not in the selection".
THERE IS A THIRD OUTPUT, and it is the one most people are actually after: "Masked copy at a cell you point at". Pick a cell and the whole block in scope is written there again — every column in the same order, the ticked ones masked, the rest carried through, a header line on top — while not one original cell is touched. What lands is a TABLE: you can select it, sort it, chart it, export it, send it. The new-column output cannot do that, because it leaves the safe values and the personal ones in one table with the reader expected to pick the right half, and it is refused on a sheet with pinned data since inserting a column would shift the pin.
A copy is written nowhere near the source, so nothing about the source restricts it — it is the only output that works over LIVE (preview) pinned data, which makes "mask this live import into a safe block over here" a thing you can do at all. It uses the project’s own key, so a hash in the copy is the same token an in-place mask would have produced. Writing to the same cell again replaces the copy that is there. The warning is unchanged and matters more here than anywhere: a copy leaves the originals where they were, so what leaves the building is the COPY, never the sheet holding both.

The scan — what gets ticked for you, and how much to trust it

Opening the dialog scans the first 200 rows IN SCOPE — the range you chose, header row excluded, or the whole sheet when you are masking whole columns — and pre-ticks the columns it recognises. Each suggestion carries a badge saying how it was found, and the two are worth different amounts of trust. "by value" means the CELLS proved it: the values match the format and, where there is a checksum, the checksum passes — an IBAN that verifies, a card number that passes Luhn, a PESEL whose eleventh digit is right, an e-mail address, a Polish NN-NNN postcode.
Those are close to certain. "by name" means only the COLUMN NAME suggested it, because no format can tell a surname from a city: headers in Polish and English are both recognised, so imie, nazwisko, adres, telefon, kod_pocztowy, nr_klienta, data_urodzenia sit alongside first_name, surname, address, phone, postcode, customer_id. On a range with a header the words come from the HEADER ROW rather than from the sheet column, which is the only thing that makes a pasted table — all of whose columns are called C1, C2, C3 — recognisable at all.
Those are guesses and deserve a look. Values always outrank the name: a column called "notes" full of e-mail addresses is treated as e-mail addresses, and a column called "email" full of order references is not. A column of ordinary dates is deliberately NOT ticked as a birth date — every extract has an order date, and a scan that ticked them all would train you to dismiss its suggestions. Everything the scan does is a starting point: untick what it got wrong, tick what it missed from the same list, and change any method.
Every suggestion arrives as Redact, whatever the kind, because the safest method is the one that should need no decision from you.

Method: Redact — the value is gone

Redact replaces the whole value with eight mask characters. "Jan Kowalski" becomes eight dots. "Wojciechowska-Kaminska" becomes the same eight dots, and so does "Li". That fixed width is the point and not an oversight: a mask that matched the length of what it hid would tell a reader how long the name was, which on a column of surnames narrows the field considerably. Use redact whenever the column is not needed for the analysis — a name column on a revenue report, a free-text notes field, a street address on a regional summary.
It is the default for every suggestion and it should be your default too: the other three methods all keep something, and each of them is a decision about what you are prepared to keep. What redact costs you: every row now reads the same, so you cannot count distinct customers, group by person, or join the masked table to anything on that column. If you need any of that, you want Hash. You can change the mask character per column if the dots are hard to read in your font.

Method: Partial — keep a recognisable fragment

Partial keeps a few characters from the start and/or the end and masks the rest with a fixed-width run, so a person who already knows the record can recognise it while a person who does not cannot find it. Worked examples with the built-in defaults: an e-mail "jan.kowalski@commerzbank.com" becomes "j" + mask + "@commerzbank.com" — the domain is kept whole, which is usually the analytically useful half (you can still count corporate against private addresses); a card "4111111111111234" keeps the last four, the same four a customer is asked for on the phone; an IBAN "PL61109010140000071219812874" keeps "PL61" and the last four, so the country and the tail survive; a phone keeps the last three; a birth date "1978-03-14" keeps "1978" and loses the day and month, so age bands survive and the birthday does not; a surname keeps the first letter.
You can override how much is kept per column with the "Keep 1st" and "Keep last" boxes. Two protections you cannot switch off: the masked run is always the same width, so a short value and a long one come out the same length, and if the value is too short to spare what you asked to keep, the KEPT part shrinks rather than the value leaking — asking to keep four characters of a two-letter surname gives you one character and a mask, not the surname.
Read partial as what it is: the weakest of the four. Kept fragments combine. A last-four card number plus a postcode plus a birth year is frequently enough to identify one person.

Method: Hash — a stable token that still joins

Hash replaces the value with a token like "CUST-9F3A21C8B4": a short tag naming what the column held, then ten characters derived from the value with SHA-256. Nothing of the original survives inside it. What DOES survive is equality: the same customer number produces the same token on every row, on every sheet, in every later pipeline run. That is the whole reason to prefer it over redacting — you can still count distinct customers, group by person, follow one account across two tables, and check that a join worked, all without a single real identifier in the file.
Use it for customer numbers, account references, e-mail addresses used as keys, and any identifier a later step needs to match on. Two things make the tokens what they are. The KIND is mixed into the digest, so a surname and a city that happen to read the same do not collide into one token. And the project KEY is mixed in too, which means two different projects produce different tokens for the same person — masked extracts from separate projects cannot be lined up against each other — and, more importantly, that nobody can recover your column by hashing a list of candidates.
What hash does not hide: the PATTERN. If one customer appears 400 times and everyone else appears twice, that is still visible, and if you already know who the frequent flyer is, you have identified their token. Hashing protects the value, not the distribution.

Method: Synthetic — a plausible fake of the same shape

Synthetic swaps in a realistic replacement instead of a mask, which is what you want for a demo, a screenshot, a training data set or a UAT environment, where a grid of identical dots makes the picture useless. Like hash it is stable: the same source value always produces the same fake, so a customer keeps one invented identity across the whole project. What each kind produces: a first name, surname or full name is drawn from a built-in bank of Polish and international names, and "Kowalski, Jan" stays comma-first if that is how the column reads; an e-mail becomes something like "anna.nowak42@example.com" — always on example.com, a domain reserved by RFC 2606 precisely so an example cannot reach a real inbox, and never configurable, because a synthetic address on a live domain is a message sent to a stranger the first time somebody runs a mail merge on the masked file; an address becomes a street name and number; a city comes from a bank of Polish cities; an IBAN keeps the original country and length and gets check digits that actually verify; a card keeps its length and its separators, starts with 4 so it sits in a test range, and passes Luhn; a PESEL gets an invented birth date and a correct check digit; a birth date keeps its YEAR and moves the day and month; a customer number, postcode or anything else keeps its exact shape — digit for digit, letter for letter, punctuation exactly where it was, so "CUST-9981-A" becomes something like "MQTR-4417-K".
The valid checksums are deliberate: a synthetic identifier that failed validation would be rejected by the first form that looked at it, which turns a masked test file into a bug report. Two cautions. A synthetic value LOOKS real, so label the file — someone who finds it on a share should not have to guess. And phone numbers are the exception to the "safe fake" promise: no numbering plan reserves a block for fiction outside the North American 555-01xx range, so a synthetic phone number may coincide with a real one.
Treat it as a placeholder and never dial it.

The project key — why masking repeats, and what it protects

The first time a project masks anything it generates a random 128-bit key and stores it in the project. Hash and synthetic both derive from it, which is what makes them repeatable: the same customer masks to the same token today, on the next sheet, and in a scheduled run next month. Regenerating it would silently change every token, and a masked column that quietly stops matching the one beside it is among the hardest kinds of wrong to notice — so it is generated once and then left alone.
A project that has never masked anything carries no key at all. What the key protects: without it, a plain hash of a small domain is trivially reversible. Anyone with a list of your customer numbers — or of every Polish postcode, of which there are not many — could hash the list and match the tokens. The random key makes that impossible for anyone who does not have it, and it also means two projects never produce the same token for the same person.
What it does NOT protect, and this matters: the key travels IN THE PROJECT FILE. It is a secret from someone holding a masked CSV, XLSX or screenshot — none of which carry it — and it is not a secret from someone holding the project. So the rule is simple: send the masked EXTRACT, not the project. If the project itself has to go somewhere, treat it as if it still held the original data, because in the sense that matters it does. In a pipeline, the key deliberately stays out of the pipeline file, so a .pipeline.json can be committed to git, shared and reviewed without carrying it.

Worked recipes — three files, three sets of choices

A REGIONAL SALES REPORT for a colleague. You need the numbers, not the people. Redact the customer name and the street address; hash the customer number so distinct-customer counts still work; leave region, product, date and amount alone. Nothing identifiable survives and every figure in the report is still correct. A DEMO OR SCREENSHOT for a presentation. Dots in every cell make the picture useless, so use synthetic throughout: synthetic names, addresses, e-mails, IBANs and customer numbers.
The grid looks exactly like the real thing, the totals are unchanged, and one customer keeps one invented identity across every sheet. Label the file clearly, because it looks real. A TEST OR UAT EXTRACT for another system. You need referential integrity above all: hash every identifier so joins between tables survive, synthetic for anything a downstream validator will check (IBAN, card, PESEL — all three come out checksum-valid), and partial with last-four kept for the fields a tester needs to eyeball against a support screen.
A SUPPORT OR CALL-CENTRE VIEW. Partial is the whole point here: last four of the card, first letter of the surname, the domain of the e-mail — enough for an agent to confirm they have the right record with a customer on the phone, not enough to compile a list from.

What masking does NOT do — read before you send the file

MASKING IS NOT ANONYMISATION. Replacing the name column does not make a row anonymous while the other columns still say which branch, which product, which amount and which day. Re-identification works on combinations — the classic result is that a postcode, a date of birth and a sex identify most people in a population on their own — and it is a property of the WHOLE table, not of one column. No per-column tool can promise otherwise, and this one does not.
Before you send a masked file, look at what is left and ask whether the rows are still unique: a single row for "branch Krakow, product X, 14 March" may name a person as surely as the name column did. MASKING IS NOT ENCRYPTION. There is no key that decrypts it and no way back. MASKING IS NOT DELETION. Under GDPR, masked data derived from personal data may still be personal data if re-identification remains possible; if you need a legal basis rather than a smaller risk, that is a conversation with your data protection officer, not a checkbox in a spreadsheet.
FIVE PRACTICAL CHECKS. Blank cells stay blank — masking never writes into an empty cell, because that would invent data where the source had none and change every count of missing values, so an empty name column is still an empty name column. A formula that produced a masked cell is removed with it, or the next recalculation would compute the original straight back. Masking one sheet does not mask the others, and it does not touch a chart, a pivot or a saved query built on the same data — check those too.
UNDO works within the session, but once the project is saved the originals are gone. And the project file carries the key, so send the extract, not the project.
Range — The block to mask. Opens on your selection when you had one. Everything outside it is left alone — which is the point on a sheet holding several tables in the same columns.
First row is a header — A header row is a column NAME, not personal data: it is left unmasked, kept out of the scan, and its text is what the scan reads instead of C1, C2, C3. Guessed from the data — correct it if the guess is wrong, because a header masked by mistake leaves a table nobody can read, and a data row mistaken for a header quietly escapes masking.

ATX Institute on LinkedIn

This site needs JavaScript for the full experience. Every page above is reachable without it.