Workflow Qualification

In the realm of IT service management and business process automation, understanding and effectively implementing workflow is paramount. Workflow, in essence, is the lifeblood of an organization’s operations, defining the sequence of tasks and decisions that ensure processes run smoothly and efficiently. When we talk about workflow in systems like BMC Remedy AR System (and its successor, BMC Helix ITSM), we’re referring to a sophisticated engine that automates these processes using a combination of powerful components: Active Links, Filters, and Escalations. These components are the architects of automation, triggering specific actions based on predefined conditions, thereby transforming raw data into meaningful outcomes.

The core of effective workflow lies in its qualification. Qualification is the process of defining the precise conditions under which a particular workflow component should execute. Without proper qualification, your automated processes can become chaotic, acting at the wrong times, on the wrong data, or not at all. This article delves into the intricacies of workflow qualification within the BMC Remedy AR System framework, exploring the distinct roles of Active Links, Filters, and Escalations, their respective functions, and the critical considerations for their implementation.

Understanding the Building Blocks: Workflow Objects

Before diving into qualification, it’s essential to grasp the fundamental nature of the workflow objects at our disposal:

Workflow Object Functions

• Active Link: These are client-side driven. They execute based on user interactions or information presented on the current screen. Think of them as immediate reactions to what a user is doing right now.
• Filter: These are server-side. They scrutinize form transactions as they are being processed by the server. Filters are the gatekeepers of data integrity and process logic at the server level.
• Escalation: Also server-side, escalations operate on a time-based schedule. They periodically check requests within the database to identify and act upon conditions that may have changed or are due for action.

Workflow Object Descriptions

• Active Links: Imagine a user typing a value into a field, and an Active Link immediately changes the color of another field’s label to red if that value is invalid. Or, perhaps, an Active Link fetches related data from another form and populates a table on the current screen. They are triggered by user actions like clicks, key presses, or focus changes. For a deeper dive into Active Link actions, refer to the BMC documentation on workflow.
• Filters: When a user clicks “Submit” on a form, a Filter might kick in to validate critical fields. If all fields are valid, it proceeds with the submission; otherwise, it might display an error message and prevent the submission. Filters are crucial for business logic that needs to be enforced consistently, regardless of how the data is entered.
• Escalations: Consider a support ticket that hasn’t been assigned to an agent for more than 24 hours. An Escalation can be set up to run every hour, check for such tickets, and then automatically assign them to a default queue or notify a manager. They are the silent guardians of time-sensitive processes.

The Cornerstone of Automation: Qualification

Qualification is not just about specifying a condition; it’s about defining the exact circumstances under which a workflow object should spring into action. This is achieved through the use of qualification expressions, which are essentially logical statements that evaluate to true or false. If the expression evaluates to true, the workflow object executes; otherwise, it remains dormant.

Defining Workflow Behavior

The power of workflow automation in BMC Remedy lies in its ability to respond dynamically to data and user actions. The qualification for each workflow object dictates this responsiveness.

Active Links: Reacting to User Interaction

Active Links are tied to client operations. Their qualification is usually based on the values of fields currently displayed on the user’s screen. For instance, an Active Link might be qualified to execute only when a specific dropdown field contains the value “Urgent” and another field, like “Assigned To,” is empty.

Key characteristics of Active Links:

• Client-Side Execution: They operate within the user’s application window.
• User-Triggered: Primarily initiated by direct user interaction.
• API Limitation: They cannot be triggered by API programs, meaning they are designed for interactive user sessions.
• Naming Convention: Duplicate names are not allowed; the system appends “\_c” to subsequent identical names.
• Mandatory Action: An “Add” action is required, signifying that the Active Link will perform some form of operation.
• Form Saving Behavior: When saving a form as a new form, Active Links are not copied. However, renaming the form preserves its associated Active Links.

Real-world Example: On a Change Request form, an Active Link could be qualified to show a hidden “Approval Group” field only when the “Change Type” field is set to “Emergency.” This ensures the relevant fields are displayed contextually, improving user experience and data entry accuracy.

Filters: Server-Side Data Integrity

Filters operate on the server and have a more profound impact on data manipulation and business logic. Their qualification determines when they inspect and potentially modify data during operations like submission, modification, or deletion.

Key characteristics of Filters:

