Customer ID Column No Longer Takes Over the Table STAGING

"Customer ID column too long"

An app member's customer ID is a 32-character code, and when a member hasn't got one the system falls back to an even longer 36-character internal reference. Printed in full, that single column was taking a quarter of the whole table — wider than the customer's own name. It's now clamped, with the full code still there when you hover over it.

Measured, before and after

Window width	Before	After	Share of the table
1500px	277px	164px	24% → 14%
1366px	246px	145px	24% → 14%
1280px	243px	133px	25% → 14%
900px	243px	128px	25% → 15%

Both sets of numbers were taken from this same page on staging, so the improvement is measured against the real thing rather than estimated.

The customers table with the clamped ID column — The customer list. The ID sits in its own tidy column instead of crowding out everything else.

Measuring it turned up something worse than the width. The table was inside a panel that simply cut off anything too wide — so on a smaller laptop screen the Points and Joined columns were chopped off entirely, with no way to scroll across to them. The long column wasn't just ugly, it was costing you two columns of information. The table now scrolls sideways when it needs to, so nothing disappears.

The customers table on a narrower window — On a narrower window — every column is reachable now.

Searching by ID still works on the whole code

Shortening what's shown doesn't shorten what's searched. Pasting a complete 32-character ID into the search box still finds exactly that one customer — including the part of the code that's now hidden behind the ellipsis.

Searching by a full customer ID returns one row — A full ID pasted into search returns exactly one customer.

Checks

Suite	Result
Local, incl. a control run against the old layout	6/6
Staging, against the deployed build	6/6
Staging smoke regression	5/5

The checks measure the rendered layout — actual column widths and whether anything is being cut off — rather than checking that a styling rule was written, which would pass happily while the table was still broken. Each width is compared against its own before-number. Search is checked in both directions: a full ID returns exactly one customer, and a nonsense query returns none, so the filter is proven to be filtering. Run against the previous version, the checks drop to 1 of 6.

No database change was needed. Verified on staging.