If you’ve worked in financial services long enough, you’ve probably run into this scenario: different team
members need to see different levels of sensitive customer information.
That’s exactly the challenge we faced. We were building a Customer/Account creation flow in Dynamics
365 where a customer’s Social Security Number (SSN) needed to be captured. The requirement was
straightforward on paper:
- Loan Account Managers should be able to view and edit the full SSN.
- Loan Officers should only see the last 4 digits — and only in read-only mode.
What sounds simple quickly gets complicated when you add a SOX compliance requirement and start
digging into how Dynamics 365 handles field-level security out of the box.
Why the Out-of-the-Box Approach Has Limitations
Our first instinct, as it usually is, was to reach for the platform’s native capabilities. Dynamics 365 has a
Field Security Profile feature that lets you control who can read or write individual fields. On the surface,
this looked perfect:
- Grant Loan Account Managers read + write access to the SSN field.
- Grant Loan Officers read-only access to the same field.
But here’s the catch we quickly ran into: when you give a user read access to a field in Dynamics 365,
they see the full value. There’s no native concept of “partial visibility” — you either see the field or you
don’t. So a Loan Officer with read permission would see the entire SSN, not just the last four digits.
That was a non-starter for us from a compliance standpoint.
Key Insight - D365's out-of-the-box field security doesn't support partial data masking. If a user has read
access, they see the full field value
The Custom Solution: Two Fields, Two Forms, One Plugin
After ruling out the OOB route, we designed a custom approach built around three pillars: two fields,
two forms, and a plugin to keep them in sync.
Step 1 — Create Two Separate Fields
We created two fields on the Account entity:
- Full SSN — stores the complete Social Security Number.
- Masked SSN — stores only the last 4 digits (e.g., *--1234).
The Full SSN field is locked down with a Field Security Profile that grants access only to Loan Account
Managers (and system administrators). Loan Officers simply cannot see or query this field — not
through forms, not through Advanced Find, not through any API call made under their credentials.
The Masked SSN field, on the other hand, has no field security restrictions. It’s visible to everyone, but
the value itself is inherently limited — just the last four digits.
Step 2 — Two Separate Account Forms
We then created two distinct Account forms tailored to each role:
- Loan Account Manager Form — contains the Full SSN field with read and write access. This user
can create a customer record and directly enter the SSN. - Loan Officer Form — contains only the Masked SSN field in read-only mode. This user sees just
the last four digits and cannot interact with the full value in any way.
This separation means the UI experience is clean and intentional. No hidden fields, no confusing grayedout boxes. Each user sees exactly what they’re supposed to.
Step 3 — A Plugin to Sync the Fields
Here’s where the automation comes in. Any time the Full SSN field is updated, we need to automatically
extract the last four digits and write them to the Masked SSN field. We accomplished this with a custom
plugin registered on two operations:
- Account Update — triggered specifically when the Full SSN field changes. The plugin extracts the
last 4 digits and writes them to Masked SSN. - Account Create (Pre-Operation) — handles the scenario where a record is created via an
external system integration. The plugin intercepts the incoming data, extracts the last 4 digits
from the Full SSN in the input parameters, and populates the Masked SSN field before the
record is saved.
This dual-registration approach ensures you’re covered whether the record is being created through the
Dynamics 365 UI or through an external API integration.
Critical note!
The plugin must run under a system administrator account (i.e., using the SYSTEM user context).
Since the Full SSN field is protected by a Field Security Profile, even the plugin won't be able to
read it unless it runs with admin-level privileges. This is a commonly missed step that will cause
the plugin to silently fail.
How the End-to-End Flow Works
Putting it all together, here’s what the day-to-day experience looks like:
- A Loan Officer creates a new Customer/Account record. They fill in the general account details
but leave the SSN section blank — they don’t have a field for it on their form. - The record is saved and assigned to a Loan Account Manager.
- The Loan Account Manager opens the record on their form, enters the Full SSN, and saves.
- The plugin fires on update, extracts the last 4 digits, and writes that value to the Masked SSN
field. - When the Loan Officer revisits the record, they now see the Masked SSN (e.g., *--6789) in
read-only mode — enough context to verify the customer, without exposing the full number.
Why This Approach Works
Beyond solving the immediate business problem, this solution has a few qualities that make it
particularly robust:
- SOX Compliance by Design — The Full SSN is inaccessible at the data layer for Loan Officers, not
just the UI. Even if someone tries to query the field directly through Advanced Find or a custom
report, the Field Security Profile prevents it. - Clean Separation of Concerns — Two fields, two forms, two roles. There’s no ambiguity, no
workarounds, and no risk of accidental exposure through form customizations. - Handles External Integrations — The Pre-Operation plugin covers scenarios where records are
created via external systems or APIs. - Minimal Maintenance Overhead — Once set up, the plugin runs silently in the background.
There’s nothing for end users or admins to manage on a day-to-day basis.
Final Thoughts
Dynamics 365’s out-of-the-box field security is a great starting point, but it wasn’t designed with partial
data masking in mind. When compliance requirements demand role-based visibility at the field value
level — not just the field level — a custom approach like this one gives you the control you need.
The combination of Field Security Profiles, separate forms, and a system-context plugin is a pattern
we’ve found reliable across multiple similar use cases. If you’re dealing with sensitive data in D365 — PII,
financial account numbers, health information — it’s a pattern worth keeping in your toolkit.