• Server-Side Execution: They run on the AR System server.
• Database Interaction: Capable of retrieving and modifying data in the database.
• Operation-Specific: Triggered by specific form operations (Submit, Modify, Delete, Get Entry, Merge, Service).
• Administrator Permissions: Filters typically execute with administrator privileges, allowing them broad access for data management.
• Form-Level: They are associated with a specific form.
• Execution Order: They have an execution order (defaulting to 500) which is crucial for defining the sequence of operations when multiple filters apply.

Real-world Example: A Filter might be qualified to execute on “Submit” for a Service Request form. Its qualification could be: 'Status' = "New" AND 'Assigned Group' = "IT Operations". If these conditions are met upon submission, the Filter could then execute an action like “Push Fields” to assign the request to a specific technician within the “IT Operations” group and update the status to “Assigned.”

Escalations: Time-Based Automation

Escalations are the timers of your workflow. They execute at predefined intervals, checking for records that meet their qualification criteria.

Key characteristics of Escalations:

• Server-Side Execution: Similar to filters, they run on the AR System server.
• Database Interaction: Interact with the database to fetch and process data.
• Time-Driven: Triggered by a schedule or time interval, not immediate user operations.
• `ar_escalator` User: Executed by a dedicated system user.
• Broad Scope: Unlike filters which act on the “current” request, escalations act on *all* requests that match their qualification at the time of execution. This makes them powerful for batch processing or proactive alerts.

Real-world Example: An Escalation could be qualified to run daily at 2 AM. Its qualification might be: 'Status' = "Open" AND 'Last Modified Date' < DATEADD(day, -7, DATE()). This Escalation would find all open tickets that haven't been modified in over a week and then trigger an action, such as sending a notification to the assigned group manager or re-assigning the ticket to a "Stale Tickets" queue.

Audit Form Fields: Understanding Change Tracking

When troubleshooting or auditing workflow, understanding how changes are tracked is vital. The Audit form fields provide insight into the types of actions that triggered a modification. These options are crucial for designing effective auditing mechanisms within your workflows.

Audit Action Types:

• 1 GET ENTRY: Indicates that the record was retrieved, often a precursor to other actions.
• 2-Set: Signifies that one or more fields in an existing record were modified.
• 4-Create: Denotes that a new record was added to the database.
• 8-Delete: Represents the removal of a record.
• 16-Merge: Used when records are combined or imported into the system, often through data import utilities.

Leveraging Workflow Actions for Qualification and Execution

Workflow objects (Active Links, Filters, Escalations) are brought to life by actions. These actions are the specific operations performed when the qualification criteria are met. The table below outlines the availability of common actions across different workflow types:

Understanding where each action can be used is key to designing robust and efficient workflows. For example, "Change Field" is primarily an Active Link action, useful for dynamically updating the presentation of fields on the client side, such as changing a field's color or making it visible/invisible. "Push Fields," on the other hand, is a powerful server-side action available to all workflow types, enabling the transfer of data between records.

Filter Execution Options: The "When" of Filter Triggering

Filters have specific execution options that refine when they are triggered. These options define the type of database operation that should initiate the filter's qualification check.

• Modify: The filter runs when a request is changed.
• Submit: The filter runs when a new request is created.
• Delete: The filter runs when a request is removed.
• Get Entry: The filter runs when a request is fetched or queried.
• Merge: The filter runs during bulk data import operations (e.g., using BMC Remedy Data Import).
• Service: This is a special option, often triggered by an Active Link's "Service" action. It allows a filter to process data passed from the Active Link without performing a direct database write operation itself, although it can interact with AR System web services or use "Set Fields" actions.

Action Specificity: When Actions Belong to Specific Workflow Types

Some actions are exclusive to certain workflow types, providing specialized capabilities.

• Only in Active Links (AL): DDE, Open Window, Run Macro, Wait, OLE Automation. These actions are typically client-side or interactive, enhancing the user's direct experience.
• In Filters & Escalations (FLR & ESCL) but not in AL: While the provided list doesn't explicitly state actions exclusive to Filters/Escalations over Active Links (beyond those already listed as exclusive to AL), many core data manipulation actions like "Push Fields" and "Set Fields" are fundamental to server-side processing and thus appear in both FLR & ESCL.
• In Filters but not Escalations: No specific actions are listed as exclusive to Filters over Escalations in this context, suggesting their core action sets are largely aligned for server-side processing.
• In Filters & Escalations: Notify, Change Field, Commit Changes, Call Guide, Exit Guide, Go to Guide Label, Goto, Log to File, Message. These actions are shared, indicating common server-side processing logic or control flow mechanisms.

