A Grid Layout Came Back Wrong After an Update: Causes and Fixes
User Solutions TeamA grid that looks wrong after an update, most often a new column missing or columns in odd widths, comes from the collision between your saved layout and a shipped change, and resetting the grid to its default layout is the clean fix. EDGEBIC by User Solutions remembers each grid's column arrangement per user and reconciles it against shipped columns, but a change to an existing column's default cannot be reconciled, which is where the surprise lives.
This post sits in the EDGEBIC troubleshooting guide and is the update-collision companion to grid layout persistence explained and the sibling symptom a saved grid layout will not persist.
What You Are Seeing
You updated, opened a grid you use often, and something is off. A column that the release notes say is new is not there. Or the columns are the ones you had, but at widths that no longer fit the new content. Or a column you expected to be visible by default is hidden. Other planners on the same version may see it correctly, which makes it feel like a per-machine glitch. It is not; it is your saved layout meeting a shipped change.
Why It Happens
Your saved layout stores an explicit choice for each column: its order, its width, whether it is visible. When a new version ships, the grid reconciles that saved layout against the current columns.
- New columns are added in automatically. A genuinely new column is merged into your saved layout, so it should appear. Removed columns are dropped. Your widths and order survive. This reconciliation is why an update does not throw away your customization.
- A changed default on an existing column cannot be reconciled. If a release changes a column's default visibility or a view setting, your saved layout still holds the old explicit value, and nothing can tell whether you chose that value or simply inherited the previous default. Your stored choice wins, so the new default does not take effect for you.
- Your saved widths win over new defaults. That is the point of saving a layout, but next to a new column it can look wrong, because your widths were set before the new content existed.
So two people on the same version diverge: whoever had no saved layout, or whose saved layout did not conflict, sees the new arrangement; whoever had a conflicting saved value keeps it.
How to Fix It
Reset the grid to its default layout, then re-customize. The reset discards your stored choices and adopts the current defaults, including the new column and its intended visibility.
- Reset the grid's layout to default. Use the grid's restore-default action (how to restore a default grid layout covers where it lives). This clears the saved choices that were fighting the update.
- Confirm the new column and defaults appear. After the reset the grid reflects the shipped arrangement, so a missing column returns and a changed default takes effect.
- Re-arrange to your preference. Set widths and hide columns you do not want. Right after a reset an uncustomized grid may auto-fit its widths on the next data load; arrange it the way you want and move on.
- Navigate away to save. The layout is saved on navigate-away and on close, so leaving the view stores your new arrangement. From then on your saved layout is applied and the auto-fit no longer runs.
How to Prevent It
- Reset a grid after a release that changes its columns. If the notes mention a new or changed column on a grid you have customized, a quick reset adopts the change instead of fighting it.
- Keep customizations light on grids that change often. The more explicit choices you save, the more surface there is to collide with a shipped default. Hide only what you truly do not need.
- Standardize per role, not per person. If a team wants the same view, agree on an arrangement and reset-then-set it together after an update, so everyone adopts new columns at once.
- Save deliberately by navigating away. A layout you never leave is a layout that may not be stored the way you expect; navigating away is what commits it.
- Treat auto-fit as a first-run helper. An auto-fit only happens on a grid with no saved layout, so it stops once you save. If widths keep auto-fitting, you have not saved a layout for that grid yet.
If instead the grid will not remember your layout at all, that is a different symptom covered in a saved grid layout will not persist. And because an export is a snapshot of the grid exactly as displayed, a column left hidden by a layout carries straight into the file, which an exported spreadsheet missing rows or columns covers. For the underlying mechanism, see grid layout persistence explained.
Because your saved layout was captured before the column existed, and a saved layout carries an explicit choice for each column. New columns are added into your saved layout automatically, so a genuinely new column should appear. When it does not, the usual cause is that the change was to an existing column's default visibility, which a saved layout cannot tell apart from a choice you made. Reset the grid to its default layout to pick up the new arrangement, then re-hide any columns you do not want.
A saved layout stores your column widths, and it wins over new defaults so your customization survives an update. If a release changed a column's intended default width or a view setting, your saved widths still apply, which can look wrong next to the new column. The fix is to reset the grid layout, which discards the stored widths and adopts the current defaults, then re-arrange to taste. Your layout is saved again when you navigate away.
No. An update reconciles your saved layout against the current columns rather than replacing it: new columns are added and removed columns are dropped, so you keep your widths and arrangement while still seeing shipped columns. What an update cannot reconcile is a change to an existing column's default, because the saved layout holds an explicit value and nothing can tell whether you chose it or inherited an old default. In that one case you reset the grid to adopt the new default.
Expert Q&A: Deep Dive
Q: After the last update, half my planners see the new status column and half do not. Same grid, same version. Why the split?
A: The planners who do not see it are on saved layouts from before the column shipped, and in this case the change was to a column default the saved layout cannot reconcile, so their stored choice sticks. New columns are normally added into a saved layout automatically, so most shipped columns appear for everyone. For the ones that do not, have those planners reset the grid to its default layout, which adopts the current column set, then re-hide anything they do not want. Their new preference saves on navigate-away.
Q: I reset a grid to fix a missing column, but next time I opened it the widths were auto-fitted and my arrangement was gone. What happened?
A: A grid that has never had a saved layout auto-fits its columns when data loads, as a sensible default for a first-time view. Right after a reset there is no saved layout, so the next data load auto-fits. Arrange the columns the way you want after the reset and navigate away so the layout is saved; from then on your saved layout is applied and the auto-fit no longer runs. The auto-fit is a fallback for an uncustomized grid, not something that repeats once you have saved a layout.
Frequently Asked Questions
Ready to Transform Your Production Scheduling?
User Solutions has been helping manufacturers optimize their production schedules for over 35 years. One-time license, 5-day implementation.
User Solutions Team
Manufacturing Software Experts
User Solutions has been developing production planning and scheduling software for manufacturers since 1991. Our team combines 35+ years of manufacturing software expertise with deep industry knowledge to help factories optimize their operations.
Share this article
Related Articles
An Operation Moved and the Machine Was Free: Finding the Hidden Cause
A job slid and every machine shows open hours. Tooling is the cause the Gantt cannot draw. How to rule it in or out in two minutes before you chase calendars.
An Operation Shows Running Forever Though All Hours Are Logged
A step stays in progress after every hour is logged because completion is an explicit stamp, not an hours threshold. How to close it and stop it recurring.
Another User Changed This Record: Causes and Fixes
EDGEBIC refuses a save when the record moved after you loaded it. The usual cause is a colleague, but the message also appears when you are alone. How to read it and what to do.