AccountedPro - Tabs and their order
A tab is a named preset over the same list — My Forms, Open, Pending my approval. Tabs compose with the filter bar rather than replacing it: whatever a reader has typed into the bar still applies inside the tab, and switching tabs keeps it.
Tabs are deliberately not separate layouts. One data source, one query shape, one set of buttons — otherwise it is two dashboards wearing a trench coat, and two saved views would serve better.
Making one
- Open the Tabs panel and press + Tab.
- Give it a Label.
- Build its condition — the builder described in Filters and conditions.
- Tick Show a count for the badge beside the label.
Drag tabs in the list to reorder them; the first is what readers land on.
The count badge
The count is computed over the whole filtered set, not the page on screen, and every tab's badge comes back in one call rather than one per tab.
Counts are permission-aware: a badge only counts records the reader could open. If two people see different numbers on the same tab, that is why.
A count that involves a child table counts each parent once, however many of its child rows match — "orders containing this serial number", not "matching lines".
What a tab's condition can hold
Everything the condition builder offers: OR, NOT, nested groups, drill-down into linked documents, @me, relative dates. All of it is saved.
Older layouts. Before August 2026 a tab could only store a flat list of conditions, and a group, a NOT or a hop was silently dropped on save. Those layouts still open, and are rewritten as a full condition the next time the tab is edited. If a tab from that era looks like it lost something, that is what happened — rebuild it once and it will hold.
The order a tab opens in
Under Order by, name the fields the tab sorts by, in priority order, each with its own Direction — A → Z, oldest first or Z → A, newest first. Up to four.
| Example | Result |
|---|---|
status ↑ then modified ↓ |
Grouped by status, newest first inside each |
date ↓ |
Newest date first |
customer.customer_name ↑ |
Sorted by the customer's name, not their ID |
The sort field picker walks into Link fields with the same › chevron used everywhere else, so a list can be ordered by a value that lives on a linked document.
The reader still wins
Clicking a column heading takes over from the tab's order, and Frappe's sort control in the toolbar shows what is actually in force — it is kept in step rather than left saying something else. Leaving the tab and coming back restores the tab's own order.
What each kind of sort costs
| Sort by | How it runs |
|---|---|
| A field on the record | Goes into the query. Free, correct across every page. |
| A field on a linked document | Cannot: a list query has no join, and the framework refuses functions in an order clause. The matching records are ordered separately and then paged. |
The second is bounded to the first 5,000 matching records, and the builder says so under the setting. For a few hundred records it makes no difference; on a very large list, sort by a field on the record itself and let the linked value be a column.
Blanks sort last ascending. Numbers sort numerically even when the field is text, so 9 comes before 10 before 100.
Tabs only some people see
Show this only when… takes a condition, a list of roles, or both, so an approvals tab appears only for approvers. It is not rendered at all for anyone else.
A tab with its own columns
Columns override lets a tab show a different column set — a Financials tab with amounts and due dates while the default tab shows picking information. Leave it empty to reuse the main columns.
Tabs on a Server Script data source
When the rows come from a Server Script there are no fieldnames to filter on, so a tab narrows it by passing arguments instead. The script decides what they mean. See Data sources.