What it does

Dataverse.Unmask lets a canvas app fetch the real value of a masked Dataverse column for one selected record, typically behind a Reveal button and a Hide button. Dataverse still decides whether the current user may see it. The buttons don't grant access, bypass column-level security or change the stored data or the masking rule.

Key facts

• The formula pattern is a label that shows the ordinary value until a context variable is set, then shows IfError(Dataverse.Unmask(Gallery1.Selected, 'Sensitive reference'), "Unable to show this value.").
• The record has to keep its Dataverse identity. Bind the gallery straight to the table and pass Gallery1.Selected; a hand-built record won't work.
• The column needs column-level security. Adding a masking rule needs a managed environment and a column type that supports masking. A secured column doesn't automatically have a masking rule.
• The user needs table and record access, column Read, and the right Read unmasked permission via a column security profile.
• Column names containing spaces take single quotes. Double quotes make a text literal and quietly break the formula.
• Reads can be cached, so repeating the formula doesn't prove a recent permission change has taken effect.

When to use / skip

Use it where a small group genuinely needs the full value now and then, such as a support agent confirming a customer reference, and everyone else should see the mask. Skip it if the whole audience needs the value all the time; then the column probably shouldn't be masked for them, and a reveal button is just friction.

Configuration decisions

• Which Read unmasked scope each profile gets. Single-record access is the point of the pattern; don't give All records to make a demo work.
• What resets the reveal state: screen visible and hidden, gallery selection, and anything else that changes the selected record or data.
• What the user sees on failure. IfError gives you a message; a blank result alone doesn't tell you it was a permission problem.
• Whether the app needs a loading indicator. The read is asynchronous and users will click twice.

Gotchas

• System administrators aren't hidden from by column-level security, so testing with your own admin account proves nothing. Test with a non-administrator and synthetic data.
• Hiding a label isn't an authorisation boundary and doesn't purge cached values. Dataverse permissions are the only control.
• Gallery child controls need Select(Parent) or the selection (and your reset) won't fire when someone taps the row text.
• Don't write unmasked values to SaveData, logs or a less protected store, and keep them out of screenshots and diagnostic attachments.
• A denied read doesn't always produce the same error, so don't build logic that keys off one message.

Consultant notes

• UAT should include a "reveal, then click another row" case. Leaking the previous record's value into the next row is the defect that gets raised, and it comes from a missed reset.
• Agree the masking rules and the security profiles with the data owner before building the app. Makers tend to start with the button and discover afterwards that nobody has defined who may unmask.
• Screenshots in support tickets are the quiet leak. Add a line to the operating procedure rather than relying on the app to stop it.
• Treat the pattern as a convenience for authorised users, never as the protection itself; the review should be of the security profiles, not the formula.

---

Worth revisiting if the function changes behaviour or masking rule types expand.