We’re researching options to protect sensitive payroll-related amounts in accounting apps (e.g., GL / Journal views) and want to sanity-check what’s possible today and what could be supported in the future.
We understand that currency fields can’t currently be masked or replaced the same way text fields are (e.g., bank account numbers), and that column hiding is the only available option today, which is less than ideal for usability.
A few questions we’re hoping to clarify:
Is there any roadmap or technical feasibility to mask currency fields (rather than fully hiding them) in the future?
Since Restricted Field Definitions are permission-based, is there a supported way to conditionally hide the value of a currency field using a combination of permissions plus line-level logic (e.g., based on source/type)?
Would aggregations (totals, balances) respect this kind of field-level security, or would they need to be explicitly suppressed to avoid inference?
Any guidance, constraints, or known patterns from existing applications would be greatly appreciated. Thanks!
Working on a new skill for Ed to parse our documentation and answer questions. So, grain of salt - but I did confirm with someone with security expertise that this is correct.
Currency Field Masking and Field-Level Security in Nextworld
Based on the documentation, here are answers to your three questions:
1. Technical Feasibility of Masking Currency Fields
The platform supports partial field concealment through restricted field profiles. The documentation states you can:
Hide fields entirely
Disable fields
Partially conceal fields
However, “partially conceal” in the context of the platform means hiding/disabling at the field level, not masking values (like showing “$***” for “$1,234.56”). Currency field value masking (showing only asterisks or partial values) is not explicitly documented as a built-in feature and would likely require custom development using logic blocks or UI customization.
2. Conditional Hiding Using Permissions + Line-Level Logic
Status: Partially supported, with constraints
The documentation reveals an important limitation:
“If one permission grants access to something, another permission cannot remove that access.”
This means:
You CAN combine restricted field profiles (permission-based) with line-level conditions
BUT permissions are additive, not subtractive — if any permission grants access, the field is accessible
Workaround: Use public-secured logic blocks to perform updates without granting direct field access
The best approach for conditional hiding:
Create restricted field profiles to hide currency fields by default
Use Permission Definitions with filters to conditionally grant read/update access based on field values or related fields
For updates without read access, use a public-secured logic block with full RUID access
3. Aggregations and Field-Level Security
Status: NOT explicitly addressed; likely NOT automatically suppressed
The documentation does NOT mention whether aggregations (totals, balances) respect field-level security. This is a critical gap:
The docs don’t indicate that hidden/restricted fields are automatically excluded from aggregations
Inference risk is real — Users might be able to infer hidden currency values from totals, balances, or sums
Explicit suppression required — You would likely need to:
Hide the aggregation field itself if the underlying currency field is hidden
Use custom logic to filter aggregations based on user permissions
Configure report/dashboard filters to respect field security
Recommendation: Areas Requiring Custom Development
Based on the gap in documentation:
Value masking (showing “****” instead of actual values) — Not built-in, custom UI required
Aggregation security — Not automatically enforced, explicit suppression/filtering needed
Currency-specific restrictions — Use restricted field profiles + public-secured logic blocks as workaround
You CAN combine restricted field profiles (permission-based) with line-level conditions
BUT permissions are additive, not subtractive — if any permission grants access, the field is accessible
Workaround: Use public-secured logic blocks to perform updates without granting direct field access