NX Administration AI: The Short Version
NX administration AI means an assistant that answers CAD-admin questions from NX documentation and your own standards, prepares admin artifacts (a UDF, a material entry, a customer-defaults change, a ribbon customization, an NXOpen skeleton) for review, and executes nothing shared without a gate. inteliScience builds these assistants on NXOpen for DACH engineering teams; the admin stays the approver.
The Problem: Every Request to the CAD Admin Is a Ticket
A DACH machine builder’s CAD administration recently collected what its NX users expect from an “NX AI”. Eight of the requests were not design questions. They were the admin’s own backlog, restated by the people waiting on it: build us a parametric DIN 509 undercut, add this material, add this hole, put a button on the Home tab that runs our program, explain this error, set this preference, tell me which preference does what, help with NXOpen.
That list is the job description of a CAD administrator, and why one or two people are the bottleneck for a whole department: each item is small, each needs someone who knows where NX keeps the thing, and each lands as a ticket behind the last one.
Hiring a second admin rarely works: around 133,900 STEM vacancies stayed unfilled across Germany in March 2026 (Digital Skills and Jobs Platform), and NX admins with NXOpen skills are a thin slice of that pool.
The useful question is not “can an AI administer NX” (it cannot, and should not) but: per request, what can an assistant answer outright, what can it prepare for the admin to check, and what must stay a gated human action. Siemens covers the answer tier itself: Designcenter 2606 (June 2026) ships a Designcenter Copilot grounded in documentation and best practices, and Siemens reports over 500,000 monthly uses of its current AI features (Siemens Designcenter blog, 23 June 2026). The prepare tier and the gate are your own setup.
Eight Admin Requests, Sorted by What an Assistant May Do
The rule: read-only questions get answered with the source cited; anything that produces a file, a setting or code is prepared as an artifact the admin reviews; anything that changes a shared library, another user’s role or a site-level default runs only through a gate, or by the admin personally.
| Request | Where it lives in NX | Answer | Prepare | Execute (gated) |
|---|---|---|---|---|
| DIN 509 type E undercut by shaft diameter | UDF Wizard, UDF library or Reuse Library | Form E, wizard pages | UDF with named inputs, test checklist | Publish to shared library: admin |
| Add material xyz | Site/user MatML library (XML), set in Customer Defaults | Which file this NX loads | Entry in a copy, or export journal | Write site library: admin |
| Add hole xyz to the hole table | XML data tables in the modeling standards folder | Which table and columns | New row in a copy | Replace shared table: admin |
| Home-tab button in role “Standard” | Customize dialog, user.mtx, roles, MenuScript | How commands and roles are saved | Role or MenuScript files to test | Rollout to all users: admin |
| “Program reports error xyz” | Syslog, listing window, NXOpen exception | Causes, syslog lines quoted | Repro journal, ticket draft | Nothing |
| Set value x to y | Preferences vs. Customer Defaults (.dpv, three levels) | Which of the two, which level | Change request with lock state | Site/group level: admin, in the dialog |
| Which preference gives function xyz? | Customer Defaults dialog, NX help | Cited answer | Nothing | Nothing |
| NXOpen help | NXOpen reference, your libraries | API members, your examples | Skeleton, members checked | Run on production data: engineer |
The “answer” column is a knowledge job for a read-only assistant like our NX Knowledge Chatbot, which cites its source and cannot touch a model. The “prepare” column is where the admin’s hours go, and where the saving is. The “execute” column is short on purpose.
Four Admin Tasks Worked Through
Mechanics checked against NX help and Siemens Community material as of September 2026; anything that depends on your NX version or site layout, the assistant must read from your environment, not assert.
Task 1: A Parametric DIN 509 Type E Undercut Driven by Shaft Diameter
An assistant can prepare this; it cannot finish it. DIN 509 defines four undercut forms (E, F, G, H) at shaft shoulders; form E cuts into only the cylindrical surface, form F into both adjacent surfaces (Engineers Edge, DIN 509 relief grooves). Depth, width and radius come from a table keyed on the shaft diameter.
In NX the container is a User Defined Feature. The UDF Wizard (definition, features, expressions, references, summary) stores the result as a special part file inserted as one feature; libraries are configured under Tools, User Defined Feature, Configure Library, and newer releases also serve UDFs through the Reuse Library (NX help: configuring UDF libraries).
What the assistant prepares, and what the admin checks:
- The groove as a sketch-driven feature set with named expressions (
d1shaft diameter;t1,f,rgroove), so the wizard exposesd1as the only input. - The diameter-to-groove lookup. The wizard does no table lookups; that logic lives in expressions or a referenced lookup. Assistants get this subtly wrong most often, so review it first.
- The placement references (shoulder face, shaft axis) on the wizard’s references page.
- Test placements on three diameters across the DIN table, with t1, f and r read back and compared.
- Only then: publishing the part file to the shared library, by the admin, by hand.
One caveat: DIN 509 is a licensed standard. The assistant can cite its tables only if your licensed copy is in its corpus; groove dimensions recited from memory are wrong until checked.
Task 2: Materials and Hole Tables, Two Shared Library Edits
Both are edits to XML files that everyone’s NX reads, which is why they sit in the admin’s queue.
NX keeps custom materials in a site library and a user library, both MatML-schema XML files whose locations are set in Customer Defaults (Gateway, Material Mass: a “Site MatML Library” switch and a file name); the shipped physicalmateriallibrary.xml is the usual starting copy, and materials are maintained through Manage Materials and Manage Library Materials (Swoosh Technologies, site material library); NXOpen can also export a part’s material into a library file (NX Journaling, create library material).
For holes, the Hole command’s drill-size, screw-clearance and threaded-hole options come from XML standard data tables in the installation’s modeling standards folder; column names must be retained, the threaded-hole folder can be redirected by an environment variable, and the syslog shows which file NX actually loaded (Eng-Tips, custom threaded hole callouts). Your admin may have moved these to a network share years ago; an assistant that edits the local copy has changed nothing.
Our position: the assistant prepares both edits in a copy, with a diff and a note on which path this NX resolves; the admin applies the diff. Shared files are not something an agent touches unattended.
Task 3: A Ribbon Button in a Role That Runs a Program
The request was precise: role “Standard”, application Modeling, Home tab, a button that runs their program. The mechanics are documented: in the Customize dialog you pick New Button, drag a new user command onto the ribbon and edit its name, icon and action (the action type can be a journal file); such customizations land in the user’s user.mtx, and for an organisation-wide rollout NX help points to MenuScript (NX Journaling, start a journal from a custom button). Roles live on the Roles tab, are saved with Save Role, and are shared by copying the role file to another machine’s roles folder (NCmatic, NX roles).
So the assistant prepares the MenuScript files for the button, the role file that includes it, and a one-page test note (application, tab, what runs, what happens when the program is missing). It should ask first: does “program xyz” exist as a journal or an NXOpen DLL, and does it run under the caller’s permissions? A button that runs something is a small deployment, and deployments have owners.
What it must not do is copy the role into the site or group startup folder so every user gets it on next start. The admin does that once, on purpose, after a test on one machine.
Task 4: Customer Defaults, and “Which Preference Gives Me X”
“Set value x to y in the preferences” hides a question the assistant should ask back: preference or customer default? Preferences apply to the session or the part in front of you. Customer defaults set the initial values, open via File, Utilities, Customer Defaults, and exist on three levels stored as .dpv files, with a startup subfolder NX does not create for you and a lock state per default once the levels are configured (Swoosh Technologies, defaults levels).
| Level | Set by | File | Who may change it |
|---|---|---|---|
| Site | UGII_SITE_DIR, startup subfolder | *_site.dpv | CAD admin only, every user affected |
| Group | UGII_GROUP_DIR, startup subfolder | *_group.dpv | CAD admin, one department affected |
| User | UGII_LOCAL_USER_DEFAULTS (directory plus file name) | *_user.dpv | The user, unless locked above |
“Which preference gives me function X” is safe ground: a documentation question, answered from the NX help with the dialog path cited. That corpus moves twice a year: Siemens previewed the next release, Designcenter 2612, at its Early Access Program in Mason, Ohio, VIP weeks 14 to 25 September 2026 (Siemens EAP), so the help index needs a refresh per release. “Set x to y” gets a change request instead: default name, level, value, lock state, who is affected. A user-level change the user applies; a site-level change the admin applies in the dialog. We would advise against wiring any agent to write .dpv files directly; the dialog is the audit trail.
This runs as a POC. What’s missing for production: GDPR compliance, SSO/Entra, scaling, monitoring, operations, and a preview-and-confirm gate in front of every shared file. We close the gap from “runs on the admin’s machine” to “runs in the engineering department” with the NX Action Assistant: preview, confirm, undo, log.
Error Triage: “The Program Reports Error XY, What Do I Do?”
This is the request an assistant handles best, because everything it needs is text. NX writes a system log per session, recording startup, the environment variables and configuration files in use, then the session’s events; you open it via Help, Log File, it lands in the directory set by UGII_TMP_DIR, and UGII_KEEP_SYSTEM_LOG set to YES keeps it after exit (Swoosh Technologies, NX logging, Siemens Community, NX syslog location). Add the listing window output and the NXOpen exception text, and the assistant has what a support engineer would ask for.
The triage it proposes, in order: which configuration file this NX loaded, whether the failing program was built against this release, whether the part is a released Teamcenter revision, whether role and permissions match the machine that works, and whether the message is in your own known-issue list. That last one is why your ticket history belongs in the retrieval corpus. Users call this “training the AI on our tickets”; in practice it is retrieval over tickets plus syslog, not model training, and it is enough.
A small NXOpen journal is often the first thing the assistant prepares, so the ticket carries facts instead of screenshots. This one prints the environment this session resolves, its syslog path, and the work part’s expressions. It changes nothing.
# NX journal (Python): environment and expression inventory for an error-triage ticket.
# Read-only: writes to the listing window, changes nothing in the part.
import NXOpen
session = NXOpen.Session.GetSession()
lw = session.ListingWindow
lw.Open()
# Which directories does THIS NX resolve? (site/group config often differs per machine)
for var in ("UGII_BASE_DIR", "UGII_SITE_DIR", "UGII_GROUP_DIR", "UGII_TMP_DIR"):
lw.WriteLine(f"{var} = {session.GetEnvironmentVariableValue(var)}")
# The syslog that belongs to this session, for the ticket
lw.WriteLine(f"syslog = {session.LogFile.FileName}")
# Expressions in the work part: name, type and formula (no values are touched)
work_part = session.Parts.Work
for expr in work_part.Expressions:
lw.WriteLine(f"{expr.Name} [{expr.Type}] = {expr.RightHandSide}")GetEnvironmentVariableValue, LogFile and ListingWindow are members of NXOpen.Session; RightHandSide and Type are members of NXOpen.Expression (NX Open reference, Session class). That is the standard for an assistant writing NXOpen: every member checked against the reference, not remembered, whichever model sits behind it (hosted, or an open-weight model on your own hardware). How to get a model there reliably is our guide to AI code generation for NX Open; the API landscape is covered in Siemens NX API programming.
What the Assistant Must Never Do Unattended
Three actions stay behind a gate in every setup we build, however good the proposal. The doctrine has not changed: AI proposes, NXOpen executes, rules and a human validate.
| Action | Why it is gated | What the gate looks like |
|---|---|---|
| Edit site- or group-level customer defaults | One write changes start-up for every seat; a wrong lock state is not undone by the user | Change request, applied by the admin in the dialog, logged |
| Change a shared library (materials, hole tables, UDF or Reuse Library) | Every session reads it; one malformed XML row breaks a command site-wide | Diff on a copy, admin applies, old file kept |
| Deploy a ribbon customization or role other users load | Ships an executable path to people who did not ask for it | Test on one machine, admin copies to the startup roles folder |
The mechanism is the one our action assistants use in the model: preview, explicit confirm, undo mark, audit line. For admin work the “model” is a file or a setting, but the loop is identical, and it is what an NX MCP server built for production adds over a raw tool layer. In our experience the admins who adopt an assistant fastest are those who see, on day one, that it cannot write to their site directory.
Read-only is an architecture, not a policy setting. An assistant that “promises” not to write to the shared library still holds the path and the permission; one that cannot write has neither.
If you would rather hand over the routine work, our NX administration services look after customer defaults, templates, roles and the license server.
Frequently Asked Questions
What is NX administration AI, in one sentence?
An assistant that answers CAD-admin questions from NX documentation and your own standards with sources, prepares artifacts (UDFs, material entries, customer-defaults change requests, ribbon customizations, NXOpen skeletons) for review, and executes nothing touching shared files or other users’ settings without a human gate.
NX Knowledge Chatbot vs. Action Assistant for admin tasks: which one do we need?
For six of the eight requests the read-only NX Knowledge Chatbot is enough: it answers “which preference”, explains syslog errors and drafts artifacts as text. The Action Assistant earns its place when prepared changes should be applied through a preview-and-confirm gate, for example a user-level default or a per-user role. Start with the knowledge tier; add the act tier where the admin is still the one clicking.
How much does an NX administration AI setup cost?
Our fixed-scope entry points are listed on the service pages: a Knowledge Chatbot pilot with your core corpus indexed, and an Action Assistant proof of concept for one bounded workflow, each four to six weeks and creditable against a rollout. Admin use cases usually start with the knowledge pilot, because most requests are answer-and-prepare.
Can the assistant be “trained on our data”, meaning our defaults, libraries, tickets and NXOpen code?
In practice this is retrieval, not training: customer-defaults exports, library files, ticket history and NXOpen sources are indexed under your access rules and cited in answers. Fine-tuning on customer data is the exception, and we do not claim it unless a project calls for it. Retrieval also lets you update the corpus tomorrow without retraining.
Does the assistant replace NX admin training for our team?
No. It shortens the queue, but whoever approves a site-level default or a shared library still needs to understand it. We pair rollouts with focused Siemens NX training for that reason: the gate is only as good as the reviewer behind it.
Next Step
Send us your CAD admin’s last twenty tickets. We will sort them into answer, prepare and execute, and show the first two categories running on your own documentation and standards. Talk to our engineers about an NX admin assistant
Related Topics
- NX Action Assistant
- Evaluating AI assistants for engineering teams
- How Siemens NX AI chatbots pay off
References
- Siemens Designcenter blog, “Designcenter is for everyone, June 2026 release” (23 June 2026): https://blogs.sw.siemens.com/designcenter/designcenter-is-for-everyone-june-2026-release/ (retrieved 2026-09-24)
- Siemens, “Welcome to the September 2026 Early Access Program for Designcenter” (Designcenter 2612, VIP weeks 14 to 25 September 2026): https://resources.sw.siemens.com/en-US/presentation-welcome-to-designcenter-early-access-program/ (retrieved 2026-09-24)
- NX help (mirror), “Configuring UDF Libraries from NX”: http://www2.me.rochester.edu/courses/ME204/nx_help/en_US/tdocExt/content/g/udf_udf_manlibs_ug.xml (retrieved 2026-09-24)
- Swoosh Technologies, “Site Material Library in NX, getting started”: https://www.swooshtech.com/2020/10/08/site-material-library-in-nx-getting-started/ (retrieved 2026-09-24)
- NX Journaling, “Create library material”: https://nxjournaling.com/content/create-library-material (retrieved 2026-09-24)
- Eng-Tips, “Custom threaded hole callouts in NX 11”: https://www.eng-tips.com/threads/custom-threaded-hole-callouts-in-nx-11.464588/ (retrieved 2026-09-24)
- NX Journaling, “Start journal from custom button”: https://www.nxjournaling.com/content/start-journal-custom-button (retrieved 2026-09-24)
- NCmatic, “NX Roles, managing your custom interface layouts”: https://ncmatic.com/technical-tuesday/nx-roles/ (retrieved 2026-09-24)
- Swoosh Technologies, “How to define the defaults level of Customer Defaults”: https://www.swooshtech.com/2023/04/06/how-to-define-the-defaults-level-of-customer-defaults/ (retrieved 2026-09-24)
- Swoosh Technologies, “NX logging business”: https://www.swooshtech.com/2018/06/08/nx-logging-business/ (retrieved 2026-09-24)
- Siemens Community, “NX Syslog location”: https://community.sw.siemens.com/s/question/0D54O000061wvKCSAY/nx-syslog-location (retrieved 2026-09-24)
- NX Open C++ Reference Guide, NXOpen::Session and NXOpen::LogFile: https://www.ugapi.com/doc/NXOpen/a05085.html and https://www.ugapi.com/doc/NXOpen/a03979.html (retrieved 2026-09-24)
- Engineers Edge, “Machined tool relief grooves, DIN 509”: https://www.engineersedge.com/mechanical,045tolerances/machined_tool_relief_grooves_15414.htm (retrieved 2026-09-24)
- Digital Skills and Jobs Platform, “STEM skills shortage: Germany persists, over 130,000 vacancies remained vacant in March 2026”: https://digital-skills-jobs.europa.eu/en/latest/news/stem-skills-shortage-germany-persists-over-130000-vacancies-remained-vacant-march-2026 (retrieved 2026-09-24)