How do you have different 'state' fields for different tables extended from the task table?

[geek1]

Let's say you want to add one additional option for the change request's state field. This field should only show up on Change request, none of the other tables that share the same State field. How do you do this?

I'm sorry if this is so trivial, I've never been asked to create have this field unique across applications.

[david_legrand]

Hi,

In fact ServiceNow do that very simply.

If you don't have any choice for the specific table, the system will try to look for the parent table choices.

If you have at least one active choice for the specific table, ServiceNow will use only this one.

To understand it, I advise you to:

1) Go on an incident / change request / ...

2) make a right click on the state field

3) choose "Show Choice List" (you should have a huge list)

4) Group by table

and you'll see tables with choices and table without (change task in OOB shouldn't have any choices for the state if I remember well)

If you speak about the attributes, labels...

1) Go on an incident / change request / ...

2) make a right click on the state field

3) Choose "personnalize dictionnary"

4) Go to the bottom in the "Dictionnary override" list and create new

Regards,

ps:If it's not precise enough, feel free to ask again, no question is trivial just the answer (mine at least) could be stupid

[Aaron40]

Hi Geek,

In connection with what David is saying, if the extended table doesn't have a custom field value for that specific field (like Priority, Type, State, etc.), it will use the base table (Task) and grab all of the options.

If you decide to add to this list, ServiceNow will automatically create local copies of the original options from the Task table specifically for your specific table. This is to say, if you wanted a Priority 6 option for Change Request, go into a Change Request and right-click the field and click SHOW OPTIONS. OOB you won't find any options specific to change request (like David mentioned). However, as soon as you add an option, it'll recreate all the other options from Task (which you can later remove just from the table you're working on.

[anuj2]

Hi ,

You can do one thing navigate to Dictionary and select task table state field.

Here you can add up any new state value under Choices and select the table with which you want to bind that state value.

For change request you can add the values under task table, as incident has it's state value specifically mapped with the incident table.

Or as an alternative you can create new state values under task table and map them with change_request table , after that go to change form personalize state field and select table as Change(change_request).

Hope that will fulfill the purpose.

[HugoFirst]

I want to add one small bit of advice about adding new custom options for the state column in any table extended from task.

The advice stems from the fact that each option consists of a value and a label.   For example, the state with a value of 1 has a label of Open.

Study the existing values for the task table ( and any table which may be a parent to the table receiving the new option ).

If your new option closely matched the label of an existing value, consider changing the label of existing option rather then adding a new value.

If there is NO existing option that closely matches your new option, then add one, BUT DO NOT ASSIGN IT A VALUE WHICH IS USED FOR AN EXISTING BUT DIFFERENT OPTION IN THE PARENT TABLE.

If the new option indicates an open, active record, make the value a negative number.

If the new option indicates a closed/inactive state, give it a high number, say 100.   And be sure to check the     business rules for Close Ticket.   Some of them have a condition that the state == 3 or == 4.       You need to add your new value to that condition ( only if the new value indicates a closed ticket )

EDIT:     My main motivation for this advice is to simplify reporting, and filtering of lists and gauges.   Sometimes people like to see all their open tasks, or all their closed tasks.   Having the state values consistent across the tables makes that possible.