Data Layouts

What a Data Layout Is

A data layout arranges the fields of a record into a designed screen rather than a list.

Where to find it

Architect Panel → Layout & Pages:

• Data Layouts — the layouts, then Layout Builder on a row
• Record Layout — per-field sections and widths

How a layout is built

A layout belongs to a table and is made of rows. Each row has its own properties, and fields are placed into cells within it, each with a type and an order.

So the structure is rows and cells rather than a single ordered list, which is what allows two fields side by side and a wide field on its own.

The builder is a row action

Layouts are listed under Data Layouts, and the actual arrangement is edited through Layout Builder on the layout’s row. That is easy to miss.

Why bother

A record with forty fields in creation order is a form nobody completes correctly. Grouping related fields, putting the important ones first and giving the rest less prominence is the difference between a screen people use and one they resent.

Design for the task

The order should follow how somebody actually works through the record, not the order the fields were added or how the database is arranged.

Watch somebody complete one. The field they scroll back to is the field in the wrong place.

Field-level layout is separate

Alongside layouts, each field on a table can carry its own section, width and whether it starts a new row. That covers the common case where you want a sensible arrangement without designing a full layout.

A tenant’s own setting beats the shared one for the same field, so a customer can adjust an arrangement without affecting anybody else.

Use width deliberately

A postcode field the width of the screen looks wrong and invites the wrong input. Field width is a hint about what belongs in it, and getting it roughly right removes a surprising amount of confusion.

One good layout beats several

The temptation is a layout per team, per role, per situation. Each is one more thing to maintain when a field is added, and they diverge quietly.

Start with one that works for everybody and add another only when the need is real.

Layouts can carry a custom function

Where a layout needs behaviour beyond arrangement, it can name a custom function. Use it sparingly — it is code attached to a screen, and it is invisible to whoever maintains the layout later.

Worked example

A case record originally showed thirty-one fields in creation order. Rearranged into four sections — who, what, when, and outcome — with the six fields staff actually complete at the top, the average time to log a case fell noticeably and the mandatory fields stopped being missed.

Recommendations

• Order by the task, not by the database.
• Use field width as a hint about the content.
• One layout until a second is genuinely needed.
• Watch somebody use it before deciding it is finished.

Building a Layout

A layout is a row, then an arrangement built in the layout builder.

Where to find it

Architect Panel → Layout & Pages:

• Data Layouts — the layouts, then Layout Builder on a row
• Record Layout — per-field sections and widths

Decide first

1. Which table, and which of its fields belong on this screen at all.
2. Who uses it, and what they are trying to do.
3. The order they work in.
4. What can be hidden or moved out of the way.

The fourth is the one that transforms a screen. Most records have fields that matter to a report and not to the person filling the form in.

Then build in this order

1. Create the layout against its table.
2. Open the layout builder from the row.
3. Add rows for each logical group.
4. Place fields into cells, widest first within each row.
5. Check it on a phone.
6. Have somebody who is not you complete a record with it.

Group by meaning, not by type

All the dates together is a grouping that helps nobody. The dates relevant to reporting a problem, next to the other fields relevant to reporting a problem, is a grouping somebody can work through.

Put required fields where they will be seen

A mandatory field at the bottom of a long screen is a field people reach after deciding they have finished. Required fields belong near the top.

Check it on a phone

Rows collapse on narrow screens, and a layout designed on a wide monitor can become a very long single column with the important fields somewhere in the middle.

If any of your users are on phones, this is not optional.

Beware of fields added later

A new field on the table does not place itself sensibly. Adding a field is the moment to revisit the layout, or it appears at the end where nobody looks.

Test with a real record

Not an empty one. Long values, empty values, a very long note — those are what reveal a layout that looks fine with placeholder text.

Ask somebody else to use it

The person who built a layout knows where everything is. The test that matters is somebody who does not, completing a real record, without being helped.

Worked example

A layout was built in four rows with the six required fields in the first two, checked on a phone where one row had collapsed badly, and then tested by a colleague completing a real case. Two fields were moved as a result of watching them scroll back.

Recommendations

• Decide what to leave off before arranging anything.
• Required fields near the top.
• Check on a phone if anybody uses one.
• Revisit the layout whenever a field is added.

Sharing and Reusing Layouts

A layout is worth building once and using widely. The risk is a proliferation nobody maintains.

Where to find it

Architect Panel → Layout & Pages:

• Data Layouts — the layouts, then Layout Builder on a row
• Record Layout — per-field sections and widths

Admin Panel → User Administration:

• User Groups — who a layout is offered to

Prefer a shared default

One layout used by everybody is one layout to update when a field is added. Three role-specific layouts are three, and in practice two of them will be updated.

Start shared and split only when a genuine difference appears.

When a separate layout is justified

• A genuinely different task — logging a case against investigating one.
• A different audience — a customer-facing screen against an internal one.
• A different device — a short mobile layout for field staff.

Not "this team prefers a different order".

Name them so the purpose is obvious

"Case — log", "Case — investigate", "Case — customer". Somebody choosing a layout six months from now has the name and nothing else.

Layouts drift

A field added to one and not the others, a group reordered in one place. Over a year the set diverges until nobody can say which is correct.

A periodic comparison — do these layouts still contain the same fields — takes minutes and prevents that.

Retire what nobody uses

Layouts accumulate from experiments and one-off requirements. Where the platform records how often a layout is used, that is the list to work from; where it does not, ask.

Layouts do not enforce anything

Worth being explicit about. Leaving a field off a layout hides it on that screen; it does not stop anybody seeing or changing it elsewhere.

If a field must not be visible to somebody, that is field security, not layout design.

Tell people when a layout changes

Somebody who has learned where a field is will look for it there. A rearrangement without warning generates support contacts that a single sentence would have prevented.

Worked example

An organisation runs one shared layout per table, with a single exception for field staff who use a short mobile version. The two are compared quarterly to confirm they hold the same fields, which twice caught a field added to only one.

Recommendations

• One shared layout until a real difference appears.
• Name layouts by purpose.
• Compare layouts periodically for drift.
• Never use a layout as a security control.