Out of box priority changes - Need help

[srinivasrao]

Hi Team,

Can you help me understanding what would be the repercussions doing the below changes?

I am doing changes to priority matrix. My instance is a brand new one, instead of 3 * 3 matrix, added one more level 4 * 4.

We have hardly have any incident data. So we don't bother to change the existing data.

But I have some questions:
1. Is it a good practice change those Impact and Urgency Values?
Below are the changes done:
Impact: (High,Medium,Low names are changed to Moderate, Limited, No Impact)

Added a new level Wide Spread (0) on the topUrgency:
High - Moderate (1)
Medium - Limited (2)
Low - No Impact (3)

Urgency: 

Added Urgent - (0) at the top. Rest are all the same

High -(1)
Medium - (2)
Low - (3)

2. Will the upgrade remove all the changes?
3. If so, What are the precautions to be taken to keep up the changes and during upgrade?
4. What about the dashboard and reports data , will there be any conflicts and impact on the future workflow that is going to be created?
5. Our instance has hardly have any customisations , almost a new instance.

Regards,

VASS

[OlaN · Accepted solution]

Hi,

The top thing to consider when configuring these choices, is where they are inserted.

You have the option to choose if they should be added to the task table or the incident table.

Adding them to the task table will make them available for all other tables that extend task, and is probably something you will want to avoid, so make sure you add these extra options to the Incident table.

