上QQ阅读APP看书，第一时间看更新

Creating Task fields

One thing that's important to understand about Tasks in ServiceNow, is that all task records (whether they're changes, problems, incidents, requests, request items, catalog tasks, or tasks in any other table that extends the base system task table) are technically all stored in a single database table. Although in ServiceNow, you see them as separate tables, that isn't actually the case. This is due to the flattening of the task table.

Each task-extending table has a field called Task type [sys_class_name], which defines what type of task it is (problem, change, incident, etc.). ServiceNow groups records with the same Task type, and treats them as though they're all in separate tables, but in the physical database on ServiceNow's servers, they're technically all in one big table.

This fact has far-reaching impacts on the way that the task table should be handled, some less obvious than others. For example, say you want to create a new field on the Incident form: Assigned developer [u_assigned_developer]. It's absolutely fine to put this field on the Incident table, and the Dictionary [sys_dictionary] will keep track of things for you; things such as where this field actually resides within the task table structure. However, what if you want to add the Assigned developer field to the Change table too, in case you have a change that requires a development effort? And while you're at it, perhaps you'd like to add it to the Problem and Requested Item tables. Well, in that case, it may make more sense to add the field to the base task table. This way, you don't need to have multiple copies of what is essentially the exact same field in the same database table (even though you wouldn't see it as being in the same table, since ServiceNow displays each task-extending table as a separate one!)

Here are some things to consider when it comes to the task table:

Try not to create new fields from the Form Designer. Instead, navigate to the Table Dictionary record for the table you'd like to create a field on, and create it from the related list of fields. This is because creating fields in the form designer often creates them on the base task table when you don't intend to, and doesn't give you much control over the name, type, default value, and so on.
Think very carefully before creating new fields on either the base task table, or any table that extends it. Think both about whether that field is necessary (could an existing, possibly unused field work?) and if so, about where it should be created (on the base table, or the extended table?).
When creating a new table where work might be done or tracked, carefully consider extending the task table. If you need features like workflow, an activity log and work notes, or assignment, you might be better off creating a table that extends task, rather than standing on its own.
Be extremely judicious about modifying the base task table. Any time you can avoid it, it's almost always best to create a Dictionary Override on the extended table, rather than modifying an existing base task table field.