Application User Interface (Forms, Lists, UI Policies)
What to know
A form is a composition of views, sections, and fields, saved in sys_ui_form / sys_ui_element style metadata and edited best through Form Designer. Lists are configured with list layout, list controls, and filters; related lists show child records on a form. Know the difference between a form view (role-specific layouts such as Default or Mobile) and a list view.
UI policies are client-side rules that change a field's mandatory, visible, or read-only state when a condition is met. Key attributes: the short description, the conditions, the order, the 'on load' checkbox, and Reverse if false - when checked, actions are undone if the condition later becomes false; when unchecked, the applied state sticks. UI policy actions target a field and a state.
Data policies look similar but are enforced server-side: mandatory and read-only are enforced for API, import, and form submissions. They also have 'reverse if false' semantics and an error message.
Client scripts (onLoad, onChange, onSubmit, onCellEdit) run after UI policies on form load, which is why a UI policy may appear to be overridden by an onLoad script that changes the same field. Server-side ACLs are evaluated before the form renders; UI policies cannot grant access, only presentation.
Traps
- Believing a UI policy protects data. It does not; a savvy user or integration can still write the field.
- Forgetting Reverse if false, then wondering why a hidden field stays hidden after the condition changes.
- Expecting a data policy to change the visual appearance of a form.
- Using an onChange client script for something a one-line UI policy already handles.
Worked example
Show and require 'Justification' when Priority is 1: create a UI policy with condition [Priority][is][1], an action setting Justification to Visible, another setting it Mandatory, and check Reverse if false and On load.
Rule of thumb: presentation in UI policies, enforcement in data policies and ACLs.