The upgrade will not remove these changes, but they will most likely be flagged as changed, and you will have to decide you you want to proceed with the upgrade (keep the change you've made, revert the change back to OOB, or where applicable, merge your changes with the changes made by ServiceNow into a updated customization).

Adding additional options like this is considered a low priority change, it will most probably not conflict with future updates to the business logic added by ServiceNow. But as with all changes from the base system, some responsibility is expected, as updates will continue to happen every 6 months.

[Moin Kazi · Accepted solution]

Hi @srinivasrao ,

1. Is it a good practice to change those Impact and Urgency Values?

Changing the naming conventions and values for Impact and Urgency can be a good practice if it aligns with your organization's terminology and better reflects your operational needs. However, consider the following:

• Consistency: Ensure that the new definitions are consistently used throughout your organization.
• Training: Provide training to relevant stakeholders to familiarize them with the new terms and levels.
• Reporting: Ensure that any reporting or dashboards reflect these changes so users can interpret data correctly.

2. Will the upgrade remove all the changes?

In general, customizations made directly to standard ServiceNow tables, such as changes to the priority matrix, can be overridden during an upgrade. However, since you are using a brand new instance with minimal customizations, the risk is lower, but it is still present. ServiceNow upgrades can potentially revert custom labels or values unless they are properly documented or implemented in a way that preserves them.

3. What precautions should be taken to maintain the changes during an upgrade?

To minimize the risk of losing changes during an upgrade, consider the following precautions:

• Documentation: Clearly document all changes made to the Impact and Urgency values, including the rationale behind the changes.
• Custom Fields: Instead of modifying existing fields directly, consider creating custom fields that mirror the desired functionality. This allows for flexibility during upgrades.
• Use of Update Sets: Capture changes in an update set. This way, you can apply the changes back after an upgrade if needed.
• Testing: After an upgrade, thoroughly test to ensure that your changes are still in place and functioning as intended.

4. What about dashboard and report data? Will there be any conflicts and impacts on future workflows?

• Dashboards and Reports: If your dashboards and reports rely on the old values, changing them could lead to inconsistencies or data mismatches. After the changes, ensure that all reports and dashboards are updated to reflect the new naming conventions and values.
• Future Workflows: Workflows that rely on the previous definitions might need to be reviewed and potentially updated to accommodate the new values. Ensure to test workflows post-change to avoid any disruptions.

5. Our instance has hardly any customizations; it is almost a new instance.

Given that your instance is mostly uncustomized:

• Agility: This is a good time to implement changes since you are still in the early stages of configuration. It allows you to design your processes without worrying about legacy data or configurations.
• Minimal Risk: The impact on existing workflows and data is minimal, but proceed with caution and test thoroughly.
• Feedback Loop: Engage with users to gather feedback on the new changes, especially once implemented, to ensure they meet organizational needs effectively.

If this resolves your issue, kindly mark it as Correct If you find my response  helpful, please mark it as Helpful based on its impact.

Best regards,
Moin

[Aniket Chavan · Accepted solution]

Hello @srinivasrao ,

Here are some quick pointers on your priority matrix changes:

1. Changing Impact and Urgency Values
- Renaming and adding levels is fine if it suits your needs. Just ensure the new terms are clear for users.

2. Upgrades and Changes
- Upgrades won’t automatically remove your changes, but you’ll need to review them as they might be flagged. You can then choose to keep, revert, or merge these changes.

3. Precautions for Upgrades
- Document changes and test upgrades in a sub-production instance to catch any issues early.

4. Impact on Dashboards/Reports
- Custom values could affect reports or workflows if they reference old terms, so update any impacted elements.

5. New Instance
- Since your instance is new, it’s a good time to set these changes as needed with minimal impact on existing data.

Please Mark ✅Correct if this solves your query and also mark 👍Helpful if you find my response worthy based on the impact.

Regards,
Aniket

[OlaN · Accepted solution]

Hi,

The top thing to consider when configuring these choices, is where they are inserted.

You have the option to choose if they should be added to the task table or the incident table.

Adding them to the task table will make them available for all other tables that extend task, and is probably something you will want to avoid, so make sure you add these extra options to the Incident table.

The upgrade will not remove these changes, but they will most likely be flagged as changed, and you will have to decide you you want to proceed with the upgrade (keep the change you've made, revert the change back to OOB, or where applicable, merge your changes with the changes made by ServiceNow into a updated customization).

Adding additional options like this is considered a low priority change, it will most probably not conflict with future updates to the business logic added by ServiceNow. But as with all changes from the base system, some responsibility is expected, as updates will continue to happen every 6 months.

[Moin Kazi · Accepted solution]

Hi @srinivasrao ,

1. Is it a good practice to change those Impact and Urgency Values?

Changing the naming conventions and values for Impact and Urgency can be a good practice if it aligns with your organization's terminology and better reflects your operational needs. However, consider the following:

• Consistency: Ensure that the new definitions are consistently used throughout your organization.
• Training: Provide training to relevant stakeholders to familiarize them with the new terms and levels.
• Reporting: Ensure that any reporting or dashboards reflect these changes so users can interpret data correctly.

2. Will the upgrade remove all the changes?

In general, customizations made directly to standard ServiceNow tables, such as changes to the priority matrix, can be overridden during an upgrade. However, since you are using a brand new instance with minimal customizations, the risk is lower, but it is still present. ServiceNow upgrades can potentially revert custom labels or values unless they are properly documented or implemented in a way that preserves them.

3. What precautions should be taken to maintain the changes during an upgrade?

To minimize the risk of losing changes during an upgrade, consider the following precautions:

• Documentation: Clearly document all changes made to the Impact and Urgency values, including the rationale behind the changes.
• Custom Fields: Instead of modifying existing fields directly, consider creating custom fields that mirror the desired functionality. This allows for flexibility during upgrades.
• Use of Update Sets: Capture changes in an update set. This way, you can apply the changes back after an upgrade if needed.
• Testing: After an upgrade, thoroughly test to ensure that your changes are still in place and functioning as intended.

4. What about dashboard and report data? Will there be any conflicts and impacts on future workflows?

• Dashboards and Reports: If your dashboards and reports rely on the old values, changing them could lead to inconsistencies or data mismatches. After the changes, ensure that all reports and dashboards are updated to reflect the new naming conventions and values.
• Future Workflows: Workflows that rely on the previous definitions might need to be reviewed and potentially updated to accommodate the new values. Ensure to test workflows post-change to avoid any disruptions.

5. Our instance has hardly any customizations; it is almost a new instance.

Given that your instance is mostly uncustomized:

• Agility: This is a good time to implement changes since you are still in the early stages of configuration. It allows you to design your processes without worrying about legacy data or configurations.
• Minimal Risk: The impact on existing workflows and data is minimal, but proceed with caution and test thoroughly.
• Feedback Loop: Engage with users to gather feedback on the new changes, especially once implemented, to ensure they meet organizational needs effectively.

If this resolves your issue, kindly mark it as Correct If you find my response  helpful, please mark it as Helpful based on its impact.

Best regards,
Moin

[Aniket Chavan · Accepted solution]

Hello @srinivasrao ,

Here are some quick pointers on your priority matrix changes:

1. Changing Impact and Urgency Values
- Renaming and adding levels is fine if it suits your needs. Just ensure the new terms are clear for users.

2. Upgrades and Changes
- Upgrades won’t automatically remove your changes, but you’ll need to review them as they might be flagged. You can then choose to keep, revert, or merge these changes.

3. Precautions for Upgrades
- Document changes and test upgrades in a sub-production instance to catch any issues early.

4. Impact on Dashboards/Reports
- Custom values could affect reports or workflows if they reference old terms, so update any impacted elements.

5. New Instance
- Since your instance is new, it’s a good time to set these changes as needed with minimal impact on existing data.

Please Mark ✅Correct if this solves your query and also mark 👍Helpful if you find my response worthy based on the impact.

Regards,
Aniket

[srinivasrao]

Team,

Thank for all your replies.

I have tried in a PDI adding the new Impact and urgency values in the incident form.

Now the task table shows the below values. It kept the old Impact and urgency values, added new values that I have added in Incident form.  Circled in Red are old values.

So when next upgrade happens it will remove the new values, as per your comments above. So if add those values everything would be alright?  Or will there be any other repercussions?

Please guide me.

Regards,
VASS