Ignition's built-in Perspective Table is genuinely good. It binds to a dataset or array with no scripting, virtualizes long lists, sorts, filters and even edits cells. For a read-mostly list it's often all you need, and you should reach for it first.
But put it on a real production screen — a work-order queue, a batch log, an asset register that operators live in all day — and you start hitting walls. Here are the six we hit most often, and how we think about closing them.
1. You can't pin a column
Wide tables scroll horizontally, and the moment they do, the identifying column (asset tag, order number, name) scrolls off with everything else. Operators lose their place. The stock table has no way to freeze a column to the left or right edge. A grid that supports pinned columns keeps that anchor visible while the rest of the data scrolls underneath it.
2. Sorting stops at one column
"Sort by line, then by start time" is a completely normal request. The built-in table sorts a single column at a time, so multi-key ordering means pre-sorting the dataset in a script or transform — and re-doing it whenever the user wants a different order. True multi-column sort, with a visible sort priority, belongs in the grid itself.
3. Inline editing has no real validation
You can make a Perspective table cell editable, but the validation story is thin. There's no built-in way to enforce required values, numeric min/max, or a regex pattern, and no clear visual state for a dirty-but-unsaved or invalid cell before write-back. On a screen where a typo writes straight to a tag or a database, that matters. You want required / min-max / regex rules and obvious dirty & invalid markers as a first-class feature.
4. No grouped (multi-row) headers
Dense engineering tables group related columns — "Counts & Cost", "Audit" — under a shared banner header. The stock table is a flat header row, so the relationship between columns has to live in the column names themselves. Multi-level grouped headers make a 15-column table readable at a glance.
5. Aggregation means another component
Want a sum or average across the visible rows? You're building a separate pinned footer, wiring it to the same dataset, and keeping the two in sync. A grid with a built-in summary / totals row gives you per-column aggregation without the duplicate plumbing.
6. Rich cells turn into a pile of view-based cells
Status pills, progress bars, sparklines, badges, dropdowns — each one in the stock table is a custom view-based cell you build and maintain. That's a lot of small views for what should be a column type. Treating these as configurable cell renderers keeps the table declarative.
How we close the gap
This list is exactly why we built Perspective DataGrid Pro. It's a drop-in Perspective component (built on AG Grid) that adds pinned columns, multi-column sort, validated inline editing, grouped headers, a summary row and rich cell types — all configured from properties in the designer, no scripting. You can try the live preview and toggle every one of these features on real sample data.
It won't replace the stock table for simple lists, and it shouldn't. But when you've outgrown it, you shouldn't have to rebuild a data grid from scratch on every project.
Hitting a wall we didn't list? Tell us what's missing — the roadmap is driven by what developers actually run into.