Was thinking about how does this with "extends table" works. That thing you can choose when you create your own table. How does it work, what are the pros, cons and is there some magic in the end that makes it all happen?
I did some research and this is what I found out and what I would like to share.
Can I extend from every table?
First thing that I noticed was that when I clicked on the field "extends table", the list wasn't showing every table. Well, since this is a reference field, let us see if we can get some info on how the selecting is taking place. So I went into the configure dictionary on the field and this is what I got.
As you can see there is a condition "extensive IS true". I'm guessing not all the tables has this as default.
So I opened up a table that wasn't showing up in the list and the lucky winner was the User table(sys_user). There it was, under the section "Controls" you have a choice of "Extensive" and making it true will make the table show up on the list. There might be some tables where this isn't possible, but I think most of them will have this option.
Can I extend from a table that is extended from another table?
Yes you can. I wouldn't recommend it since it can get hard to keep track how its all connected and since the a lot of stuff (UI policies, Business rules etc.) can come down from the table you extended from, this can get messy. So even if it is doable, I don't see any reason why you should build something like this, rather rethink how to do what you are doing.
What do I get from extending?
Well, first you get all of the fields that exists in the table you extended from. And this is pretty much the obvious reason why you are extending. Why redo all the work when you just can reuse something that's already there. You also get one field that is named "sys_class_name". This field might have different labels, but the thought behind seems to be the same. For example if you extend from task table, this field label is "Task type". If you extend from cmdb_ci this field ls labeled "Class" which seems to be the normal label. Don't know if there is any more versions of the label besides these two. I'm going to tell you more about this sys_class_name a bit further down.
But I want a different default value on a field that I get from the extended table!
Don't worry, this is what dictionary overrides is for 😃 Right click on the field, go to the configure dictionary and then you got a related list called "dictionary overrides". From you you can click new and have a couple of fun stuff to do and changing the default value is one if them.
Just remember that the dropdown "table" show all the tables that has extended from the table, so make sure it's the correct one before changing and submitting.
So, the final question. How does it work, where are the records being saved?
Well, when you create a table that extends from another table, you can say that they get a parent/child relationship. Let's say that I have created a table "how does it work" and it extends from the table task. Now, on my own table I also created a field labeled "My own field". If I now look at a new record in my table, I get all the fields from task and my own little field "my own field". But if you look in the database it looks a bit different. In there, my table "how does it work" only has 2 fields. One named sys_id and one named "u_my_own_field". So in the database my table only has the field specific for my table and a sys_id to be able to match it to the correct record. This because all the records are saved in the "extended table". In this case task table. And here is where to sys_class_name field comes in place. I here have created a record through my own table. and looking at the task.list, it looks like this:
As you can see, it have automagically set the task type to "how does it work". Now ServiceNow knows that this record belongs to the table "how does it work" and in the background it will put these two tables together, making us believe there is only one. And that is also the reason our own table also has a sys_id field. So it can connect its records the the records on the task table. It is also so clever, so even if you go to task.list and see all the records. When you click on the record and get the form ui, it will show you in the correct form and not the "task" form.
This also gives the option to switch which table your record extends to since you can change the task type to any other table that extends from task. I wouldn't recommend it since you might break a lot of stuff. I'm just thinking that for example if you take a incident and change its task type to Change Request, some workflow won't start, since they are connecting when the record is created, not updated. But in a controlled area, this might be useful.
If you want to see more graphical how the fields are set up between the two tables, you can take a look at the schema map. Here you can see that only my own field is in the table and the rest is in the task.
Here you can also see my test to extend a table from a table that already was extended from task. You can see my own table that extends from task has 1 own field/column named "A new column" and the rest is from task. And my other "How does it work 2" doesn't have any own at all.
Can I see the extended fields in a list view?
What you might have noticed that in the task.list you can't show the fields that exists in the extended tables. For example you can't see the column "a new column" in the list view of task like this:
Ohh wait, it looks like you can 😃
This is only a property that you need to set, and this might help you a lot if you want to have users to look at a task list to gather all you incident, change etc. in one place. But you haven't done it since you can't show the specific fields for incident, change etc.
If you go to system properties->UI Properties and a bit down you find this:
If you set it to true, you can "dot walk" in the list layout as well.
Well, hope this have given you some insight on how extend table work and how to take advantage of it.
6 Comments
