# Architecting a Centralized Column Visibility Manager for Dynamic Perspective Tables **URL:** \ **Category:** Ignition\ **Tags:** ignition81, perspective\ **Created:** [March 5, 2026, 10:38pm UTC](https://forum.inductiveautomation.com/t/architecting-a-centralized-column-visibility-manager-for-dynamic-perspective-tables/114352 "2026-03-05T22:38:26Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![ryan.white](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ryan.white/32/73193_2.png) [@ryan.white](https://forum.inductiveautomation.com/u/ryan.white)\ **Post date:** [March 5, 2026, 11:24pm UTC](https://forum.inductiveautomation.com/t/architecting-a-centralized-column-visibility-manager-for-dynamic-perspective-tables/114352/2 "2026-03-05T23:24:39Z")
The centralized storage method more or less lines up with what I have recommended to others in the past for holding similar user specific information, like personalization and such. You could expand it to hold additional data other than just column visibility. (Sorting preferences or similar). Just make sure the top level property is set to private. > [@Save/restore component properties to DB](https://forum.inductiveautomation.com/t/save-restore-component-properties-to-db/88383/9): > > Correct. To make it sticky, save/load from the DB. I'd say this is much easier and more transparent than diving into using SDK functions, especially if you get another engineer who knows nothing about the project/customization data. (That's my opinion anyways). It would also essentially 'live' in only one or two places, the session startup handler and the user id value change event, as opposed to every component that needed some sort of customization. You could have a structure something alo… One pitfall I could see is if a single table is used for different queries, you could run into a case where column A needs to be hidden for query A, but should be shown for query B. That means you might need to include additional identifier information in your config data to indicate if the column visibility is for the table in general or a specific query on that table. > [@Farhan\_Basheer](#): > > onEditCellCommit Writing directly to the session props could leave you with orphaned key/value pairs if you change what columns are available for the table after saving a config, but that's a pretty negligible cost unless you have thousands of orphaned items. You could also run a cleanup operation on the storage table if you really needed/wanted to clean out stale keys. > [@Farhan\_Basheer](#): > > A helper function Are you able to modify your existing function that generates your columns to take an optional `userConfig` argument and pass the config for the table through that? Then when you are doing whatever logic to loop through and create the columns, you can check immediately to see if the column should be hidden or not. This would save you from looping over the list of columns again after their generation. I would still keep the helper for any post generation changes. On submission of new config, pass the existing generated columns, new config, and table Id, and adjust the columns based on the new config. --- _[View the full topic](https://forum.inductiveautomation.com/t/architecting-a-centralized-column-visibility-manager-for-dynamic-perspective-tables/114352)._