When building a CRM card with UI extensions, the interactive input components — Input, NumberInput, Select — render at a fixed, small size that can’t be changed. There’s no width, size, or fullWidth prop, and the documented Box flex fill mechanism has no effect on them inside a Table cell. So a NumberInput or Input placed in a table column stays a tiny box no matter how wide the column is set (via width={n} on the cell).
Use case
We have a lot of custom-logic & function requirements for building quotes that the native “Configure line items” screen doesn’t deliver on*, so we’ve created a custom line-item card that mimics HubSpot’s native “Configure line items” screen — an editable grid of products with Qty, Unit price, Discount, part numbers, etc. The natural design is an editable table: one row per line, inputs in each column. But because the inputs can’t be widened to fill their columns, the grid is unusable for editing — every field is a cramped ~30px box regardless of the column width. Our only workaround is to make the whole table read-only and push all editing into a separate side panel, one line at a time, which is a big step back from a spreadsheet-style editor.
What we’d like
A supported way to control the rendered width (and ideally height/font size) of interactive input components — even a constrained set of options would be enough. For example:
a width / size prop on Input / NumberInput / Select, or
having these controls honour Box flex / fill their container the way read-only cells do, or
a documented “fill cell” behaviour for inputs placed inside TableCell.
We understand the goal of keeping the CRM visually consistent, so this doesn’t need to be arbitrary CSS — just enough control to build a usable editable grid within HubSpot’s own design system.
Impact
This is the single blocker preventing UI-extension cards from replicating the editable line-item / table experiences that HubSpot ships natively. Any app trying to build an in-grid editor hits the same wall.
* specifically:
Can’t handle cost price being a different currency to unit price
Can’t handle bundles (yes there’re 3rd party add-ons, but they still don’t solve the bigger picture)
Some of our products require us to get a quotation from the supplier case-by-case, so need to flag where that’s the case
Handling cloning/moving/deleting multiple lines at once
Handling >1 SKU per product that can all be searched against
More advanced searching logic & flagging (if SKU xxx.xxx.xxx is searched, it shows xxx.xxx.xxx and xxx.xxx.xxx.1, etc. with no flag to highlight this isn’t an exact match)
Handling inflationary price increases for multi-year contracts (in custom cards, we can teach logic to say SKU X denotes the start of a new year, and what % uplift to apply per year) that applies to both price and cost
Being able to change the FX rate to look at how margins would be affected if the GBP-EUR rate changed given we buy from suppliers in EUR and sell to customers in GBP, etc.
Hi @OllieS and Happy Friday! Great to see you on the HubSpot Community!
Thank you so much for taking the time to detail your use case regarding the current limitations with input sizing in CRM card UI extensions.
I’d love to make sure our product teams see this feedback. For that, could you please submit the HubSpot Developer Feedback form? If it’s easier I can submit it on your behalf, just let me know.
In the meantime, I’d love to check with our Top Experts: Hi @Anton, @SteveHTM and @zach_threadint, if you’ve discovered any partial workarounds beyond side-panel editing, I’m sure others in the Community would be interested as well.
Thanks so much and have a wonderful weekend!
Bérangère
- Please note that I’m out of the office until August 27th -
Hi, @OllieS can confirm this matches the current state of UI Extension input components — the documented CRM action/UI component props don’t include a width, size, or fullWidth control for Input, NumberInput, or Select, and the fixed-size rendering inside table cells is a known constraint of the component library, not something you’re missing in the docs. HubSpot
A few workarounds that other builders have used for editable-grid-style cards, none of which are as clean as native prop support but may help in the short term:
Abbreviate cell content, expand on focus/interaction: instead of trying to widen the persistent input, show a compact read-only value in the cell and open a small inline popover/modal (anchored to that cell) with a properly-sized input when the rep clicks it. More clicks than a true spreadsheet, but keeps the grid dense and avoids the cramped 30px box while editing.
Move away from Table for the editable rows: build your own row layout using Box flex containers stacked vertically instead of Table/TableCell — flex containers do respect width/fill in most UI Extension layouts, and the fixed-size behavior seems specific to inputs rendered inside actual Table cells. You lose native table styling (borders, header alignment) but regain control over input width.
Batch-edit side panel with multi-select: since you already have a read-only table + side panel fallback, you could extend the side panel to accept multiple selected rows at once (checkbox column in the table) so at least bulk edits like clone/move/delete/uplift % don’t require one-line-at-a-time — partially addresses your “handling multiple lines at once” pain point without solving the core width issue.
For the actual ask — a supported width/size prop on interactive components — this is a genuine product gap in the UI Extensions component library, not a config issue on your end. I’d strongly recommend posting this on HubSpot Ideas (not just Developer Support) with the same detail you’ve given here, especially the “any app trying to build an in-grid editor hits the same wall” framing — that’s the kind of platform-level limitation that gets traction when other devs building similar line-item/quote tools upvote it. Worth linking this thread in the Ideas post so the context isn’t lost.
Thanks for confirming. We’ve tried moving away from tables, but this then caused other limitations, so we’ve ultimately had to move to a stripped-back table with an editing panel. Have posted to ideas, so let’s hope this gets traction.
