Admin table action buttons always need scrolling to the far right — too many columns, or just the wrong order?

In admin tables, action buttons often require dragging the scrollbar all the way to the far right before you can find them. In most cases this isn't because there are truly too many fields; it's because the columns were never prioritized: the action area that should be fixed on the right isn't fixed, long text that should be tucked into a detail view is taking up body space, and similar fields that should be merged each get their own column. Based on common 2026 delivery habits, a comfortable experience range for the default visible body columns in one desktop viewport is 5 to 8 columns, with the action column fixed separately on one side. This range isn't a hard standard, but it can be used to quickly judge: is this table truly 'information overloaded,' or was the structure simply never finished?

Why horizontal scrolling is sometimes tolerable and sometimes not

The cost of horizontal scrolling isn't the drag motion itself; it's that it breaks the ability to compare. When users check data row by row, their eyes have to move back and forth; once the identifier column scrolls out of view, the numbers on the right lose their owner, and users must rely on memory to map them. The same scrolling that rarely draws complaints in a 'look at one row' detail lookup will be repeatedly flagged in review and reconciliation scenarios where rows must be compared one by one. The action column is even more obvious: it should be clickable at hand for every row-level action, but once pushed to the end of the scrollbar, users have to drag first every time they act.

To judge whether a table can accept horizontal scrolling, ask three questions first: Are users checking row by row, or occasionally looking up one record? Do columns have to be compared side by side? After scrolling right, is there still information on the left that anchors the identity of that row? If two of these three lean toward 'needs comparison,' consider sticky columns, splitting columns, or changing the presentation instead of continuing to squeeze column widths.

• Row-by-row checking type (reconciliation, review, scheduling): minimize horizontal scrolling, prioritize sticky positioning columns, and fix the action column separately.
• Occasional lookup type (logs, transaction records): horizontal scrolling is acceptable, but the table header, filter state, and action entry point should always remain visible.
• Long text type (notes, addresses, descriptions): truncate directly in the body, and let the full content go to a hover or detail view without taking up column width.

Assign column roles first, then decide who stays and who goes

The root cause of too many columns is often not 'too many fields' but that no one ever assigned roles to the fields. The same field, as a locating identifier versus as editable content, is handled completely differently. Group by role first, and deciding which columns to keep becomes a well-founded question, instead of adding a column whenever a new requirement arrives until no one dares delete any.

1. Identifier columns (ID, name, avatar plus name): their job is to identify the row. When possible they should be sticky, with width based on common values, not stretched open for the rare extremely long value.
2. Status columns (in progress, expired, abnormal): used for quick scanning. Tags or color blocks work well, with fixed width and consistent wording, avoiding a different phrasing on every page.
3. Numeric columns (amount, quantity, duration): need alignment for comparison. Right-align, use tabular figures, unify decimal places, and put units in the header rather than stuffing them into every cell.
4. Action columns (view, edit, more): subtract buttons, tuck low-frequency actions into 'More,' and fix the column where the user's eyes are likely to land.
5. Long text columns (notes, description): truncate by default and provide a view entry; keep only the first few characters in the body column.

Each column type has different concerns: identifier columns fear being stretched wide, status columns fear clashing colors, numeric columns fear misalignment that hides size relationships, action columns fear ever more buttons pushed ever farther away, and long text columns fear eating horizontal space. After grouping, define column widths, sticky behavior, and field order; the probability of rework later will be lower.

Where should the action column go: fixed right, fixed left, or inline expansion

These approaches aren't mutually exclusive. The difference is who carries the complexity: the user's dragging action, the user's configuration action, or the jump between pages. Before choosing, clarify whether the main users are professional roles who use it daily or people who come in occasionally to look something up.

• Option A: Fix the action column on the right. Suitable for tables with frequent actions and uniform row-level actions. Implementation cost is relatively low, with a typical range of half a day to one person-day on the front end; the risk is that on narrow screens the fixed area squeezes the body.
• Option B: Keep default columns lean and leave the rest to column settings. Suitable for admin systems with many fields and large differences in what different roles care about. Implementation plus integration has a typical range of 1 to 3 person-days; the risk is that if the default columns aren't configured well, it's as if nothing was done.
• Option C: Keep only key columns in the main table; put actions and secondary fields into inline expansion or detail. Suitable for scenarios with long low-frequency fields and low viewing frequency. Implementation cost is in the middle; the risk is too much back-and-forth jumping, which can actually reduce checking efficiency.

