Now-SDK 4.8 silently drops and tombstones sys_ux_asset records

[BenKhz]

Question: How should sys_ux_lib_asset records be handled when converting an installed app to SDK source?

⚠️ This round-trip silently deletes previously existing application records. Converting an installed app to SDK source and redeploying removes sys_ux_lib_asset records that were part of the app, with no warning and no error — build and deploy both report success.

Context

We're evaluating the workflow of installing an existing (store) application on an instance, then converting it to SDK source and redeploying, and want to confirm it's lossless. The app's scope contains a number of sys_ux_lib_asset records (a module-federation UI bundle — multiple .js/.css assets under a shared library name).

We observe that after transform → build → deploy, the app's installed file count drops (in our case ~90 sys_ux_lib_asset records disappear). We'd like to understand whether this is expected and what the intended handling is.

Environment

• @servicenow/sdk: 4.8.1
• Node 26.x, macOS

Steps to reproduce

1. Install/have an app whose scope contains sys_ux_lib_asset records, where some records share the same name (common with module-federation builds that emit hashed + unhashed variants and leave copies across builds).
2. now-sdk download <dir> — confirms all records download (e.g. all N XML files present under <dir>/update/).
3. now-sdk transform (against the instance) — generates src/fluent/generated/.
4. Inspect src/fluent/generated/keys.ts, then now-sdk build and inspect the author_elective_update output.

What we observe

• Fewer records than input. keys.ts contains one sys_ux_lib_asset entry per unique name, not per record. Records that share a name collapse into one. Debug output shows the dedup at load time (Database contains N records for transformation, where N is the unique-name count plus related records).
• No source files generated. Every other record type in the app gets a generated source directory (ACLs, roles, scope privileges, script includes, …), but there's no generator/directory for sys_ux_lib_asset — the surviving records exist only as keys.ts identity stubs.
• Survivors become deletes. After an instance-connected transform, all the sys_ux_lib_asset entries in keys.ts are marked deleted: true. On build these become action="DELETE" author-elective updates, and deploy removes them from the instance. (An offline transform --from <dir> does not set deleted: true, so this appears to come from the instance-reconciliation step.)

Questions

1. Identity key: sys_ux_lib_asset appears to be keyed by name in keys.ts, but name is not unique on this table. Is this intended? Should it be keyed by sys_id? Records with duplicate names are silently dropped.
2. Source representation: Is sys_ux_lib_asset expected to be representable as Fluent source? If not, what's the recommended way to carry these assets through an SDK conversion without losing them?
3. deleted: true on reconciliation: Why does an instance transform mark existing, present-on-instance records as deleted: true when they simply have no source representation? This turns "can't represent" into "delete on deploy," which is the actual data loss.
4. Recommended workflow: For an app that includes module-federation / UI-library assets, what's the supported pattern — should these assets be managed outside the SDK deploy, excluded from transform, or is there a config to preserve them?

Side note

now-sdk transform --from <dir> appears to delete the consumed XML files from the input directory after processing. Is that expected? It's surprising for a directory of hand-curated metadata.

[bryce-godfrey]

Thanks for the report, we will investigate this

[BenKhz]

Appreciate the response Bryce! After spending some additional time with it, it appears that the uiBuild portion of the client build (intended to land in the sys_ux_* tables) works well. My armchair theory, is that those tables aren't necessarily intended for storing libs not associated with existing fluent code and the built XML is intended to be pruned and regenerated every roundtrip. But if a product already had existing records there, they disappear when trying to migrate to a fluent powered sdk pipeline.

Our solution was to add the table to the ignoreTableTransform and manually author the fluent code using the Record() escape hatch. One time process, but hopefully this approach might help others in the future.

P.S. Thanks again for your teams work on the sdk as a whole. (Any idea when the aiux-sdk will be made public?) :)

[sn-rickbull]

https://www.npmjs.com/package/@servicenow/aiux should be published now.
If you have now-sdk@4.10.x or newer you should see a new template option pop in when running now-sdk init.

[chasingtheflow]

Huzzah! 🙌🏼 Are there docs for AIUX somewhere? The readme giving away mich. --Billy Matthews719.439.5484On Aug 14, 2026, at 9:34 AM, sn-rickbull ***@***.***> wrote: ***@***.***/aiux should be published now. If you have ***@***.*** or newer you should see a new option pop in. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>