Read-Only Is Not Security
Your instance has 800 employees. The custom HR case table u_hr_case stores confidential notes in a field named u_confidential_notes. A UI policy makes that field read-only for anyone without the hr_agent role; 30 people have hr_agent, 770 do not. An audit of the last 30 days found 14 cases where u_confidential_notes changed, and the changed-by user was not an hr_agent. Two changes came through list editing, one through a REST integration using a service account, and the rest through the standard form. The UI policy condition uses g_user.hasRole('hr_agent') and is active. No ACL exists on u_hr_case or on the field. The service account has the employee role only. Leadership wants the field protected without blocking HR agents from editing cases.
1. Explain why the UI policy did not prevent these edits and identify which change paths are expected to bypass it.
Read the worked answer
UI policies run in the browser and affect the form; they are a user-experience control, not an enforcement control.
- List edit does not reliably run form UI policies, so the field remained editable.
- REST/service account has no browser and no UI policy evaluation.
- Standard form changes need investigation, but a client-side check such as g_user.hasRole() can evaluate differently than expected because of role timing, group-inherited roles, or a condition that did not run. The key point is that a client can be bypassed.
Only a server-side control such as an ACL (and, where appropriate, a data policy) is authoritative. The audit result is consistent with client-side enforcement being bypassed, not with the UI policy being 'wrong' about the role.
2. Design the server-side control. Specify ACL type, table/field, role requirement, and what to keep from the UI policy.
Read the worked answer
Create a field-level write ACL on u_hr_case.u_confidential_notes that requires role hr_agent. Keep the table-level write ACL permissive enough that employees can still create or edit their own cases if that is the requirement. ACL evaluation is most-specific-first: the field ACL governs writes to that field even when the table ACL allows a write.
Add a read ACL on the same field if the notes are confidential; write-only protection still leaks data through the form, lists, and reports. Keep the UI policy for user experience (grey out the field), but do not rely on it. Add a data policy only if you need message/validation behavior; the ACL is the enforcement.
Test the service account: if it truly needs to write the field, give it a dedicated role, not employee.
3. How would you verify the change without granting broad access or disrupting HR agents?
Read the worked answer
Impersonate a non-agent employee and try four paths: form edit, list edit, REST PATCH to the field, and import. All should fail with an ACL error. Then impersonate an hr_agent and confirm edit still works. Use session debug / Debug Security to see which ACL matched. Check the service account separately. Add a scheduled audit: query sys_audit for changes to u_confidential_notes where the user lacks hr_agent, and alert. This verifies enforcement rather than assuming the ACL is correct because it exists.