Customized fields

You can add fields or change field information in your environment. Typically, you make field changes to for the following goals:

• Capture some additional information about a record.
• Provide a way to store a key to link to a separate table.
• Change the context of an existing field to make it required (by changing the field itself or adding additional workflow against that field).
• Manage the values of enumerated fields. The following types of enumerated fields are part of the applications:
• Custom fields are designed to have a gap between the enumerated values. You can add new values in those gaps as long as you use odd number values. This practice ensures that you have no conflicts with values added by BMC.
• For inline enumerated fields, you will want to add new values only to the end of the list because of the impact that these changes have on existing workflow and data if you make changes to the middle of the list.

When you make field changes, know how the fields will be used by existing workflow and integrations. To ensure that existing functionality will continue to work, understand the interface forms and application interactions. If one of these interactions expects that a field is not available or is not required, your design must determine how to handle such issues.

Best practices for customizing fields

Regarding field changes, we recommend:

• Do not change data types for existing fields. If you need a field to hold a different data type, add it as a new field, and hide the existing field.
• If you make an existing field required, add a default value. You can either change the properties of the field itself or set the default by workflow. This practice ensures that existing integrations to the form will continue to work.
• If a field must be accessible to other systems, ensure the field is added to the interface forms for that application. Each application will have defined interfaces for creating, querying, and updating data. In general, the naming convention for these forms is to add _Interface and _Interface_ as suffixes to the form name Create.
• Follow the field ID standards for BMC Helix ITSM applications to ensure that a field does not conflict with another field added by BMC in future releases.
  • The following field ID ranges are reserved by BMC:
    • 1 – 536,870,911
    • 1,000,000,000 – 2,000,000,000
  • The following custom ranges are not used by BMC, so you can use them:
    • 536,870,912 – 999,999,999
    • 2,000,000,001 – 2,147,483,647

• Do not change the database name for an existing field. Reports in the system typically make use of the database field name when querying the database. You can change the display label of a field; however, the database name must remain consistent.
• You can add new values to custom enumerated fields, but add only odd number values to prevent any future conflicts with application upgrades.
  • Enumeration values are incremented with room to allow for values to be inserted between them (1000, 2000, 3000 and so on).
  • You can add values anywhere in the list. Use odd numbers because even enumeration values are reserved for BMC. An example of inserting a value into a custom enumeration follows:

• For linear enumerated fields, you can add new values only to the end of the list. Otherwise, any value that follows a new value added in the middle now has a new value, which impacts existing workflow. This workflow would need to be updated. Also, any existing data in the system would need to be transformed to handle the new value. Any integrations that use this field would need to be updated. An example of a linear enumerated field: Enumeration values are 1, 2,3,4,5, and so on. Do not customize any of the Status fields, typically with Field ID 7, found on all the BMC Helix ITSM forms. The status fields are linear enumerated fields, and the workflow is heavily dependent on the existing values of the status fields.