Workflow change guidelines

Keep workflow changes to a minimum and keep the the changes separate from the existing application flow. This approach prevents issues occurring from the workflow that interact with other system components which change during an upgrade. The following workflow changes don't impact other parts of the application.

You can make the following workflow changes for both the BMC Helix ITSM and the BMC Helix ITSM on-premise environments. Use overlays for these changes so that you can track the changes.

• For existing forms, add new workflows that do not affect the processing of existing workflows. You must ensure that the new workflow does not change when the existing workflow runs. Because the process workflow can change from release to release, we recommend that you avoid these types of code changes.
• Add new forms to the system and add new workflows to support the processes on these new forms.
• Add new workflows to read data from your new forms by:
  • Adding active links to the main forms associated with new buttons or links.
  • Adding table fields to the existing forms to read data from newly added forms and the workflow to interact with the tables.

If you are making changes to key processes in the application, avoid changing the following workflow processes:

• Status flows
• Permission-based workflow (multitenancy, support groups)
• Interactions with processes such as approvals and Assignment Engine
• Interface forms

Instead of making changes to the underlying code that drives these processes, you can configure the data.

Workflow coding style

In Action Request System, a workflow refers to the operations carried out by active links, filters, and escalations. Workflows are triggered by user actions, such as submitting a form or clicking a button, by other workflows, or by time. Workflows act on the data stored in forms to automate business processes.

Guides

Use guides to group and reuse workflows as functions.

Unqualified searches

Develop in the most restrictive setting without selecting the server setting Allow Unqualified Searches. This setting raises more awareness for the need to qualify tables and other workflow objects. For client-side active links that start in Search mode, ensure that all fields being set are accessible and visible to end users so that if unqualified searches are permitted at their site, any expected result occurs in the client. 

DSO aware workflow

The Distributed Server Option (DSO) that is available with the AR System platform enables you to transfer data between forms on two servers. You need to configure the DSO service, create mappings to map forms and fields between the two servers, and to create DSO workflow (filters) to perform the transfer and delete functionality. For more information, see  Configuring Distributed Server Option . 

The DSO filter that transfers the data starts on a merge action, and the DSO delete filter starts on a delete action. To avoid a clash between out-of-the-box workflow and the DSO merge filters, qualify the merge filters to not start.

Because the DSO delete filter deletes the form records, bypass all the out-of-the-box delete workflow so that the workflow doesn't start when triggered by a DSO delete.

Performing the following actions as coding standards to make the out-of-the-box workflow DSO aware:

1. DSO qualify any new merge filters that you create. Add the following information to the Run IF qualification for the merge filters:

   The exceptions are the merge filters that check for unique records and provide messages (as those need to be caught on a DSO transaction, too). 

   AND ($USER$ \!= "Distributed Server")

   
   Some filters have a mix of OR and AND clauses in the Run IF qualification, so ensure that you have the brackets in the correct place, for example:

   (($OPERATION$ = "CREATE" ) OR ($OPERATION$ = "MERGE" ) OR
   (($OPERATION$ = "SET" ) AND ( 'z1D Action' = "BUILDUNIQUE" ))) AND (
   'Permission Group Type' = "Application Permission") AND ( 'z1D Previous
   Operation' = "SET" ) AND ($USER$ \!= "Distributed Server" )

2. Add any new forms with delete workflow to this shared workflow:

   SHR:SHR:SkipDeleteFiltersFor_DSO_User

Best practices for changing workflows

The following recommendations apply to the BMC Helix ITSM and the BMC Helix ITSM environments:

• Use service calls to avoid performance impacts. Evaluate the data that you want to pull into a new form. If you determine that a number of queries must be completed by using active links to retrieve the data, perform the following actions:
  • Investigate by using filters instead of active links.

  • Use a service call from an active link to reduce the number of server calls required to retrieve the information.

• Use escalations only to add to new forms due to the potential impact on system performance.
• Do not change out-of-the-box web services due to the potential impact on applications that might use these web services for integration purposes. Changes to out-of-the-box web services might be overwritten during an upgrade. The best solution is to copy an out-of-the-box web service and extend that web service for any specific requirement.
• Use a namespace that does not conflict with out-of-the-box or future system workflows to build any workflow that is added to the system. You can use a unique prefix for your application objects to avoid any future workflow conflicts if multiple companies are running on the same instance of the AR System server.

Adding a new 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. 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 Helix ITSM Notification Engine or as separate AR 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 are to be sent, based on events in the application. For further information about the BMC Helix 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 workflows

Ensure that existing optional processes are not changed to required processes because this situation will affect existing integrations that do not expect required functionality. To ensure that you are not affecting other workflows, we recommend that you leverage the AR System functionality that shows the workflow that is associated with a field. This practice 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. We recommend that you add a new or modified identifier to the name of your object as either a prefix or a suffix. This convention ensures 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 an out-of-the-box workflow to support your customizations, use overlays to make changes to the AR System workflow objects. This way, 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 section describes how to update existing application processes, such as status, status transitions, and status reasons.

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 Helix ITSM: Service Desk: Incident Management that follows). Typically, this field 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 Helix ITSM: Change Management, you can control the process flow by using data.

Updating change status transitions

You can access the data-driven model for status transitions for BMC Helix ITSM: 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   Task Phase Management . 

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 we do 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 to add the additional values for the menu.
   These items are 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.