ServiceNow “Now SDK”, AI-assisted development and offline packaging into an installable Update Set XML.

People who know me know how enthusiastic I am about the Now Platform evolutions during the years.

I have always seen the platform as one of the most interesting enterprise ecosystems to work with: structured enough to govern complex processes, but flexible enough to let teams build real business solutions quickly.

And now that ServiceNow is increasingly embracing another trend I follow very closely, AI, I have been genuinely enjoying the opportunity to explore new ways of working with the platform.

That exploration brought me to what I believe may be one of the biggest ServiceNow game changers of the last few years: the Now SDK.

The SDK opens up a new world. It changes how we can think about development, source control, automation, local tooling, AI-assisted delivery and repeatable engineering practices around ServiceNow.

While exploring this space, we focused on a challenge that looks simple at first, but is actually very relevant in enterprise contexts:

Can we use AI and the ServiceNow Now SDK to build a complete scoped application without giving the AI direct access to the customer’s ServiceNow instance?

In our case, the answer had to respect very real constraints:

• no direct authentication to the customer’s ServiceNow instance
• no SDK install flow through now-sdk install
• no pre-existing scoped app on the target instance
• a final artifact that a ServiceNow admin can import, preview and commit
• the ability to develop, test and validate everything locally

The solution was to build a full offline workflow with the Now SDK.

We modeled the application locally using Fluent and the Now SDK: tables, roles, ACLs, workspace configuration, UX routes, navigation, Script Includes and application logic. Then we used now-sdk build to generate the local XML records for the application.

The key step was this: instead of stopping at the SDK ZIP, we created a packaging bridge that takes the local dist/app output and converts it into a real Retrieved Update Set XML, ready to be imported through:

System Update Sets > Retrieved Update Sets > Import Update Set from XML

The result is an installable ServiceNow package without the AI, the local code or the SDK ever authenticating to the target instance.

In our case, the update set:

• created the scoped app on the target instance
• installed the custom tables
• installed roles and ACLs
• installed the workspace configuration
• made the /now/.../home route available
• allowed validation directly on the platform through the standard preview and commit process

We also kept demo data separate from application metadata: the app is delivered as an update set, while seed data is generated as a separate XML data file that can be imported after the app commit. That separation keeps the package clean and makes the data load repeatable.

The most interesting part, to me, is not only technical. It is methodological.

There is still a lot of skepticism, often for good reasons, around letting AI work directly against customer instances. Credentials, sensitive data, auditability, governance and accountability are all real concerns.

This workflow creates a different boundary:

AI and SDK work locally. The customer keeps control of the ServiceNow instance. The final output is a standard, reviewable ServiceNow artifact that can be previewed and committed by an admin.

It does not remove governance. It makes governance easier to apply.

It does not replace platform validation. It prepares it better.

It does not ask for blind trust in AI. It produces something that can be reviewed.

I believe this can change how we build ServiceNow solutions: more automation, more speed, better engineering discipline, and still a clear boundary between AI-assisted development and control of the customer environment.

We also learned a few important details along the way:

• the ZIP generated by the Now SDK is not automatically an installable update set
• the local build output contains very useful XML records, but it needs the right wrapper
• workspace UX routes must be explicitly validated
• some records, such as sys_user_role_contains, can create duplicate-key warnings in repeated update set installs and need careful handling
• seed data should remain separate from the application package

We are in a moment where many organizations want to use AI to accelerate development, documentation, refactoring and delivery, but they are not yet ready to give AI tools direct access to customer instances. A native Now SDK capability to generate offline installable packages, for example update set XML or an equivalent governed artifact, would be extremely valuable.

It could become a secure bridge between AI-assisted development and enterprise governance:

• local development
• no customer credentials
• reviewable artifacts
• standard import
• preview and commit controlled by the platform

I believe integrating something like this natively into the Now SDK could unlock many real use cases for partners, customers and the developer community.