What problem does this solve?
Limiting access to confidential fields (e.g. Application costs or risks) is a critical capability which builds organizational buy-in to bring this data into Ardoq and enables broader access to data without the risk of exposing too much.
How does it work?
When marking a field as confidential, it switches to a "hidden by default" mode within all workspaces.
"Hidden by default" means that the confidential field's value will be replaced or tokenized (wherever relevant in the UI), as well as stripped from the API:
One thing to be mindful of -- confidential Fields only apply to component fields. They will not currently affect or limit access to reference fields.
Who can view a confidential field's value?
There are three ways to get access to a confidential field:
Users with the
adminrole will see all confidential field values.Users with
Full accessto a given workspace will see the confidential field values within that workspaceAny groups who have been explicitly granted access by an admin to a confidential field within a given workspace (see below).
Does this hide the entire field, or just redact its values?
Only values, and this is by design.
There are many reasons to hide fields (UI clutter of calculated fields, personalization, etc) which are unrelated to data confidentiality. We feel that these needs should be separated:
One tool to confidently restrict access to data, with strong guarantees of correctness.
One tool to simplify the UI and improve your ability to curate insights.
We have targeted the first need with Confidential Fields, and designed it in such a way that it should play nicely with future work on field personalization.
How do I grant a group access to a confidential field?
You can grant a user group access to a confidential field on a workspace-by-workspace level:
There is one precondition for granting a group access -- the group must already be explicitly granted at least Read access to the workspace. If a group is missing from here, you must add them first (which grants them read access to the workspace) and then grant them access to the field. A few notes:
Admins always have access to the field.
Users or groups with
Full accesswill always have access to the field.Users cannot be granted access directly to a confidential field. They can only be assigned access through one of their groups.
How does this interact with other assets?
When you mark a field as confidential, it takes effect across the platform. However, certain assets are handled specially.
⚠️ Presentations
All confidential fields are stripped from all visualization-based presentation slides. For example, block diagrams and capability maps but not report or dashboard slides.
This is the safest default. However, it may impact slides where (for example) you have a capability map with a cost label, a bubble chart using a confidential field as a parameter, or a view where conditional formatting is based on the confidential field.
For communicating insights such as cost rollups based on confidential fields, you can instead use a Report or a Dashboard in place of a heatmap-based visualization.
Reports & Dashboards
It is up to the author of the report and dashboard to choose what they expose to their recipients. Therefore, it is possible for someone to view/consume a confidential field via a report/dashboard, where they otherwise wouldn't have access.
However, it is impossible to gain access to a confidential field in this manner. A report/dashboard author cannot create something based upon a confidential field which they cannot access themselves.
Limitations
New vs Old Discover:
Confidential fields only supports New Discover, which uses our existing permissions setup. As such, you will not see any guidance in the Discover Viewpoint builder, and field permissions are still managed through Viewpoints in New Discvoer.
Integration handling:
A writer uploading an excel sheet needs to be aware that they won't be able to import certain columns if they are mapped to confidential fields. The values will end up being removed on import
Gremlin graph filters:
Gremlin has access to all data and all fields, so certain gremlin graph filters may leak information about the field values depending on how they are written. The admin must take care and potentially be guided on the risks.
Perspectives:
Perspectives, grouping, and formatting based on confidential fields may have confusing behaviour (e.g. a heat map based on a confidential field will not work if you don't have access to the underlying heat map field)
Changelog
We will be continually recording changes/improvements here as the beta proceeds.
04.03.26: Redesigned confidential fields admin configuration UI
New two-step configuration flow with field search, links to workspaces and related assets (surveys, reports), and visibility of unsupported field types (List, Multi-select List) shown as disabled with explanations instead of hidden.
04.03.26: Confidential field support in surveys
Survey editors now see warnings when questions reference confidential fields — in field dropdowns, question headers, custom result page fields, and change approval configuration (warning that approvers will gain access). The backend also prevents non-admin users from exposing confidential data through survey question edits or advanced search configuration.
09.03.26: Confidential field warnings in dashboard builder
Widget headers, filter tables, and column selectors now indicate when confidential fields are involved, matching the existing behavior in report builder.
11.02.26: Confidential field support in presentations
Confidential fields are now properly redacted across all presentation modes — public, shared, and private — including traversal slides which were previously bypassing field permission checks.
Public presentations never show confidential data; private presentations with "Creator" read access respect per-viewer permissions.
26.02.26: Confidential fields warning in report and survey permission modals
When managing permissions for a report or survey, admins now see a warning listing which confidential fields the resource exposes.
20.02.26: Improved remove confidential field confirmation
The confirmation dialog when removing a confidential field now shows which groups/users currently have restricted access and who would gain access after removal.
17.02.26: Security fix: Report create/update validates confidential field access
Writers could bypass confidential field redaction by crafting an API call to create or update a report with columns they weren't authorized to view. The API now validates permissions on both create and update.
11.02.26: Security fix: Workspace copy enforces confidential field access
Writers could copy a workspace via the API, becoming admin on the copy and thereby gaining visibility of all confidential field values. Both the workspace and component copy endpoints now require full CF visibility in the source workspace.
10.02.26: Security fix: Write protection bypass on stale permission data
Fixed an edge case where granting a user access to a previously redacted field could cause stale null values to overwrite real data if the user's client hadn't refreshed.
06.02.26: Improved reliability of confidential field permission management
Batch operations (mark/unmark/grant/revoke) now execute atomically in a single request, eliminating race conditions when marking a field as confidential and assigning permissions simultaneously. Also fixed a bug where revoking access to one field could accidentally wipe all field permissions for that workspace+group.
06.02.26: Real-time permission updates via websocket
Confidential field permission changes now propagate in real-time, so users see updated field visibility without needing to reload.
06.02.26: Bugfix: Date range confidential fields in scenarios and component overview
Fixed multiple issues where date range fields weren't properly recognized as confidential due to the _start_date suffix not being resolved during permission checks. Affected the scenario sidebar and component overview panel.
25.01.26: Addressed issues with client/server synchronization
There are two protections:
- Connected users will now have a popup which informs them that their permissions have changed and that they need to reload the app. Reloading has been made possible without a full refresh to various parts of the app in order to support this.
- The API will now consult metadata on each component to check that it isn't removing values from fields which it considers confidential.
19.01.26: Small tweaks to builder UI
Improved sorting and ability to clear selected fields during builder flow
14.01.26: Bugfix: race condition
Issue/error when saving a new confidential field and also assigning a group to have access to that field in the same operation.
14.01.26: Added support for managing workspace permissions from the confidential fields configuration flow
Previously the user had to flip back and forth in order to grant a user access to the workspace first, before assigning confidential field access.
08.1.26 Improved indicator for workspaces which include a confidential field in report builder.
If the author includes a workspace + column for a confidential field which they don't have access to, we now communicate exactly which workspaces are including these fields.
19.12.25 Improved indicator/placeholder for a redacted value in reports.
Added clearer indicator for a "redacted" confidential fields in reports.
18.12.25 Handled Date Range field confidential access rules
Added clearer indicators in the report builder, to warn writers and inform admins about sharing confidential fields.
18.12.25 Improved UI indicators of confidential fields in reports
Added clearer indicators in the report builder, to warn writers and inform admins about sharing confidential fields.
17.12.25 Allowed users/groups with Full Access to see the confidential fields
These users now see the fields as they should
14.12.25 Support for confidential fields scaled out to 95% of viewpoints functionality
There is an extremely small edge-case which remains, when applying filter rules on a starting component.
11.12.25 Support for confidential fields scaled out to 90% of scenarios functionality
It is still possible to inspect the API and see the confidential fields of connected components, but not the core components in the scenario itself.
8.12.25 DateRange display of confidential fields improved in Pages + Tables View
Fields were correctly being redacted, but the UI wasn't showing the confidential fields tags for the end of a date range. This has been fixed.
5.12.25 Prevent writers from being able to view fields through report preview
There was a small circumvention of confidential fields where a writer could use the report preview to view confidential data. This has now been patched.