Advanced Workflow Actions and Their Uses

Beyond the basic actions, several advanced ones offer significant power and flexibility when qualifying and executing workflows.

Direct SQL Action

This powerful action allows you to execute any valid SQL command directly against a non-AR System database. It's indispensable for integrations with other databases.

• Usage: Active Links, Filters, Escalations.
• Purpose: Facilitates integration with external databases.
• Critical Note: BMC strongly advises against using Direct SQL to modify data in AR System's internal tables. Doing so can lead to severe data corruption and is unsupported. Its purpose is for interaction with *other* database systems.

Goto Action

The Goto action provides granular control over the execution order of workflow items.

• Usage: Active Links, Filters.
• Purpose: Allows you to deviate from the normal sequential execution of workflow. When encountered, the system looks for the next workflow object with an execution order greater than or equal to the specified value. This is useful for creating loops or conditional execution sequences.

Go to Guide Label

This action is a companion to Guides, enabling more structured and modular workflow design.

• Usage: Active Links, Filters.
• Purpose: Redirects the execution flow within a Guide to a predefined "label." This allows you to create reusable workflow segments, implement conditional branching, or repeat certain steps within a larger Guide.

Run Process Action

This action allows you to execute external programs or commands.

• Usage: Active Links, Filters, Escalations.
• Purpose: Can run scripts, applications, or AR System commands on either the client machine (for Active Links) or the AR System server. This is crucial for triggering external integrations or administrative tasks.
• Example: A Filter could use "Run Process" to execute a script that generates a report based on updated data.

Service Action

The Service action is particularly interesting for its role in enabling asynchronous processing and integration, often with web services.

• Usage: Active Links, Filters, Escalations.
• Purpose:
  • Active Links/Filters: Triggers filters with an "Execute On" condition of "Service." It's used to pass data from the Active Link to the filter for processing without direct database writes.
  • Escalations: Can be used to set values in the database if output data is provided. It can interact with AR System web services or work in conjunction with "Set Fields" filter actions. This makes it a bridge for more complex service-oriented integrations.

Commit Changes Action

This action has a dual nature depending on its context.

• Usage: Active Links.
• Functions:
  • With Dialog Boxes: Works with "Open Window" and "Close Window" to capture data entered in a dialog. It pushes this data to parent form fields but does *not* save it to the database directly.
  • With Regular Forms: When used on standard forms, it applies changes and performs the primary form action (Submit, Search, or Modify), effectively saving data to the database.

Push Fields Action

A fundamental action for data synchronization and updates.

• Usage: Active Links, Filters, Escalations.
• Purpose: Automates data updates by copying values from specified fields in the current request to another request on the same or a different form. It can update existing records or create new ones. It supports most field types but excludes non-data fields like table or panel holders. Each "Push Fields" action targets one other form, but can affect multiple requests within that form.
• Example: When a Change Request is "Approved," a "Push Fields" action in a Filter could copy key details (like Change ID, Summary, and Due Date) to a "Change Schedule" form.

Commit Changes vs. Run Process "PERFORM-ACTION-APPLY"

Both actions can result in saving a request during a modify operation, but they have distinct characteristics.

• "Commit Changes" is logged in the system logs, making it traceable.
• "Run Process" with "PERFORM-ACTION-APPLY" also saves the request. It's often preferred when the action itself needs to be dynamically determined based on field values within the workflow, offering greater flexibility for complex, generated workflows.

Cache Modes: Understanding Performance Implications

The way BMC Remedy AR System manages its cache significantly impacts workflow execution, especially for administrative tasks and long-running processes.

Production Cache Mode (Default)

In this mode, administrative operations are designed not to disrupt ongoing user activity. When an administrator performs an operation that requires cache modification, a copy of the cache is created. This allows regular application users to continue working seamlessly with the original shared cache.

Use Case: Ideal for production environments with a high volume of concurrent users, ensuring minimal downtime or performance degradation for end-users during system maintenance or configuration changes.

Development Cache Mode

Here, administrative operations can lock out other users from the shared cache, forcing them to wait until the administrative task is complete. This mode can lead to significant delays if long-running tasks (like complex escalations or large integration jobs) are active when an administrator attempts to make cache-affecting changes.

Caution: Development cache mode is generally not recommended for production environments. It's more suited for development or testing where isolating the environment for administrative changes is acceptable.

Other Notable Workflow Components and Utilities

DDE Action

