Application Service class: "Used for" vs. "Environment" field?

[Jacques Clement]

Hi -

Does anyone know why on Application Service (and other Service tables), we have both Used for and Environment to model the environment. They both seem to represent the same thing - or am I missing something?

Thanks

[scott_lemm · Accepted solution]

A bit of history here:

1. used_for is a legacy attribute in ServiceNow CMDB and not present on all CMDB classes

2. The used_for label is quite possibly the worst label in all of ServiceNow CMDB. The industry refers to this data as "Environment". Due to the poor name, many customers didn't know this attribute existed. The #1 custom created attribute in ServiceNow CMDB is "Environment". 

3. The oob Environment attribute is our effort to right a wrong by providing an object that is available on all CMDB classes and labeled appropriately as "Environment". 

Eventually, after customers have migrated from used_for to environment, we will deprecate the legacy used_for object. We recommend you utilize "Environment" in your operations.

Hope this helps in understanding why both objects exist. 

[Community Alums]

Thanks Scott. But what is the best practice for actually populating the Environment attribute? Per the CSDM White Paper, "application services represent instances of a business application or system in different
types of development environments, like development, test, or production". So should the Environment be populated as appropriate on the Application Service CI and then somehow populated downward to other CIs from there (via some custom code)? Or is there another provided/recommended method?

[Jacques Clement]

I'd say use Application Service CI and have the Environment field set appropriately based on the environment.

Then whether one also cascades this value down to all the infrastructure CIs is probably nice-to-have and convenient but not an absolute necessity. The same information can be obtained by navigating through the Depends On relationship between the Application Service and the Infrastructure CI.

I suppose a set a business rules that would do this automatically would be nice though.

[J_r_my POTTIER]

Hello @scott.lemm ,

"used for" field looks still in use in APM. When we want to display only "production" application services on the TPM portal (Technology Portfolio Mgmt):

https://<your instance>.service-now.com/apm?id=technology_portfolio_management

Moreover, this field is also mentioned in the official documentation :

https://docs.servicenow.com/bundle/rome-servicenow-platform/page/product/configuration-management/re...

Maybe, it will be move to "Environment" field in the next releases?

[Jim Zeigler1]

Scott,

Instead of creating a new attribute that still can't properly model the relationships between CIs and environments, wouldn't it be better to migrate customers to use the Environment and Environment to CI tables  (which can model the one to many relationships between a Server and the environments it is used for.

• Based on my experience, database and application servers in a non-prod environment frequently host deployments from more than one environment.

With both the used_for and environment attributes(which are implemented as Choice lists), customers must create a unique choice value for every one of the different combinations of environments that servers can be used for.

Also, instead of relying on manual edits to capture the used for information, once the customer Application Service hierarchy is defined (with Service Groups for each environment at the top of each hierarchy), the environment values could be populated to all the Services and CIs in the hierarchy for each environment.