How the ServiceNow IDE and Fluent may change the future of servicenow development

[ChrisF323949498]

I previously tasked myself with using the IDE more, looking into Fluent, and ultimately getting reactJS working in servicenow. Then I put that into a few articles to hopefully help others having a starting point – you can find those here.

I did that because I’ve always found the best way to truly learn and understand is by doing, and so I would recommend trying that too before reading on.

As I worked through playing around with the ServiceNow IDE and Fluent, the experience gave me a deeper understanding and helped establish my thoughts on how this may change things and speed up development, which is what I want to cover here.

• So how is this going to speed up delivery for us?
• How is this going to boost value and velocity?

From Forms to Fluent

 Traditionally servicenow development has relied on graphic interfaces, form builders, script include coding windows etc to define and manage the platform ‘objects’ like Tables, Business rules etc.

Whilst these have been intuitive, they perhaps fell a little short on scalability, productivity and presented a bit of a ‘blocker’ for other developers whom may typically work from VSCode or an IDE almost exclusively.

Fluent changes this. Fluent is a ‘Domain specific language’(DSL) based on TypeScript, and it expresses the servicenow metadata in readable maintainable code which can be modified from the IDE.

A business rule goes from a user interface with a script area (and an XML payload behind it), to an object such as this:

BusinessRule({
    $id: Now.ID['br0'],
    action: ['update'],
    table: 'x_snc_example_to_do',
    script: showStateUpdate,
    name: 'LogStateChange',
    order: 100,
    when: 'after',
    active: true,
})

This gives us numerous few advantages such as:

1. Integration into modern IDEs – Such as VSCode which is what servicenow have already embedded for us (Thank you!!!)
2. Artefacts become code.
   This means other software developers in your org can likely assist with development efforts, as the bar in some ways has been lowered – They don’t need to know that in order to write a script include they must navigate to table…err… what was it again? Sys_ something?
3. Improved readability and diffing compared to XML update sets.
   
   

And more.

However, more significantly, it opens the possibility for AI to better understand and learn from our code, helping us to produce artefacts via code, which we already see AI doing today with tools such as Copilot etc.

This means we can leverage AI far more, to help produce these artefacts for us (with our oversight of course).

So navigating to the script include table, clicking the menu item, waiting for the form to load etc starts to become a legacy approach and by moving away from this, we allow other developers and AI Agents to assist us.

That first part was important: “other developers” – This means other employees in your organisation, without specific servicenow knowledge can assist us more effectively too.

The IDE – A natural habit for most developers

With the ServiceNow IDE, built on VS Code, we move into a more familiar area for the vast majority of developers too (not just those specific to servicenow).

With its support of:

1. Workspaces
2. Realtime synchronization to the platform
3. IntelliSense
4. Full source control to github etc. (Sure we had this before to some extent, but now we also have code devs are used to seeing too, not just XML).

These capabilities offer so many advantages, but, let’s just pretend that it only reduced the time we spent wondering things like ‘What methods exists on GlideSystem again?’ That alone is going to boost productivity…but it does far more than that.

The combination of AI + Fluent + IDE

This combination is the real game changer here, ‘Better together’, and with ServiceNow AI technology, we’ll move more towards ‘describing what we need’ and unlocking numerous benefits including

1. Rapid prototyping: Even if you are reluctant to fully trust AI, for prototypes (where code won’t go into production without review), this becomes less of a concern.
   Getting applications built and into the hands of your stakeholders sooner to see, test, tweak their requirements is so important in producing a valuable end product and so this will increase business value significantly.
   
   
2. Error reduction: IntelliSense alone will help, but add in the various AI tooling and you’ll be outputting effective bug free code more rapidly. UAT will likely pass faster, meaning your business customers can start using your app sooner.
   
   
3. Knowledge democratisation: Less time spent having to know where script includes reside, means your broader development teams can assist too.

In summary, although Fluent and the IDE appear to just be extra tools, they actually shift the way and the speed at which we build things.
Taking the metadata and turning it into code, then integrating AI on top of that empowers us to build faster and collaborate more effectively, both with our human team members and our AI assistants.

Ok cool, so, where do we go from here?

I would encourage everyone to take a look at the IDE and Fluent first, get some hands on experience and that’s what I covered previously in parts 1v-4 here – Gives you some steps, and some code to use – We pull a NPM package in, which in itself is pretty powerful!

Then there are the official servicenow fluent docs here.

Once you compile your build and see the artefacts, and benefit from the help the IDE along the way, and maybe even push your code to GitHub (and review the outputted artefacts) I think that’ll help towards building excitement for this shift in servicenow development!

This is just my 2cents.

What are your thoughts?

1. How do you think this will change our approach to deployment and CI/CD?
2. What about being able to pass our code through other tooling to review security issues, etc?
3. How about the power of being able to import NPM modules, etc?