Dynamic Data Exchange (DDE) is an older technology for inter-process communication.

• Usage: Exclusively in Active Links.
• Purpose: Allows data exchange between a client application and the AR System. While still functional, its use is declining with the rise of more modern integration methods.

arsignal Utility

The arsignal utility is a command-line tool used to signal the BMC Remedy AR System server to reload or refresh various types of definitions and information. This is often done after configuration changes or for specific administrative tasks.

• Syntax: arsignal {-a | -b | -c | -d | -e | -g | -l | -m | -p | -r | -u} serverName[:port][sigArgument]
• Key Options:
  • -a: Refreshes Alert user information.
  • -c: Reloads server configuration (ar.conf/ar.cfg).
  • -e: Reloads Escalation definitions.
  • -g: Reloads group and data dictionary information.
  • -r: Recaches definitions from the database.
  • -u: Reloads user information.
• Usage: Can be run from any machine that can access the AR System server.
• Relevance: Essential for ensuring that configuration changes or newly developed workflows are recognized by the AR System server without requiring a full server restart.
• Official Documentation: Managing the Server Cache provides context for `arsignal`.

Ports and Queues Tab

Located within the AR System Administration Console, this area is critical for managing the server's communication pathways and thread allocation.

• Server Ports: Configures RPC numbers and ports used for communication between clients, servers, and various services.
• Server Queue: Governs the configuration of server queues and threads, essential for the multithreaded architecture of BMC Remedy AR System. Proper configuration here ensures that workflow processes (like filters and escalations) are handled efficiently without causing bottlenecks.

Troubleshooting Workflow Qualification Issues

When your workflow doesn't behave as expected, the qualification is often the first place to look. Here are common pitfalls and how to address them:

• Incorrect Field References: Double-check field IDs and names in your qualification. A simple typo can render a qualification ineffective.
• Data Type Mismatches: Ensure you are comparing or manipulating data of the same type. For instance, comparing a date field to a text string without proper conversion will likely fail.
• Operator Errors: Verify the use of logical operators (AND, OR, NOT) and comparison operators (=, !=, >, <, LIKE). Misplaced parentheses can drastically alter the evaluation of complex qualifications.
• Case Sensitivity: Be mindful of case sensitivity, especially when dealing with text fields. Use functions like `UPPER()` or `LOWER()` if case-insensitive matching is required.
• Execution Order Conflicts: If multiple workflow objects are triggered by the same event, their execution order (for Filters and Escalations) can lead to unexpected results. Use the AR System Administrator Console to review and adjust execution order.
• Cache Issues: After making changes to workflow, if they don't seem to take effect, try using arsignal -c (for configuration) or arsignal -r (for recaching definitions) to force the server to reload the definitions.
• Server Logs: The AR System logs (arevent.log, arerr.log) are invaluable. They will often indicate when a workflow was triggered, if its qualification passed or failed, and any errors encountered during action execution.

Interview Relevance

Understanding workflow qualification is a cornerstone of any BMC Remedy or BMC Helix ITSM administration or development role. Interviewers will likely probe your knowledge in these areas:

• Differentiate between Active Links, Filters, and Escalations: Be prepared to explain their purpose, execution context (client vs. server), and typical use cases.
• Explain Qualification Syntax: Be ready to construct simple or complex qualification examples and explain how they work.
• Discuss Action Availability: Know which actions are suitable for which workflow types and why. For example, why "Open Window" is an Active Link action and not available for Filters.
• Troubleshooting Scenarios: Describe how you would debug a workflow that isn't firing correctly, mentioning log analysis and cache management.
• Cache Modes: Explain the implications of Production vs. Development cache modes and when to use each.
• Real-world Examples: Provide practical examples of how you've used these components to solve business problems.
• Direct SQL Risks: Be aware of and able to articulate the dangers of using Direct SQL improperly.

Conclusion

Workflow qualification is not merely a technical detail; it's the strategic intelligence behind automated processes. By meticulously defining the conditions under which Active Links, Filters, and Escalations operate, organizations can ensure that their IT Service Management and business processes are not just automated, but intelligently and reliably automated. Mastering these concepts is essential for anyone looking to build efficient, robust, and responsive systems within the BMC Remedy and BMC Helix ecosystems.

For further reading on workflow concepts and their implementation, the official BMC documentation is an indispensable resource:

• Creating and Managing Workflow: Filters, Escalations, and Active Links
• Workflow Objects and Actions