Customized BMC Remedy ITSM workflow

You can change the existing workflows or add new workflows and still ensure that the new or modified workflows will work successfully with the applications.

Adding a new workflow

You can add a new workflow to extend the functionality of an application.  However, that workflow needs to be built so that it does not affect the primary flow of the application. Examples of workflows that you can add that would not affect the processing of an application include:

• Client-side workflow (active links) that provides for navigation to other forms or displays lookups to select data that is pulled into the existing form
• Server-side business logic (filters) that perform the following operations:
  • Validation of data in new fields that have been added
  • Additional notifications (either as integration points to the BMC Remedy ITSM Notification Engine or as separate BMC Remedy Action Request System notifications)

  • Pushing data into other forms that have been added

    Tip

    The Notification Engine provides a back-end workflow model for defining which notifications should be sent, based on events in the application. For further information about the BMC Remedy ITSM Notification Engine, see Notification Engine.

  • Setting data from newly added forms into fields that have been added
• Server-side Escalation Logic, which enables data to be polled periodically and permits actions to be performed on this data. You can add this functionality to new forms, but use caution when you are adding it to existing forms because it might impact system performance.
• Menu Objects, which you can add to fields to enable the lookup of data to populate fields. If you define a menu as a type-ahead menu, it will show values based on the data being entered in the field. However, use this option sparingly to avoid performance impacts on the form.

Best practices for customizing workflow in BMC Helix ITSM and BMC Remedy ITSM

Ensure that existing optional processes are not changed to required processes, because this will affect existing integrations that do not expect required functionality. To ensure that you are not affecting other workflows, BMC recommends that you leverage the BMC Remedy AR System functionality that shows the workflow that is associated with a field. This will enable you to see which functions are affected by populating a specific field with data.

After you have ensured that your new workflow will not affect existing functionality, build and test your new workflow. Provide a name for your workflow that identifies it as your new workflow. BMC recommends that you add a new or modified identifier to the name of your object as either a prefix or suffix. This will ensure that the workflow is not overwritten during an upgrade. Also, it will enable you to see which workflow is added or modified. Adding comments to the Change History tab for the workflow object will also track changes made to the workflow. The following information shows an example of how to document workflow changes.

Sample customer document

If changes are required to out-of-the-box workflow to support your customizations, use overlays to make changes to the BMC Remedy AR System workflow objects. This will ensure that these changes are preserved after an upgrade. If you want to revert back to the original functionality of the application, you will disable or remove the overlay for these objects.

Updating existing processes

This information discusses how to update existing application processes.

Status

The status workflow provides functionality that is critical to the running of the applications. Status drives the process flows for the applications. The applications have a specific field that drives status flows (for example, see the Status field in the Incident Request window for BMC Service Desk: Incident Management that follows). Typically, this is Field ID 7, except for BMC Change Management, which has a different field ID so it can have more controllable status transitions. The following information describes:

• The status components that cannot be changed due to their involvement in processing applications
• The functionality that you can change and how you can implement these changes

Because status values and basic flows are integral to the processing of applications, you cannot change the workflow that controls these areas.  However, you can customize other areas to extend the functionality of applications, and in the case of BMC Change Management, you can control the process flow via data.

Updating change status transitions

You can access the data-driven model for status transitions for BMC Change Management and Release Management via the Process Flow Configuration window. This window enables you to change how a change record moves between the existing status values. It also controls the status values that appear in the Status menu so that just the values for appropriate transitions apply for the current state. Transitions are managed via data, so no changes to code are required to manage status flow changes. For more information, see   Change status transitions - Draft to complete with task phase management enabled . 

Updating status reason

The status reason is a value that is contextual to the current status. You can extend this field is to provide some additional information for the current status or provide a way to trigger workflows from a function that occurs during the specific status.  

Components on the back-end include base workflow functionality, data, and an enumerated field that drives the status reason. You can add values for additional status reasons, but BMC does not recommend it because you would need to make additional changes to the selection fields.

If you make changes, you must perform the following actions:

1. Update the data in the SYS:Status Reason Menu Items form (shown in the following window) to add the additional values for the menu. These items will be based on the value of the current status.
   
   

2. Update the enumerated Status_Reason field (Field ID 1000000150) to add the new value. Use the same enumeration as you did when you created the data record.  Add a value that is an odd number so that it is not impacted by future upgrades.
3. Ensure that the changes to this field are done on the HPD:IncidentInterface_Create form and the appropriate forms for data loads for each application that you are changing.