The grid on a small screen
A grid is a horizontal instrument, and a phone has no horizontal room. On a narrow display the Data screen falls back to a stacked layout: one record at a time, its fields listed down the page, with search and the filters already in force still working. The controls that only make sense across width — resizing, reordering, freezing — are not offered.
What survives#
- Reading. Every field of a record is legible, stacked rather than spread.
- Finding. Search still runs against the whole sheet, and a filter you set elsewhere is still narrowing it.
- Opening a saved view. The filters and the sort come with it; the column arrangement has nothing to arrange.
- A narrow edit. Changing one field goes through the owning service exactly as it does on a desktop, with the same validation and the same refusals.
That set is chosen around what people actually do on a phone: check something, correct something small, and move on. It is a reading surface with a pen attached, not a place to restructure a sheet.
What is dropped, and why#
| Control | On a phone | Reason |
|---|---|---|
| Column resize | Not offered | There is one column of content; width is not a variable |
| Column reorder | Not offered | Order is the stacked field order, which is fixed and readable |
| Freeze | Not offered | Nothing scrolls sideways for a frozen column to hold still against |
| Grouping | Not offered | Group headings and collapsed blocks need a table to sit in |
| Side-by-side comparison | Not possible | Comparing rows is what the width was for |
| Bulk selection | Avoid it here | Building an exact set on a small display is where the wrong set gets acted on |
Doing the wide work later#
On the phone, find the records and note what needs doing.
Result You have the answer you needed without waiting to be at a desk.
Make only the single-field corrections that are unambiguous.
Result The change is written through the same service, so nothing needs redoing later.
Leave bulk actions, import and merges for a wide display.
Result The set you act on is one you built with the filter count in front of you rather than one you assembled by thumb.
If a job genuinely has to happen now and only a phone is to hand, the Assistant is often the better route: describing the change in words and confirming a proposal needs no width at all. Its own narrow-display behaviour is covered in the Assistant on a phone and on a wide screen.
The same fallback for both audiences#
The Owner and a customer get the identical layout from the identical code. There is no reduced customer version and no operator-only convenience here — a customer request is rewritten to its own path and checked against the allowlist, and then handled by the same service.
That matters more than it sounds. A screen that behaves differently for one audience is the defect this product has had to correct repeatedly, and the reasoning behind holding to one implementation is set out in one implementation, two audiences.
Questions#
Can I still edit records from my phone?
Yes, one field at a time, through the same service and with the same validation. What you should not do is build a large selection on a small display — the count is harder to verify and the consequences of acting on the wrong set are the same size as they are anywhere else.
Why not just let the grid scroll sideways on a phone?
Because a table you can only see three columns of at a time is a worse way to read one record than a list of its fields. The fallback is not a smaller grid; it is a different presentation of the same records.
Do my saved views work on a phone?
Their filters and sort do, which is the part that defines the set. The column arrangement stored in the view has no effect, because there are no columns to arrange.