When ERPNext teams need masked values instead of hidden fields
Finance, HR and sales teams often need to confirm that a bank account or phone number is on a record without seeing the full value. Data masking in ERPNext on version 16 is built for that case: users in designated roles see a partial value, such as the last few characters, while the stored value stays complete. The feature is experimental, so treat it as a candidate for a controlled pilot rather than a settled control. Confirm its status, supported field types and settings in the release notes for the exact version you plan to run before you design around it.
Masking changes only what the user sees on the form. It does not change who can edit the field, so a role that can write to a bank account field can still replace the whole value. It also does not, by itself, cover the other channels where the value appears, including exports, reports, list views, print formats, API responses and attachments. Test each of these with a masked role on a copy of your site. Field-level hiding through perm levels works differently: it removes the field for a role entirely, which is the better fit when a role should not know the value exists.
Consider masking when the business need is partial recognition, such as verifying that a supplier has a bank account on file, and the full value is needed only by a small set of roles. If the requirement is to block access to personal data, restrict the role or the record instead, because a display mask is one measure among several under the security-of-processing duty in Article 32 of the GDPR. Before a pilot, ask your ERPNext partner or Frappe to confirm which DocTypes and fields are supported, how the mask is formatted, and whether it applies to exports and the API. Write those answers into your test plan.
Choosing between perm levels, data masking and other access controls
This table compares four ways to limit a sensitive field or record in ERPNext: perm levels, Frappe data masking, user permissions and DocType or report access. Read each row for what the user sees, what the control protects and what to confirm in the version you run. Data masking is version-dependent and experimental, so treat it as one tool alongside the others rather than a replacement for them.
| Option | What the reader sees | What it protects and where it fits | What to confirm in your version |
|---|---|---|---|
| Perm levels | Field hidden or read-only for roles without a matching permission row | Salaries, cost prices and margins where the value should not appear at all for some roles | Which roles hold each perm level row and that tests confirm what each role sees |
| Frappe data masking | Field shown in partly hidden form, such as a masked phone number or bank account | Phone numbers and account numbers where some staff need a partial reference, not the full value | That the feature is available in version 16, its experimental status and how it behaves on your fields |
| User permissions | Only records linked to the user's allowed company, territory or branch | Restricting staff to their own entity or region across whole documents and lists | Which link fields apply per DocType and how hierarchy access is set for managers |
| DocType and report access | Whole document type or report hidden from roles without access | Entire datasets such as payroll, bank details or supplier bank records | Role assignments per DocType and report, and whether exports or print formats expose the same data |
How data masking differs from perm levels
Perm levels decide whether a role can read or write a field at all, while data masking changes how a value looks to a role that can still open the document. A field locked through a perm level is withheld from the role's view of the record, so the value is not sent to the user's browser in the normal form path. Masking is a display measure: the full value remains in the document, and the role sees a partially hidden version of it, such as the last few digits of a bank account. For fields that must be fully hidden from certain roles, such as salaries or bank details that only payroll should reach, test perm levels first and treat masking as an additional layer on top of them. Confirm the current masking configuration options, and whether masking is marked experimental, against the Frappe documentation for your version before you rely on it.
Masking is only as good as its coverage, and a masked value can surface in more places than the form. Check every path that can return the field for a masked role: list views, report builder and standard reports, exports to CSV or Excel, the Data Import tool's export templates, print formats, email notifications, API responses, and attachments generated from the document. Each path needs its own test with a user who holds the restricted role, and the test should compare the raw value with what that role receives. Record the results per DocType and per path, and repeat the tests after each ERPNext upgrade, because a release can change how a path renders a field.
Plan the control as a verified display measure, not a guarantee of confidentiality. If a regulator or auditor asks how a sensitive field is protected, the answer should rest on the access layer that blocks the value, with masking documented as a presentation control that was tested on named paths. Ask your implementation partner to write the test matrix as part of the scope, and agree in writing which paths are in scope, who signs off the results, and how exceptions such as custom scripts or third-party integrations are handled.
How to set up and test masking on one field first
This sequence proves that masking works for one DocType and one sensitive field on a non-production copy before any wider rollout. It produces a documented expected view for each role and a recorded test result with a rollback plan.
Build a non-production site on version 16
The platform or ERP administrator creates a staging site that matches production on the same ERPNext and Frappe version 16 release, with the same installed apps and a copy of the roles and user permissions. Use a sanitized data set if production contains personal data that the test team should not see. The step is done when the site version, installed apps and role assignments match production, and the team records the exact version numbers in the test log. Confirm with your own environment's version details that the staging and production builds match.
List sensitive fields and the roles that need partial views
The project lead and data owners list each field that must be partly hidden, such as a phone number, bank account or salary, along with the DocType it belongs to. For each field, they name every role that currently reads it and state whether that role should see the full value, a partial value or nothing. The output is a short register with one row per field and role. The step is complete when every role that can open the DocType appears in the register, and the data owner has signed off the rules.
Record the expected view for each role
Before any configuration change, the tester writes down what each role should see on the sample record: the full value, the masked value and the way the value appears in the list view, reports, exports, API responses and print formats. Keeping these expectations in writing lets the team judge the result against a fixed standard rather than against whatever the screen happens to show. The step is done when the expectation sheet covers every surface listed in the test plan and a second reviewer has read it.
Enable and configure masking on one field
The ERP administrator turns on data masking for a single DocType and a single field on the staging site only, following the configuration location in the documentation for version 16. Because masking in version 16 is experimental, the team confirms the current status and known limitations in the release notes before enabling it. The step is done when the setting is saved, the change is recorded in the change log and the field shows the expected behavior for the System Manager account on a test record.
Test each role on the form and list view
The tester signs in with a test account for each role in the register and opens the same sample record, then checks the form view and the list view against the expectation sheet. Each mismatch is logged with the role, DocType, field, screen and observed value. The step is done when every role has been tested on both screens, and every mismatch has either been fixed or accepted by the data owner in writing.
Test reports, exports, API calls and print formats
The tester runs the standard reports that include the field, exports the list to a spreadsheet, makes an API call with each test account and generates a print format for a sample document. A value that is masked on screen but visible in an export or API response is a failure, and the team treats it as a blocker. The step is done when every surface in the plan has a recorded result for every role, and any leak has a documented fix or a decision to keep the field out of that surface.
Record the result and set a rollback plan
The project lead writes a test report that lists the version, the field, each role's results, the open defects and the data owner's approval. The report also states the rollback steps: turning the masking setting off, restoring the previous role and print format configuration from the change log, and confirming on the staging site that the original values display again. The step is complete when the report is approved and the rollback steps have been rehearsed on the staging site. Only then should the team consider a wider rollout.
Security and operational risks to test before relying on masking
Masking changes what a screen shows, so each route to the underlying data needs its own check. The six risks below cover storage, outputs, access changes, permission overlap, upgrades and logging. Assign each check to one owner before the rollout date is set.
Stored values and backups
Confirm whether a masked field keeps the full value on disk in the database, replicas and backups. A display-only mask leaves the complete account number in every copy, so retention, encryption at rest and restore access must cover those copies. Restore a backup to a test site, sign in as a masked role, and query the stored column directly. Owner: the platform team, with the data protection lead, because Article 32 of the GDPR requires security of processing.
Exports, reports and imports
Masked fields can reappear in report output, list exports and the Data Import tool when a user holds export or import rights. Test every DocType that holds a masked field against each role that should see it masked, and compare the exported file with the on-screen value. Run import tests on small sample files first, since the import documentation advises loading records in limited batches. Owner: the data owner for each function signs off, and the ERP administrator runs the matrix.
API, attachments and print formats
The REST API, uploaded attachments and print formats can each expose a value that the Desk hides. Call the API as a masked user for each DocType, open attached files that contain bank details, and render print formats for the same record. Custom Server Scripts that return data may also bypass what the screen shows, so review every custom endpoint before go-live. Owner: the application security team runs these tests, and the ERP developer fixes any gap found.
Role, user permission and perm level overlap
Masking, user permissions and perm levels can each restrict the same field, and their combined result is what users see. Test a user who holds a broader role, a narrow user permission and a field locked by perm level at the same time. Retest after any role profile change or temporary grant, and confirm that revoking a role restores masking. Owner: the ERP administrator builds the test cases, and the access review owner approves changes to them.
Upgrade regressions in an experimental feature
Data masking is experimental in version 16, so a release can change its behavior without the stability a mature feature would carry. Keep a regression script that checks each masked field for every role, and run it before and after each upgrade. Read the release notes for changes to the feature, and pin the version in a staging site before production. Owner: the platform team approves upgrades, and the security team maintains the regression cases.
Audit trail of who viewed masked data
Establish whether the system records when a user reveals or views a masked value, or only when a record changes. If the log covers edits alone, you need a separate control for viewing. Test in staging what version history and activity logs capture for masked fields, and document the result for auditors. Retention of those logs is a policy decision for the data protection lead, and the compliance lead owns the evidence.
What GDPR Article 32 expects from access measures
Article 32 of the GDPR (Regulation (EU) 2016/679) places security of processing duties on both the controller and the processor, and it leaves the choice of technical and organizational measures to them. The controller decides which measures fit the risk to people's rights and freedoms, and must be able to justify that choice. For a masked field such as a bank account number or a salary, the question is not whether masking exists as a feature, but whether the combination of role permissions, field display rules and the surrounding controls matches the sensitivity and volume of the data for that group of users.
The GDPR requires no audit, attestation or certificate. Certification under Article 42 is voluntary, and it does not reduce the controller's or processor's responsibility for compliance. An auditor's report or a certificate on your ERPNext environment would be evidence you gathered for your own assessment, not a compliance finding that the regulation requires. Your data protection officer, legal counsel and, where relevant, your supervisory authority's guidance are the right sources for deciding what your obligations are.
Masking is one possible measure among several. Before relying on it, confirm with legal advice whether it is sufficient for each dataset, considering who can still reach the unmasked value through other DocTypes, reports, exports, API responses or print formats. This page does not state legal conclusions. Document the risk assessment, the roles that see full values, the testing you performed and the owner who approves changes, so that the justification exists before an assessor asks for it.
Limits to confirm in your environment
Data masking in ERPNext sits on top of version, hosting and customization choices that you control. The cards below cover the checks that decide whether masking works as intended in your deployment, and they are best read before you design the roles that depend on it.
Experimental status in version 16
Masking in version 16 is marked experimental, so its behavior, field coverage and known issues may change between releases. Ask the vendor or check the release notes for your target version before you rely on it for production data. Record which minor release you tested, and repeat your role tests after each ERPNext update.
Server Scripts disabled by default
Custom workarounds that hide values in server code depend on Server Scripts. From version 15, these are disabled by default and must be enabled with the server_script_enabled setting. Frappe Cloud public shared benches do not allow them, so a workaround designed on one hosting option may not be possible on another.
Hosting choice limits configuration
Frappe Cloud, Docker Compose and bench each differ in what you can change on the server. Confirm whether your hosting option lets you enable server-side settings, install custom apps and apply patches. Decide the hosting model before you design masking, because changing it later can force a rework of the role and script design.
Version lifecycle and support plan
Version 16 is planned to be supported until the end of 2029, and warranty coverage from Frappe depends on running a listed version with a matching Frappe Cloud support plan. Confirm which version your organization will run, who applies fixes to masking behavior, and how security patches reach your environment within your own change process.
Behavior with your apps and customizations
Masked fields may not behave the same way in every report, print format, export or custom script. Test each customization that reads a masked field, including Frappe HR, custom apps and integrations. Check whether exports, API responses and attachments reveal the underlying value, since masking the form view alone may not protect the data.
Roles, permissions and audit coverage
Masking is one layer beside role permissions, perm levels and user permissions, and it should not be the only control for sensitive fields. Confirm how masking interacts with each of these layers for the same DocType, and make sure your access reviews and logs can show who saw what. Test with real role accounts, not only the Administrator.
Questions buyers ask before hiring help with ERPNext data masking
Can Frappe data masking replace perm levels in ERPNext?
Usually not on its own. Perm levels decide which roles can read or write a field, while masking changes how a value is displayed to a role that is allowed to open the record. Treat them as two controls that work together. Before you rely on masking for salaries, bank accounts or contact details, confirm in the documentation for your ERPNext version how masked values behave in list views, reports, exports, print formats, attachments and the REST API. Because the feature is experimental in version 16, test each of those surfaces with a test user for every role, and keep the perm level rules that already restrict editing and reading in place.
How long does a masking pilot take and what drives the time?
No duration can be stated from the research behind this page, so ask for a timeline in the written scope rather than relying on a generic estimate. The main drivers are the number of masked fields and DocTypes, the number of roles that need different views, and the number of surfaces to test, such as list views, reports, print formats, exports, web forms and API responses. Custom apps and custom scripts add time because each one can expose a value that the standard checks do not cover. A pilot limited to one DocType and two roles is much smaller than a company-wide rollout across sales, purchasing, payroll and manufacturing.
What does a masking project need from our own team?
The work depends on four inputs from your side. First, a role matrix that lists every role, what it may see today and what it should see after the change. Second, a field inventory that names each sensitive field, the DocType it sits in, and the business owner who signs off on who may see it. Third, test users for each role, created in a non-production copy of the site, so results can be repeated. Fourth, a named decision-maker who approves the masking rules and the evidence before go-live. Gaps in these inputs are the most common reason a masking project runs longer than planned.
Can our internal team implement ERPNext data masking alone?
Yes, if the team has Frappe development skills, a staging environment that mirrors production, and time to test each surface against each role. The harder part is the ongoing work: a feature marked experimental can change between releases, so someone must read release notes, rerun the tests and decide whether to upgrade. Internal teams often underestimate the test matrix, which grows with every role and every report. If you do the build in-house, agree on a test plan and an owner for upgrade regression before you start. Outside help is most useful for the test plan, the review and the handover documentation.
What should a quote for ERPNext masking include?
A quote should follow from a written scope that lists the fields, DocTypes and roles in scope, plus the surfaces to test, such as list views, reports, exports, print formats and API endpoints. Ask for the environments involved, the deliverables (role matrix, configuration record, test scripts and results, runbook for changes), the handover and training, and any assumptions about custom apps. Also ask what is excluded. DeployOpen works mainly on fixed-scope engagements agreed in writing before work starts, and ongoing support is available as a retainer. Ask which costs are one-time and which recur, such as retesting after each upgrade.
What happens to masking when ERPNext ships a minor release?
ERPNext ships minor releases frequently on both supported major versions, so masking behavior can change without a major upgrade. Read the release notes for each version you deploy, and rerun your masking test suite on a staging copy before applying the update to production. Keep the exact version pinned, and schedule upgrades rather than applying them automatically. If a release changes how masked values appear in a report or an API response, you need a fix or a documented workaround before go-live. Ask your partner how they track releases and how quickly they can retest after an update.
Does ERPNext data masking make us GDPR compliant?
No single feature makes a system compliant. The GDPR does not require an audit, attestation or certificate. Article 32 requires controllers and processors to apply technical and organizational measures that suit the risk to personal data, and masking can be one of those measures when it is tested and documented. Certification under Article 42 is voluntary and does not reduce your responsibility. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or attestations. Review the regulation text on EUR-Lex with your legal and privacy team before you describe masking as a control in any assessment.
How DeployOpen scopes and tests ERPNext access controls
DeployOpen treats data masking as one layer in a wider access model for ERPNext, alongside role permissions, perm levels and user permissions. We plan which roles see full values, which see masked values and where the masking must hold across reports, exports and the API. Engagements are fixed-scope, with the scope agreed in writing before work starts.
How we scope
- Inventory the sensitive fields such as phone numbers, bank accounts and salaries, and the DocTypes and reports that display them.
- Map each role and job function to the exact values it may see in full, masked or hidden.
- Confirm in writing whether the rollout uses the version 16 masking feature, which is experimental, or perm levels and other controls instead.
How we build
- Configure masking and permission rules in a staging copy of your ERPNext site, with each change tied to a documented role decision.
- Check masking against list views, print formats, report builder output, data exports and API responses for each role.
- Run test accounts for every role profile and record what each one sees, so gaps are found before go-live.
How we hand over
- Deliver a written access matrix listing roles, fields, masking rules and the test results behind each one.
- Document how to add a new sensitive field, how to test it and who approves the change.
- Train administrators on reviewing access after role or org changes, so masking does not drift over time.
How we support
- Offer ongoing support and upgrade work as a retainer, including re-testing masking after each ERPNext minor or major release.
- Review the access matrix when the experimental masking feature changes status or when your roles are reorganized.
- Confirm with your legal and privacy team how masking fits your own obligations, since DeployOpen does not issue audit reports or certifications.