A common 2026 combination is: provide a lean default column set, fix the action column on one side, send long text to detail or hover, and keep an entry for column settings. Note that column settings are only valuable when the default columns are restrained enough — if twenty-plus columns are all open by default, the user's first impression is still a table that needs horizontal dragging, and the action buttons are still at the end.

On the delivery floor: fields come from the business side, and timelines are compressed

In projects, admin table rework commonly happens when two constraints appear at the same time: one is that fields are handed over directly by the business side, often a dozen columns at once, all marked 'must display'; the other is that the timeline is only a few weeks, leaving no time to split secondary information into a detail page. A common approach is to first go through the columns by role, break 'must display' into 'display by default' and 'available on demand,' move the action column from the end into the fixed area, and confirm item by item with the business side. In most cases this can be compressed to six to eight default columns, with the rest going into column settings or detail.

The cost is spending an extra half day to a day aligning on definitions up front; the benefit is not having to change the structure before or after launch. Conversely, skipping this step and starting work directly often leads to rework at review or before launch, changing headers, column widths, sticky logic, and how various statuses are displayed. The rework volume usually clearly exceeds the time spent aligning up front. The same applies when materials are incomplete — for example, if status enumeration wording is missing, placeholder rules must be defined first; otherwise the same column will have three or four different phrasings, and someone will have to clean them up one by one during review.

Check against these items at acceptance

• At the target resolution (such as the common 1366×768 or typical laptop sizes), can all locating information and one or two high-frequency values be read without dragging the horizontal scrollbar?
• Can row-level actions be clicked without horizontal scrolling, and is the number of buttons within a scannable range?
• Do empty data, loading, extremely long text, and only-one-record cases each have a corresponding presentation, rather than a blank area?
• Does the table header stay visible during vertical scrolling, and are the current sorting, filtering, and pagination states visible?
• After filter conditions change, can users still tell 'which batch of data am I looking at now'?

Applicable scenarios and boundaries

The approach fits when fields are truly numerous, users need to compare repeatedly and act frequently, and the scenario is an internal admin system or professional tool — then spending time prioritizing columns pays off. The unsuitable cases should also be stated clearly: one-off lists for ordinary consumers (product lists, message lists) usually have only a few columns, and the focus should be on the hierarchy of the list item itself and the click target; forcing sticky columns and column settings only adds cognitive load. Mobile narrow screens are also not suitable for porting a desktop table as-is; a common approach is to change to card-style entries, keeping only the name, status, and one key value, with the rest tucked into detail. In addition, if only an occasional long field breaks the layout, address that field first rather than rebuilding the entire column structure for one table.

FAQ

How many columns is too many for an admin table?

There is no absolute number. A comfortable experience range for default visible body columns on desktop is 5 to 8 columns. Beyond that, prioritize splitting, collapsing, or moving into detail rather than just adding horizontal scrolling.

Is it better to fix the action column on the left or the right?

A common approach is fixing it on the right, because most people's reading and mouse movement habits extend to the right; if there is already a sticky identifier column on the left, it can also go on the left. The key is to stop letting it scroll along with everything else.

How many sticky columns are appropriate?

A common approach is to fix one to two columns, usually locating information such as ID or name, plus the fixed action column. Fixing too many squeezes the body space and actually narrows the readable area.

Do long texts like notes always need to be truncated?

In most cases, truncating by default and providing a view entry is a common approach. If that field itself is the main basis for judgment, that means it shouldn't live in the table and is better carried by a detail page.

How should mobile admin tables be handled?

On narrow screens, converting the table into card-style entries is more common. Each card keeps the name, status, and one key value, with action buttons directly inside the card and the remaining fields tucked into detail.

If you're stuck on a table where you have to drag right to find the buttons, don't rush to adjust column widths: group the columns into identifier, status, numeric, action, and long text, then define default display, sticky columns, and the action area position. Many horizontal scrolling problems will be resolved at this step. Lists with few fields that users only glance at don't need this approach. Based on enterprise project delivery habits, column priorities are usually reviewed with the business side before starting; when the order is right, later changes are mostly details rather than structure.