Default State Issue in Travel Request Table (Extended from Task)

[akashmundli]

Hello ServiceNow Community,

I have a custom table Travel Request that extends the Task table. I want the State field (state) to default to "Requested" when a new record is created.

However, multiple states (e.g., "Open" and "Requested") have the same value (1), and the system is defaulting to "Open" instead of "Requested."

What is the best way to ensure that the default state is always "Requested" when creating a new Travel Request?

I have tried setting the Default Value in the Dictionary, but since multiple choices have the same value (1), it picks "Open" instead of "Requested."

[Dr Atul G- LNG · Accepted solution]

Try using a dictionary override instead of in the dictionary, as your table extends from the Task table, so it is taking the default Task values instead of your table's values.

[Dr Atul G- LNG · Accepted solution]

Try using a dictionary override instead of in the dictionary, as your table extends from the Task table, so it is taking the default Task values instead of your table's values.

[Shivalika · Accepted solution]

Hello @akashmundli 

Best option id dictionary override

Other option is updating the existing value 

Other option is creating a custom choice values. 

Kindly mark my answer as helpful and accept solution if it helped you in anyway. This will help me be recognized for the efforts and also move this questions from unsolved to solved bucket. 

Regards,

Shivalika 

My LinkedIn - https://www.linkedin.com/in/shivalika-gupta-540346194

My youtube - https://youtube.com/playlist?list=PLsHuNzTdkE5Cn4PyS7HdV0Vg8JsfdgQlA&si=0WynLcOwNeEISQCY

[storywords0]

This is a common headache when extending the Task table, primarily because the system maps defaults to the first choice it finds with that integer value in the database.

As you’ve discovered, setting the dictionary default when multiple choices share the same value (1) leads to unpredictable behavior. Here are the two best ways to handle this, ranked by best practice:

1. The Best Practice Fix (Recommended): The cleanest way to resolve this is to assign a unique integer value to your 'Requested' state. ServiceNow best practice dictates that each state should have its own unique backend value (e.g., Open = 1, Requested = 10, Work in Progress = 11). If you update the 'Requested' value to a unique number in the 'Choices' list, you can then set that unique number as the default value in the dictionary without any scripts.

2. The 'Quick Fix' (Before Insert Business Rule): If you cannot change the underlying choice value (e.g., due to strict documentation or cross-scope dependencies), use a 'Before' Business Rule on the Travel Request table:

When: Before Insert

Condition: state is empty

Script:

JavaScript

(function executeRule(current, previous) {
// Set the state specifically for this table
current.state = '1'; // Ensure this matches your requested state's value
})(current, previous);
Recommendation: I strongly suggest going with Option 1. Avoiding overlapping integer values for states prevents significant issues with reporting, SLA calculations, and list filters down the road. Changing the value once now will save you a lot of troubleshooting time later!