A support lead opens a queue to reassign overdue cases. They narrow the list, select the checkbox above the first column, and click “Assign.” The interface says “Done.”
But what changed? The 50 cases on the current page? Every case matching the filters? Only the cases they have permission to edit?
That uncertainty is a data table UX problem. Better spacing will not resolve it.
In B2B SaaS products, tables often serve as the workspace where people investigate issues, compare records, prioritize work, and make changes at scale. Their design must explain both the information on screen and the consequences of acting on it.
Dworkz focuses on data-driven B2B software, where these details belong at the center of product design. A useful table connects the user’s task to the relevant information, makes its state understandable, and keeps actions predictable.
Four decisions deserve particular attention: column selection, saved views, selection scope, and bulk actions. Together, they determine whether users can turn a large dataset into a manageable workflow.
Start with the decision the table supports
Before choosing a table component, write down the job someone needs to complete.
“Manage cases” is too broad. “Find overdue cases without an owner and assign them to an available specialist” gives the team something concrete to design and test.
That task defines the information users need: case identity, due date, status, ownership, and possibly the skill required to resolve it. It also exposes questions that a static mockup can hide. Can closed cases be reassigned? Can users act across multiple pages? What happens when another teammate assigns a case first?
Map the workflow around five questions:
What does one row represent?
Which values determine the next action?
Which records can this user see and change?
What makes a record ineligible for an action?
How will the user verify the result?
A table is easier to simplify once the team understands what it must help people accomplish.
Column selection should support judgment
Column selection lets users choose which attributes appear in a table. It is especially useful when different roles need different evidence from the same records.
An operations lead might need owner, status, and deadline. An analyst might need category, processing time, and source. Giving both users every available field creates a wide table with little hierarchy.
Choose a useful default
Treat the default configuration as a product decision. Include enough information to identify records, compare relevant attributes, and decide what to do next.
Keep a stable identifier visible. When horizontal scrolling is necessary, pinning the record name or ID can preserve context. Use additional pinned columns sparingly so the remaining viewport stays useful.
There is no universal ideal number of columns. The right set depends on the task, the content, and the available space. Removing a field that users must repeatedly open a detail panel to inspect can make a visually cleaner table slower to use.
Make customization easy to understand
A column picker should show readable field names and which columns are currently visible. When the field list is long, add search and meaningful groups. Explain unfamiliar terms where users make the choice.
Let users reorder columns, restore the default, and recognize required fields. Provide keyboard alternatives to drag-and-drop reordering.
If users can make several changes before committing, provide clear Apply and Cancel controls. If changes apply immediately, make that behavior consistent and easy to reverse.
Hiding a column must not silently remove a filter or sort rule that uses it. Keep those rules visible elsewhere, for example: “Sorted by last activity, oldest first,” even when Last activity is hidden.
Separate visibility from access
A hidden column is a display preference, not a permission boundary. Data access must be enforced independently of the column picker.
Exports need their own explicit contract. Explain whether an export includes visible columns, selected fields, or another approved set. A user who hides a sensitive field should not have to guess whether it will appear in the downloaded file.
Saved views should preserve a repeatable way of working
A saved view stores a useful table configuration so users can return to it without rebuilding their workspace.
Name views around a recurring purpose: “Unassigned overdue cases,” “My open investigations,” or “Ready for review.” These names explain why the view exists.
Decide deliberately what the product saves.
Setting | Recommended behavior |
|---|---|
Filters and search | Save the criteria; make their scope visible. |
Sort order | Save the field, direction, and supported secondary sorts. |
Columns | Save visibility and order; define whether widths and pinning travel with the view. |
Grouping | Save it when grouping is part of the task. |
Display density | Often better as a personal preference than a shared setting. |
Selected records | Keep separate from the view by default. |
Current page | Usually return to the start when reopening a view. |
These are design recommendations, not a universal specification. The important requirement is that the behavior stays understandable across the product.
Distinguish a saved view from temporary changes
Suppose a user opens “Unassigned overdue cases,” then adds a region filter. Show that the configuration has changed. Offer clear choices such as Save changes, Save as new view, and Reset changes.
For a shared view, explain who can update the definition and who will see the change. Personal exploration should not unexpectedly rewrite a team’s workspace.
Sharing a view also should not grant access to its underlying records. Two teammates may see different result counts because they have different permissions. Explain that this difference could cause confusion.
Explain dynamic criteria
“Due in the next seven days” moves with time. “Due November 1–7” does not. Likewise, “Assigned to me” should resolve to the person opening the view when that is the intended behavior.
A saved view is normally a live query and display configuration, not a frozen report. If people need to preserve exactly what they saw at a particular time, provide a separately named snapshot or export workflow.
When a saved field is removed or permissions change, explain what is no longer available. Silently dropping a filter can broaden a work queue in ways users may not notice.
Selection scope must be explicit
Selection scope defines which records an action will affect. It becomes particularly important when the table spans multiple pages or loads rows as users scroll.
“Select all” can mean all rows on the current page, all matching records, or every record the user can access. Those are materially different actions.
Separate page selection from result selection
For a paginated queue, a clear pattern is:
The header checkbox selects the 50 rows on the current page.
A message confirms: “50 cases on this page selected.”
A separate control offers: “Select all 1,284 matching cases.”
After activation, the message becomes: “All 1,284 matching cases selected.”
Keep Clear selection available. If users deselect individual records from the full result set, show the new count and make the exclusions reviewable.
The header checkbox also needs an understandable partial-selection state. Its visual state and accessible label should reflect the scope it controls.
Define what happens when the table changes
Sorting changes order; filtering changes membership. Those operations should not accidentally redefine the records a user intends to change.
For an operational queue, a reasonable starting policy is:
Preserve selection across sorting and pagination, using stable record identities.
Show the total selected count when some selected records are off screen.
Clear selection with a visible explanation when filters or saved views change.
If the workflow requires preserving selection across filters, expose hidden selections and provide a selected-records review.
Choose the policy with users and apply it consistently. Silent persistence can be as confusing as silent clearing.
Account for changing data
An “all matching” selection can change while someone is working. New records may arrive, existing records may leave the queue, and permissions may change.
Define when membership is fixed. For consequential actions, resolve the target set at a clear review or confirmation step and revalidate eligibility before execution. If the product intentionally uses a live query at execution time, disclose that behavior and refresh the scope before the user commits.
The count the interface promises must correspond to the target set the system actually processes.
Bulk actions need a complete interaction flow
Bulk actions let users apply one operation to multiple records. Their value comes from removing repetitive work, but that efficiency also magnifies mistakes.
A bulk-action toolbar should identify the selection and offer relevant operations. Carbon’s data table guidance illustrates this general pattern: selecting rows reveals batch actions for the selected items.
The workflow still needs to answer four questions: What is selected? What can change? What will happen? What actually happened?
Explain eligibility before execution
Suppose a user selects 50 cases, but eight are closed and cannot be reassigned.
Do not quietly skip them. State: “42 of 50 selected cases can be reassigned. Eight closed cases will be skipped.” Provide a way to review those exceptions.
Some operations should be blocked if any selected record is ineligible. Others can safely proceed with an eligible subset. Define the rule for each action. For a disabled action, provide a discoverable explanation that also works without a mouse.
Match confirmation to the consequence
Adding a reversible internal tag may need only immediate feedback and a reliable undo option. Changing access, deleting records, or sending external notifications deserves a more deliberate review.
A useful confirmation explains the action, target count, destination or new value, exclusions, and any side effects. Its button names the operation, such as “Assign 42 cases.”
For bulk editing, distinguish “Leave unchanged” from “Clear value.” An empty input should never leave users guessing whether existing data will be removed.
Offer undo only when the system can reliably reverse the operation. Actions with external effects may require a compensating workflow rather than a simple reversal.
Design progress and recovery
A long-running operation needs a durable status that users can revisit. Explain whether it continues if they leave the page and whether cancellation stops only the remaining work.
Report outcomes precisely. In the 50-case example, the final result might be:
“39 cases reassigned. Three failed. Eight closed cases skipped.”
Provide the affected records and understandable reasons. Let users retry eligible failures without repeating successful changes. Prevent duplicate submissions, and recheck permissions and record state on the server when the action runs.
For consequential changes, retain an activity record showing the actor, action, time, scope, and outcome. Completion feedback helps the current user; history helps the team understand the change later.
An annotated table audit
The following audit uses a fictional operations queue. It demonstrates how to assess behavior and consequences, rather than presenting findings from a Dworkz client project.
The task is to find overdue cases and reassign active work to a specialist. There are 1,284 matching cases, displayed 50 per page.
Example interface under review
View: Overdue cases [A] Filters: 2 [B] Columns: gear icon [C] Selection message: “50 selected” [D] Actions: Assign | Close | Export [E]
Select [D] | Case [C] | Status [F] | Owner | Due [F] |
|---|---|---|---|---|
Selected | CS-1048 | Open | Unassigned | Sep 21 |
Selected | CS-1049 | Closed | M. Chen | Sep 20 |
Selected | CS-1050 | Waiting | Unassigned | Sep 19 |
Excerpt: three of the 50 selected rows are shown above. Footer: “1–50 of 1,284.” After Assign, the interface displays “Done.” [G]
Audit findings and annotations
Priority reflects potential task failure and consequences in this example. Validate it against actual permissions, action behavior, and user research.
Ref | Finding | Priority | Recommended correction |
|---|---|---|---|
D | “50 selected” does not explain page or cross-page scope. | High | State the scope; offer selection of all matching records separately. |
E | Assign appears available for a selection containing closed cases. | High | Show eligibility and exceptions before execution. |
G | “Done” hides partial failure and skipped records. | High | Report successes, failures, and skips; support targeted retry. |
A | The view label does not reveal unsaved changes or ownership. | Medium | Show modified state and personal or shared status. |
B | “Filters: 2” conceals the rules defining the queue. | Medium | Show active criteria and make them easy to inspect. |
C | Column settings are hard to discover; export fields are unspecified. | Medium | Use a labeled Columns control and explicit export settings. |
F | Status does not explain eligibility; abbreviated dates lack context. | Medium | Explain action restrictions and provide unambiguous dates. |
If the bulk operation could change unauthorized records or produce irreversible harm, escalate the relevant finding to Critical. Severity should follow the consequence, not the size of the visual defect.
What the corrected experience should communicate
Before selection, show “Overdue cases — Personal view” and the active criteria “Due before today” and “Region: West.” Display “Due date, oldest first” as the sort rule.
After the page checkbox is selected, show “50 cases on this page selected” alongside “Select all 1,284 matching cases.”
Before assignment, show “Assign 42 eligible cases to Maya Chen. Eight closed cases will be skipped.” If assignment triggers notifications, state that before confirmation.
After processing, show “39 reassigned, three failed, eight skipped,” with controls to review the exceptions and retry eligible failures.
Each message answers a different question. Together, they make the operation understandable from initial filtering through recovery.
Make accessibility part of the behavior
Choose the interaction model before adding keyboard shortcuts. W3C distinguishes a semantic table, which can contain individual interactive controls, from an interactive grid with managed focus and directional keyboard navigation. Adding sorting or checkboxes does not automatically mean the whole table needs grid behavior.
Use native table semantics when they fit. If you implement a grid, implement and test its keyboard behavior, focus management, and accessible states.
In either model, users should be able to identify rows, understand sort order, select records, and reach the bulk-action controls without relying on a mouse. Do not communicate status or selection through color alone.
Test long values, horizontal scrolling, zoom, empty results, loading, and errors. Distinguish “No cases exist” from “No cases match these filters” and “Cases could not be loaded.” After a bulk change, preserve a sensible focus location even if affected rows disappear from the current view.
Test understanding as well as speed
A table can feel fast while leaving users uncertain about what they changed. Test whether people can predict the result before they act.
Ask a participant to find overdue cases, add a useful column, save a personal view, and select records across pages. Before they run a bulk action, ask them to explain which records will change. Then introduce an ineligible record or a partial failure and observe how they recover.
Measure task completion, time to a verified result, scope mistakes, repeated setup effort, and recovery success. Record where users hesitate and what they expect the system to do.
Use those observations to prioritize the redesign. A less prominent toolbar may be inconvenient. An ambiguous selection that changes the wrong records is a more consequential problem.
At Dworkz, our focus is helping B2B SaaS companies make complex products easier to understand and use. Data table design belongs in that work because it connects information directly to operational decisions. When columns, views, selections, and actions follow clear rules, users can spend more attention on the work itself.
If your product’s tables require repeated setup or leave users unsure about bulk changes, start with one critical workflow. Dworkz can help you assess the experience and plan a practical redesign.
FAQ
How many columns should a B2B SaaS table show?
Show the fields users need for the primary task, including a stable record identifier. Validate the default with realistic data and user testing. Offer customization when roles or workflows need different evidence.
What is the difference between a saved view and a filter?
A filter determines which records qualify for display. A saved view can preserve filters together with search, sorting, columns, and other configuration. It usually shows current matching data rather than a historical snapshot.
Should Select all include every page?
It can, but users should explicitly understand and choose that scope. A clear pattern separates selecting the current page from selecting all matching records and confirms the count for each.
What should happen when some bulk actions fail?
Report successful, failed, and skipped records separately. Explain the exceptions, provide a reviewable result, and allow retrying eligible failures without repeating successful changes.
Should a saved view remember selected rows?
Usually not. Views preserve a way of finding and displaying records; selection identifies targets for an action. If users need a persistent collection, give that feature a distinct name and explain its membership rules.
