Extending User is Bad

Author

Jace Benson
August 12, 2021

A few weeks ago, extending User sys_user] came up and I had always thought, well ServiceNow did it for Customer Service Management, so it must be fine. This day however Pheedbaq explained why this is a problem and why we shouldn't do it.

Here's my understanding.

Let's go with spatial bodies. For this example, we'll extend sys_user to user_martian and user_plutonian.

You can create a user on user_martian, they will never have a class of sys_user.

If you decide that later you want user_plutonian extension, users who were made on user_martian can never also exist on user_plutonian.

Let's use an example. Let's say John is a new Citizen on Mars and moved there yesterday. You guys have a process that creates a user_martian record for him. Then you decided he's going to move to Pluto and work from the branch there.

You'd need a second record because his class cannot be both user_plutonian and user_martian.

Pheedbaq's message that spurred this

If you have: sys_user 

contract_user extends sys_user 

subsidiary_user extends sys_user 

Then you create Bob who is a contract_user 

Bob's class will never be sys_user.

Bob can never be a subsidiary_user.

To make Bob both a contract_user and a subsidiary_user, Bob must have 2 accounts.

The User table should never be extended. We have had apps and guidance in the past that say, "extend sys_user" and those are wrong. For ServiceNow-made apps which extend sys_user, those teams have already or are in the process of unwinding that, so they don't break future customers. The documentation should hopefully already be cleaned up, but there may be some lingering bad advice out there.

I didn't mean to interrupt the LCHH; I thought posting here would be non-disruptive. Hope it wasn't a bother.

-- Pheedbaq

Reply

or to participate.