# Layouts, Lightning pages, labels and Visualforce

## Page layouts

Never put the word "Layout" in the name — the metadata type already says what it is.

- Keep the **number of fields to a minimum**; every field on a layout costs render time.
- Put **required fields above the fold** so a user does not scroll to find what blocks the save.
- Use **sections** to group related fields.
- Always place **Record Type and the system fields** somewhere on the layout, so support can see what a record actually is.

## Search layouts, list views, compact layouts, lookup filters

Same naming rule: no "Layout" in the name.

| Element | Rule |
|---|---|
| Search layouts | Show enough columns for a user to tell two similar results apart |
| List views | Show what is relevant to whoever uses that view, not the default three columns |
| Compact layouts | Give a **large text area a section of its own**, with 6 or more visible lines — anything less is unreadable |
| Lookup filters | Decide deliberately whether each lookup needs one. Filtering out closed-lost opportunities or inactive accounts stops the wrong record being picked |

## Lightning pages

Named `{sobject API Name} Org Default` — prefixed with the object's API name, suffixed with the intended visibility or use case:

```
Problem__c Org Default
Case__c Support Console
```

Tab order is fixed:

1. **Details** first
2. Object- or process-specific tabs in between
3. **Related** last

## Approval processes

- Hard-code no Ids, in the process or in any field update or email alert it triggers.
- Do **not** use *Re-evaluate Workflow Rules after Field Change* on a field update. It re-enters automation in an order nobody can predict and is a reliable source of recursion.

## Custom labels

- Do not prefix common terms. A label for "Save" is `Save`, not `Common_Save` or `Util_Save`.
- Do not create a second label with the same value as an existing one. Duplicates drift apart in translation and then the UI says two different things in two places.

## Validation rules

- Always reference `User.Ignore_Validation_Rules__c` so the rule can be bypassed for data loads and migrations.
- Hard-code no Ids.
- Define the error message **at the field location** rather than at the top of the page, so the user sees what to fix where they are looking.

## Flows

Named *Object · Record Type Label (if applicable) · Context · Event*:

```
Problem Asset_MQ Standard_Before_Upsert
```

Give every flow a feature toggle the same way validation rules have one, so it can be switched off without deactivating and redeploying.

Background deck: [Salesforce Flow Basics](https://agcocorp-my.sharepoint.com/:p:/p/lauren_kamrad/EWyw-7HOrOZLi6aqjLsmS2cB682Oz63GP0jOkN7uITkR7g) (internal — SharePoint sign-in required).

## Visualforce

| Rule | Why |
|---|---|
| Link with `{!$Page.PageName}`, never `value="/apex/PageName"` | The hard-coded path breaks under a namespace or a site prefix |
| Show errors with `<apex:pageMessages />` | One consistent place for validation and Apex messages |
| Mark non-persisted data `transient` | View state has a hard limit; transient data does not count toward it |
| Wrap dynamic SOQL input in `String.escapeSingleQuotes()` | Prevents SOQL injection through user input |

Pages and their controllers are named together, with the controller suffixed `Ctrl` or `Controller`:

```
DemandPlan  →  DemandPlanCtrl
```