2.3 Lists, Forms & UI Customization
Key Takeaways
- Form Layout and Form Design control which fields and sections appear on a form; the list editor and List Layout control list columns and order.
- Form sections group fields into tabs/areas, annotations add inline guidance, and related lists show child records linked by reference or many-to-many relationships.
- UI Policies run on the client to dynamically show, hide, make mandatory, or set fields read-only; Data Policies enforce the same rules on the server regardless of interface.
- Personalization changes only the current user's view (no Update Set); configuration changes the form/list for all users and is captured in an Update Set.
- Choosing client-side UI Policies versus server-side Data Policies depends on whether the rule must hold for imports and integrations, not just the form.
Why Lists, Forms & UI Customization Matters
Quick Answer: Administrators shape what users see by configuring forms (layout, sections, annotations, related lists) and lists (columns, order). UI Policies dynamically change a form on the client; Data Policies enforce rules on the server for any interface. Personalization affects only the current user; configuration affects everyone and is captured in an Update Set.
This topic supports the larger Instance Configuration and Collaboration domains. The CSA exam reliably tests the difference between UI Policy vs Data Policy and personalization vs configuration, so master those two contrasts.
Configuring Forms
A form displays one record. Administrators change forms with:
- Form Layout (the older slushbucket editor): add/remove fields and arrange them in columns.
- Form Design (the modern drag-and-drop designer): visually build the form, add sections, and manage fields.
- Configure > Form Design / Form Layout is reached from the form's context (hamburger) menu.
Form Sections and Annotations
- Sections group related fields. Multiple sections render as tabs (or stacked areas) so a long form stays scannable — for example, a Notes section separate from a Details section.
- Annotations are inline text/instructions placed on a form to guide users (for example, a note explaining a field). They are added through Form Design and are not data fields.
Related Lists
A related list appears at the bottom of a form and shows records related to the current record:
- Reference-based — child records that point back via a reference field (for example, Tasks related to a Change).
- Many-to-many — records linked through a relationship/junction table.
- Defined relationships — custom related lists created with a Relationship record for non-standard joins.
Related lists are configured through Configure > Related Lists, which uses the same slushbucket pattern as form layout.
Configuring Lists
A list shows many records. Administrators and users adjust lists with:
| Action | Effect | Scope |
|---|---|---|
| Personalize List columns (gear) | Choose columns and order | Current user only (personalization) |
| List Layout (Configure > List Layout) | Set default columns/order for everyone | All users (configuration) |
| List Control | Govern list behavior, mechanic options | All users (configuration) |
| Right-click header | Sort, group, set filter | View-time only |
The key distinction: the gear/personalize path changes only your view, while Configure > List Layout changes the default for all users and is tracked in an Update Set.
UI Policies vs Data Policies
This is the single most tested concept in this section.
| UI Policy | Data Policy | |
|---|---|---|
| Runs where | Client (browser, on the form) | Server (database layer) |
| Effect | Show/hide, make mandatory, set read-only, run a UI Policy script | Make a field mandatory or read-only for any write |
| Applies to | The form/UI the user is interacting with | Form and imports, web services, and other server writes |
| Use when | You need dynamic, condition-based form behavior for users | A data rule must hold no matter how the record is created |
| Can convert | — | A Data Policy can be converted to a UI Policy (and vice versa) for consistency |
Rule of thumb: if the requirement is "users should not be able to submit without a field on the form," a UI Policy is enough. If the requirement is "this field must never be empty even when records arrive via Import Set or integration," you need a Data Policy (often paired with a matching UI Policy so users get immediate feedback).
flowchart LR
A[Record write] --> B{Where does the rule run?}
B -->|On the form, client-side| C[UI Policy: show / hide / mandatory / read-only]
B -->|Any write: form, import, API| D[Data Policy: mandatory / read-only on server]
Personalization vs Configuration
| Personalization | Configuration | |
|---|---|---|
| Who is affected | Only the current user | All users (or all users in a view) |
| Typical actions | Personalize list columns, reorder your own form fields (where allowed) | Form Design, List Layout, UI Policies, Data Policies, new fields |
| Update Set | Not captured | Captured and promotable between instances |
| Permissions | Usually available to end users | Requires admin or appropriate elevated role |
| Risk | Low (private to the user) | Higher (affects everyone) — test in sub-production |
A classic exam scenario: "An end user rearranges columns using the personalize gear." That is personalization — it does not change other users' views and is not recorded in an Update Set. A new mandatory field added through Form Design is configuration — it affects everyone and is tracked.
Putting It Together
When asked to implement a rule, ask three questions in order:
- Does it need to hold for non-UI writes (imports/APIs)? If yes, use a Data Policy.
- Is it dynamic form behavior for users only? Use a UI Policy.
- Is the change just for me, or for everyone? Personalization for me; configuration for everyone (and it goes in an Update Set).
Mastering these decisions is exactly what the CSA exam validates in this domain.
A requirement states that a field must never be empty, even when records are created through an Import Set or an inbound integration. Which tool enforces this?
An end user uses the list 'personalize columns' gear to add a column. What is true about this change?
Which feature is used to add inline instructional text to guide users on a form?
Which capability is NOT something a UI Policy can do?