Enivornment, Used For and Service Instances

[Tone1]

Hi everyone,

I’m currently refining our CSDM 5 implementation and have a conceptual question regarding Service Instances (cmdb_ci_service_auto).

In the Service Instance Wizard, we can only select Production, Test, or Development for the Environment. However, the record itself also has the Used for (used_for) attribute with more granular OOTB choices like QA, Training, and Staging.

I need to create a Service Instance that is technically hosted within our production infrastructure, but its sole purpose is for Training. I’ve read in older posts that used_for is considered legacy and we should focus on the environment attribute.

Could someone clarify if used_for should be completely avoided in CSDM 5? If so, is the best practice to simply add custom dictionary choices (like "Training" or "Staging") to the environment field so they appear in the Service Builder, and how do you generally handle such a "Production-Training" instance in your data model without breaking governance?

Thanks in advance for your insights!

[fknell]

HI @Tone1,

The used_for field is already declared to be deprecated and shouldn't be used anymore. The environment field is the replacement, this explains also why you find it in the Service Instance Wizard.

It was mentioned in the CSDM training, but I try to find you an official statement.

Edit: It's in the slides, that come with the class.

Hope this helps!

[Tanushree Maiti]

You should avoid depending on the used_for field when modeling in CSDM 5.

It is effectively a legacy attribute and is no longer part of the recommended data model.

Instead, environment field should be treated as the primary and authoritative source, even if it appears less granular.

Although used_for is still available out-of-the-box (OOTB), it is generally:

• Not aligned with CSDM best practices
• Not recommended for new implementations
• Often excluded from reporting and dashboards

Key guidance

• Avoid using used_for: This field is considered legacy and may be deprecated in the future. It can also introduce inconsistencies, as it does not synchronize with the environment field out-of-the-box.
• Use the environment field: This is the preferred attribute for maintaining consistency and aligning with recommended practices in ServiceNow.

If the standard environment options (Production, Test, Development) are too restrictive—for example, if you need to represent a “Training” use case: 

the recommended approach is to extend environment field by adding “Training” as an additional choice, rather than reverting to the legacy used_for field.

[Mathew Hillyard]

Hi @Tone1 

There was a thread on here about environment where someone from ServiceNow advised us to use the Environment (choice) field. The Used for field is deprecated, and I understand the Environment table (which is not referenced by any field on the Service Instance anyway) is also either deprecated or planned for future deprecation.

This is not uncommon - Many ServiceNow products contain tables with fields that seem to have been intended for a particular purpose but have fallen by the wayside.

Just add additional choices to the Environment field to suit your use case. I'd avoid naming environments "Production-Training" - give it with the most appropriate name for its purpose (Dev, QA, Test, Sandbox, Staging etc.)

I hope this helps!

Mat