Fluent, ServiceNow IDE and Build Agent - with Horizon Design System and Now Components
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-03-2025 09:40 AM
Folks,
I'm new to the use of Fluent, the ServiceNow IDE and the Build Agent. I'm really excited by ow much I am able to achieve using the Build agent and the initial results are very impressive.
We are coming from a position where as a Build Partner, we have invested heavily in Workspace, Now Experience and the use of Now Components. Including years of wrestling with the frustrations of UI Builder.
It seems that if we head down the Fluent route, the default proposition is to use the React components - which has many positive benefits - not least, no more UI Builder headaches!
The "What" Question:
I really want to retain both the look and feel or the Workspace UX and ideally to use Now Components as I create apps using Build Agent in the ServiceNow IDE.
There are four different questions, I guess:
1) Can I use "atomic" Now components that are available via NPM
- now-icon
2) Can I use "molecular" Now Components that are available via NPM?
- now-template-card
3) Can I use "molecular" Now Components that are only available in UIB
- now-form
4) Can I use more complex "business unit" components, which are currently only available in UIB
- datagrid
- gantt
- roadmap
It feel like if the re-use of Now Components is a sensible thing to try to do, then we'd need to see more/all of these components made available via NPM.
The "How" Question:
I'd be grateful for some advice on the technical possibilities and limitations here and a guide on how to implement this (maybe a prompt I could give to Build Agent?).
The "Why" Question:
I'm also keen to understand the engineering team's view on the strategic direction here - maybe I'm heading in completely the opposite direction from the direction of travel that you are taking the ServiceNow IDE and Build Agent.
Many thanks,
Andy
@patrickwilson
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-08-2025 10:53 AM
Hi @Andy Smith2
i'd utilize React (or another frontend framework) if you want to migrate to Fluent (which I support).
Personally I haven't tried Build Agent myself but if you're using fluent and clone the repository locally you could also use any AI Agent. You'd also need someone on your team that may connect a MCP Server so the Agent has all the knowledge like the Build Agent probably does. I'm very impressed with the results.
1) & 2) & 3)
be aware that Servicenow doesn't publish their npm components anymore. The new versions are not available anymore via NPM. see also this command you need to develop with so it will fetch the newer versions from the instance (we noticed when it behaved completely different locally vs deployed on instance)
https://developer.servicenow.com/dev.do#!/reference/next-experience/zurich/cli/cli
fetch-assets-from-instance | fa:
[Experimental] - This is an experimental feature and is not expected to work for all scenarios at this time.
You basically using deprecated components if you still pull them via npm. Unfortunately the documentation on that is not really clear. That is one of the reasons we migrate to React instead of using UI Builder custom components
All the components you listed, be it atomic or molecular, are available in all the frontend frameworks for free. I''d suggest to use those instead and if you want to have the same look and feel just style them via css.
4) You can still use those complex components and build a UI Builder Page with it. Let's say your main frontend is React. Then via iframe you can include a UI Builder Page. Since you style your React frontend in the same look there will be no visible break. This is a pattern I know some companies are using.
The last question only the engineering team can answer. I've the feeling that right now a lot of possibilities will be provided for low/no Code and pro Code alike. With more upcoming data by customers Servicenow will decide what strategy to actually pursue. That is why I'm pushing other devs like you to go the pro code way. For selfish reasons.
