If you have been following my recent posts, you know I’ve been spending quite some time trying to tame the Action Bar component. We looked at filtering, splitting, and moving buttons around just to make the workspace look a bit cleaner.

But there was one thing that really bugged me. A behavior that just didn’t make sense, no matter how you looked at it. And I decided not to let it go.

So, here is a short story about a small fight for better UI design principles. 👇

The issue

---

You know the situation: you have an Action Bar on a record page. You have a wide monitor, plenty of screen real estate, and you want your buttons to be visible. You go to the backend, you set the Display type to “Button” and ensure Overflow is unchecked.

And the result? The Action Bar still hides half of your buttons into the “More” context menu. Even when there is clearly enough space around. 🫠

“It’s not a bug, it’s a feature”

---

I opened a case with ServiceNow support because I genuinely believed a component ignoring its container’s width is a defect. The initial response? It was… interesting.

They told me that the limit is hardcoded. Apparently, it was a request from a Business Unit to limit the space the Action Bar takes up, even if placed in a full-width container. So, the codebase explicitly prevents it from stretching.

Basically: “We hardcoded a width limit inside a reusable component.”

For me, that breaks the fundamental principles of UI design. A reusable component should respect the width of its parent container, not define its own arbitrary maximums. If I put it in a narrow column, it should shrink. If I put it in a full-width header, it should expand. That’s how responsiveness works.

The Victory 🏆

---

I pushed back (politely, of course, but firmly 😎). I argued that hardcoding layout constraints inside the component limits flexibility and forces us into bad UX.

And guess what?

The development team acknowledged the feedback. They admitted that the component should behave better. They have officially linked my case to a Problem Record and a fix is targeted for the Australia release. 🐨

This is a win not just for workspace on my project, but for everyone who wants responsive, clean UI design in ServiceNow. It proves that constructive pushback works. If something feels wrong in the platform, don’t just accept it as “system behavior” or a “hardcoded limit.” Challenge it.

Until Australia arrives, we stick with the workarounds, but at least we know the fix is coming!

Jan