When importing users from external systems, you might have some User IDs that are longer than the 40-character limit in ServiceNow. It can be tempting to increase the size of the “User ID” [user_name] field to fit those longer values.
Trust me, don’t do it!
Not just because ServiceNow explicitly tell you not to do it.
Increasing the length of the “User ID” field may seem like a practical solution, but it causes weird, nightmare bugs that will haunt you forever.
How do I know? I worked for a client that had increased the size of the “User ID” to 80, and every now and then, there was a poltergeist that I had to investigate.
If you are not convinced yet, keep reading.
I’ll briefly explain why this happens and show you a few examples of random, weird behaviours.
Why does it happen?
The “Created by” [sys_created_by] and “Updated by” [sys_updated_by] fields, that are available on every table, track which user created or last updated a record. These fields don’t store a reference to the user record. Instead, they store a string with a snapshot of the “User ID” at the time the record was created or updated.
The length of these fields is limited to 40 characters. If your “User ID” is longer, it will be trimmed to fit.
Example:
“User ID”: ThisIsAVeryLongUserNameThatIsLongerThan40Characters
“Created by” / “Updated by”: ThisIsAVeryLongUserNameThatIsLongerThan4
Some out-of-the-box scripts compare “Created by” or “Updated by” with the logged-in user’s full “User ID”. This leads to confusing and unexpected behaviours when the trimmed value doesn’t match the full ID.
By the way, be careful about replacing the “User IDs” of active users, as it can be problematic too.
Examples
1 – Attachments to a record not yet created are not visible
This one drives people crazy. When your User ID is 40 characters or less, everything works as expected. You attach a file to an incident you are creating, and you can see it before submitting the record.
But if your “User ID” is longer than 40 characters?
You attach the file.
You get the confirmation that it was attached.
But where is it?!
To make it more confusing… Once you submit the incident, the attachment magically appears!
This snippet in the AttachmentSecurity Script Include is the one causing trouble:
// If parent table does not exist, or parent sys_id not found,
if (!parentRecord.isValid() || !parentRecord.get(current.table_sys_id)) {
// If this attachment was created by this user,
if (current.sys_created_by.equals(gs.getUserName())) {
// User can add attachments to: a new record they are creating, but haven't submitted yet.
// They need to be able to view attachments on the record they are creating.
return true;
}
return false;
}
Code language: JavaScript (javascript)The check compares your full “User ID” with the trimmed version stored in sys_created_by. If your “User ID” was cut off, the comparison fails, and you experience the weird behaviour (but only during the record creation!)
2 – Filter your apps in Creator Studio
For this one, you need the admin role and at least one app created.
Normally, if you filter by “Your apps”, the UI should show your app, and the counter should reflect it.
Not if your “User ID” is longer than 40 characters!
What’s wrong? The script behind the filter and the counter uses your full “User ID” to match with the sys_created_by field, just like in the previous example.
Let’s have a look at the code in the ApplicationService Script Include.
The filter:
case APPLICATION_FILTERS.OWNED:
// DEF0464717: admins cannot be collaborators, use alternate logic to find admin user apps
if (!gs.getUser().hasRole("admin")) {
const grJoin = grApps.addJoinQuery(
USER_COLLABORATION_TABLE,
"sys_scope",
"application"
);
grJoin.addCondition("user", userId);
grJoin.addCondition("descriptor", OWNER_DESCRIPTOR);
} else {
grApps.addQuery("sys_created_by", gs.getUserName());
}
Code language: JavaScript (javascript)The counter:
function getOwnedApplicationsCount(keyword) {
if (gs.getUser().hasRole("admin")) {
var ga = new GlideAggregate(REQUEST_APP_TABLE);
if (keyword)
ga.addQuery("sys_scope.name", "CONTAINS", keyword);
doCanReadCheck(ga);
const joinQuery = encodeJoinQuery({
table: REQUEST_APP_TABLE,
field: "sys_scope",
joinTable: "sys_app",
joinField: "sys_id",
});
ga.addEncodedQuery(joinQuery);
ga.addQuery("sys_created_by", gs.getUserName());
let qca = ga.addQuery("is_deleting", false);
qca.addOrCondition("is_deleting", null);
ga.addAggregate('COUNT');
ga.query();
var recordCount = 0;
if (ga.next()) {
recordCount = ga.getAggregate('COUNT');
return recordCount;
}
return recordCount;
Code language: JavaScript (javascript)At least you can still find them under “All apps”…
3 – Update your Knowledge feedback
You should be able to edit your own feedback if you have the right permissions, as checked by the write ACLs for kb_feedback records.
But you can’t when your User ID is longer than 40 characters
What is going on? I guess you can imagine at this point. 🙂
The ACL calls this function:
function canEditFeedback() {
if(new SNC.KnowledgeHelper().canContribute(current.article.getRefRecord()) ||
current.sys_created_by == gs.getUserName()) {
return true;
}
return false;
}
Code language: JavaScript (javascript)No feedback edition for you if your name is too long!
More examples
I just wanted to show you some real examples, not do a full analysis (I’m not being paid for that).
If you’d like to explore more scenarios, you can search your scripts for things like:
sys_created_by.equals(gs.getUserName())Code language: JavaScript (javascript)sys_created_by == gs.getUserName()Code language: JavaScript (javascript)addQuery("sys_created_by", gs.getUserName())Code language: JavaScript (javascript)You might be surprised at what you can find!
References
- ServiceNow Support: Why you should not increase the max length of the User ID field [sys_user.user_name] which is limited to 40 characters Out of the Box
- ServiceNow Support: Users With user_name Over 40 Characters Cannot Download Exported Excel Files
- ServiceNow Support: Unable to attach the attachments though user has roles
- ServiceNow Community: Why you shouldn’t exceed 40 characters on your UserIDs?
Tested in a PDI in Zurich.