Hello @Mohan_Rao_Alladi
Interestingly, we encountered a very similar requirement during a recent POC, and after few days of architectural brainstorming we arrived at an approach based on one key design question:
Why should masking/unmasking be handled inside the case context when it can be handled entirely at the UI layer?
This led us to a hybrid pattern combining Access Control Policy for security enforcement and a custom Constellation component for runtime reveal behavior.
However, we are still evaluating other approaches as well in parallel.
Design Approach
1. Security Enforcement via Access Control Policy
First, we identified all fields that must be masked for a given case type and implemented an Access Control Policy that conditionally masks them (fully or partially). This ensures:
- Security is always enforced server-side
- Masking is the default state
- Data remains protected regardless of UI behavior
2. Config-Driven Field Registry
Instead of hardcoding logic, we created a data type that defines which fields participate in masking/unmasking:
| Field |
Purpose |
| Field Name/Path |
Property reference (scalar or embedded) |
| Data Test ID |
UI element identifier |
| Is Masked |
Flag controlling inclusion |
This makes the solution fully configurable and future-proof — adding/removing fields requires only data changes, not component updates.
3. Custom Toggle Component (Field → Boolean)
We built a reusable custom field component that renders a toggle button.
Behavior:
When user clicks toggle ON:
- Invoke a parameterized data page with Case ID
- Data page retrieves masking configuration
- Filters only entries where
IsMasked = true
- Fetches actual values directly from DB using the case data page
We intentionally fetch from DB because client APIs (like pConn.getValue()) still respect Access Control Policies and return masked values.
4. DOM Replacement Mechanism
The component then:
- Iterates through returned field list
- Locates elements via
data-testidin - elements
- Replaces masked text (
***) with actual values
When toggle is turned OFF:
- Values revert to masked state using cached data
- No additional server call required
5. Stateless Security Behavior
On refresh or re-open:
- Access Control Policy automatically re-applies masking
- Toggle defaults to OFF
- No cleanup logic required
- No session flags needed
6. Role-Based Visibility
The toggle component itself is conditionally rendered based on access roles:
- Authorized users → see toggle + can reveal
- Unauthorized users → always see masked values
Why This Works Well
This pattern satisfies all stated requirements:
- No Perform access required
- No case audit entries created
- Masked by default on every load
- Explicit user action required to reveal
- Fully secure and server-enforced
- No unnecessary UI refreshes
- Configurable and scalable
External Audit Logging
For audit requirements:
- Trigger an asynchronous REST call from the toggle action
- Send case ID, operator ID, timestamp
- Log externally (SIEM / audit service)
Since this action never updates case data, it avoids generating Pega audit records while still meeting compliance visibility needs.
Additional Considerations / Recommendations
To make this enterprise-grade and guardrail-friendly:
1. Throttle or debounce toggle calls
Prevent repeated rapid toggles from spamming audit logs.
2. Mask at API level as well
Ensure that APIs returning case data also respect the same Access Control Policy so data cannot be retrieved unmasked through alternate channels.
3. Avoid storing revealed values client-side long-term
Keep values only in component state and clear on unmount.
4. Add optional timeout auto-re-mask
For high-security environments, re-mask after inactivity.
5. Document field registry ownership
So business teams know where masking fields are configured.
Architectural Principle Behind This Pattern
Security enforcement belongs on the server. Visibility behavior belongs on the client.
Area that is slightly Non-Standard (But may be acceptable with justification)
If i look back at the solution below is one point which is not completely aligning with the standard guardrails.
DOM manipulation using data-testid
This is the only part that is not a typical Constellation pattern, because:
- Constellation is metadata-driven
- Direct DOM manipulation is technically outside rule model
However, it can be justified because:
We are not altering structure
We are not injecting logic into layout rules
We are only swapping rendered values
No server state is affected
In architecture review language, this is:
A controlled client-side enhancement layered over standard rendering.
This is acceptable when:
- No OOTB extension point exists
- Security is still server-enforced
- Solution is documented
A short design note on the above implementation documentation:
This solution uses client-side rendering substitution to reveal values that are already authorized and retrieved via governed data pages. No security logic resides in the UI. Access control remains fully enforced server-side.
The above single paragraph can protect this solution during:
- guardrail reviews
- upgrade assessments
- architecture boards
- compliance audits
Below is the Implementation in action.
Appreciate thoughts, feelings and any other alternatives from our community members.
Regards
JC
