Forms change guidelines

Refer to the following guidelines that explain how to make form changes so that your changes are not affected by system upgrades. As with any code changes, use overlays.

• You can add new fields; however, avoid adding new required fields because you might need to change existing integrations. Alternatively, you can provide a default value for the new required field so that it can be set automatically if an older integration interfaces with the application.
• Add new fields in the field ID range that is not reserved by BMC. For more information, see User interface object designs.
• Do not remove any existing fields because it can potentially affect the overall processing of the applications and affect existing workflow. If you do not want to have a field appear to a user, use an overlay of the form and view to remove the field from the view so that it is not visible to the user.
• Do not change the properties of existing fields, including whether they are their required fields, data types, and their pattern matching because it can affect the existing processing of the record, and are overwritten during an upgrade. If you need to change these properties, create a new field, change the properties on that field as appropriate, and then hide the original field.
• You can add new forms but add them in your specific namespace.
• You can add values to a linear selection field; however, we recommend avoiding it because it causes data and workflow issues.
• You can add values to a nonlinear selection field.
• If you add new fields to a form that has to be accessible to integrations, they must also be exposed in the interface forms and web services.

One of the benefits of the AR System platform is that you are able to customize the layout of your forms. BMC provides a set of Best Practice views that are based on best practice workflows for each BMC Helix ITSM application. 

You can update views to:

• Place a new field appropriately in the user interface so that it can be accessed by an end user.
• Adjust the layout of a view to make the flow more appropriate for the needs of a company (you might want to hide unused fields, for example.)
• Change the color scheme of a form to make it fit in with your corporate "look and feel."

When making changes to the views, ensure that you leverage the user interface to support the appropriate user flows. Evaluate the views in the context of how an end user will use them, and then you can determine where to place each new data field. The current Best Practice views assume that the user will start entering data in the fields from beginning to end in the first column and then move to the next column to enter any other data that needs to be captured.  

The BMC Helix ITSM applications display only data that is required most of the time in the main views. If data is required only for some specific supporting actions, that data is moved to a separate dialog and is accessed via the navigation bar on the one side of the form.

Best practices for customizing forms

We recommend that you use the following approach for customizing to forms:

• Instead of changing colors, backgrounds, and images directly in the view, leverage the AR System Skins feature. With the Skins feature, you use the Skins form to add data to reference the views where you want to change the color or images or add a new color or image. These changes do not affect the form definition itself, so all of these changes are backward compatible. For more information about the Skins feature, see  Applying skins to form views .
• Always make changes by using an overlay of the form and view.
• Use the overlaid view name in your workflow. Because the AR System server uses the view name as a unique identifier, the original view name must be used to ensure that workflow is not broken.

You can always go back to the original view provided with the application by disabling or deleting your overlay.

When updating views, ensure that you display only the required fields on a view. AR System does not require that a field be displayed on a view for it to be accessible via workflow. If you have a field that is there only to support referencing other data, you do not have to display the field in any views.

In the AR System view structure, each language has its own separate view on a form. If the change that you make must be displayed in multiple languages, you must make the same change for each of the views that represent each individual language, using the steps already given.