Demystifying Workflow Fundamentals in BMC Remedy AR System

In the complex world of IT Service Management (ITSM), efficiency and automation are not just buzzwords; they are the bedrock of successful operations. At the heart of BMC Remedy AR System’s power lies its robust workflow engine. Understanding workflow fundamentals is crucial for anyone looking to tailor the system to their organization’s unique processes, troubleshoot issues, or even land that coveted developer or administrator role. This article will dive deep into what workflows are, the core components that power them, and how they interact to create seamless automated processes.

What Exactly is a Workflow?

At its simplest, a workflow can be defined as the series of processes and actions an organization uses to conduct its business. Think of it as the organizational DNA – the predefined steps that guide tasks from initiation to completion. In the context of BMC Remedy AR System, a workflow is much more than just a theoretical concept. It’s a tangible set of logic and rules that automate these business processes.

This automation is achieved through the intelligent use of several key components: Active Links, Filters, and Escalations. These components are designed to trigger actions based on specific, user-defined execution options. In essence, they allow Remedy to “think” and “act” in response to events happening within the system.

The core idea is to empower the system to react automatically to user interactions, data changes, or scheduled events, thereby reducing manual effort, minimizing errors, and ensuring consistent application of business rules.

The Building Blocks of Workflow: Objects and Their Functions

To truly grasp workflow fundamentals, we need to understand the primary objects that constitute them and their specific roles:

1. Forms (Schema) – The Data Canvas

Before we can talk about actions, we need a place to store information. In Remedy AR System, Forms serve as the interface for users to interact with data, but on the backend, they are essentially the schemas that represent tables in the underlying database. These forms hold the records (data) that our workflows will manipulate.

2. Active Links – User-Driven Actions

Active Links are the frontline responders to user interaction. They are triggered based on what a user does directly within the application or on the current screen. Think of them as the system’s immediate reflexes to your clicks, keystrokes, or selections. Their functions are diverse and immediate, including:

• Displaying messages to guide the user.
• Changing the visual appearance of fields (like altering label colors for emphasis).
• Fetching data from other forms or pushing data to them.
• Performing client-side validations before data even hits the server.

Crucially, Active Links execute on the client side. This means they run in the user’s browser or the AR System client application, providing instant feedback without needing to involve the server for every single action. This client-side execution is what makes them ideal for enhancing user experience and performing immediate validations or data displays.

Active Link Nuances:

• Uniqueness: An Active Link with the exact same name is not allowed within the same workflow context. If you try to create one, Remedy will automatically append “_c” to the name to ensure uniqueness.
• Mandatory Action: Every Active Link must contain at least one action. A definition without an action is effectively useless.
• Save As Behavior: When you use “Save As” on a form, the Active Links associated with it are not copied by default. However, if you rename the form, Remedy *will* bring over all associated Active Links.
• API Limitation: Active Links cannot be triggered through the use of an API program. They are strictly tied to user operations.

3. Filters – Server-Side Guardians

While Active Links handle immediate user interactions on the client, Filters are the silent guardians operating at the server level. They are triggered by specific operations or transactions occurring on a form, such as submitting a new request, modifying an existing one, or deleting a record. Filters interact directly with the database to retrieve or modify data and enforce business logic.

• Execution: Filters execute on the AR System server.
• Permissions: They run with administrator permissions, giving them the power to make significant changes.
• Focus: Filters act on the *current* request that meets their defined qualification criteria.
• Execution Order: Filters have an execution order (defaulting to 500), which is crucial for defining the sequence in which multiple filters will run during a transaction.

Consider a scenario where a user submits a new incident. A filter might be triggered to:

• Validate that all mandatory fields are filled.
• Assign a default priority based on the reported issue.
• Send an email notification to the user confirming ticket creation.
• Update a related form with information from the new incident.

4. Escalations – Time-Based Taskmasters

Escalations share similarities with Filters in that they are server-side workflow objects that interact with the database. However, their trigger is fundamentally different: time. Unlike filters, which respond to specific transactional events, escalations execute based on a predetermined time interval or at a specific point in time.

• Execution: Like filters, escalations run on the AR System server.
• Trigger: Time-based (e.g., every hour, daily at midnight, 24 hours after creation).
• Scope: While filters typically act on the *current* request, escalations are designed to find and act on *all* requests in the database that meet their qualification criteria at the time of execution.

Common uses for escalations include:

• Sending reminder emails for overdue tasks.
• Automatically changing the status of tickets that have been open for a long period without updates.
• Archiving old records.
• Performing scheduled data clean-up tasks.

Execution User: Escalations are executed by a dedicated system user, often referred to as `ar_escalator`. This distinction is important for understanding permissions and how they are applied.

Access Control: The Gatekeepers of Data

In any robust system, controlling who can see and do what is paramount. BMC Remedy AR System employs two primary mechanisms for this:

• Permission Groups: These define collections of permissions that can be assigned to users. They determine access at a higher level.
• Roles: Roles are more granular and can be used to assign specific sets of permissions and workflow access to users or groups.

Together, these objects control access to various elements within Remedy, including forms, specific rows within forms, and even individual columns (fields).

Understanding Workflow Actions: The “Doing” Part

Workflow objects (Active Links, Filters, Escalations) define when something happens. Workflow actions define what happens. BMC Remedy AR System provides a rich library of actions that can be used, often across different workflow types. Let’s explore some of the most significant:

Commonly Used Actions Across Workflow Types

Several powerful actions are available for use in Active Links, Filters, and Escalations, allowing for complex automation:

• Push Fields: This is arguably one of the most frequently used actions. It enables you to automatically transfer values from fields in the current request to fields in another request, either on the same form or a different one. It can be used to update existing records or even create new ones in the target form. This is the workhorse for synchronizing data across different parts of the system.
• Set Fields: Similar to Push Fields, but generally more focused on manipulating values within the current form or setting variables. It’s excellent for calculations, assigning default values, or modifying field data before it’s saved.
• Run Process: This action allows you to execute an external program or script on the client machine or the AR System server. This is incredibly powerful for integrations or triggering custom logic that Remedy itself cannot handle directly, such as sending faxes, making specific log entries, or interacting with other applications.
• Direct SQL: Use this with caution! The Direct SQL action allows you to submit any legal SQL command to a non-AR System database. It’s primarily for integrating with external databases. BMC strongly advises against using it to modify data within AR System’s own tables, as this can lead to data corruption. It’s designed for pushing data *out* to other systems.
• Service: This action triggers filters that have their “Execute On” condition set to “Service”. It’s used to perform services, either by interacting with external web services or by calling internal AR System services. It can pass data between the calling transaction and the service provider, returning output values.
• Log to File: Useful for debugging and auditing, this action writes specified messages to a log file on the server.
• Message: Displays a pop-up message to the user. Common for confirmations, warnings, or displaying brief status updates.

Actions Primarily for Active Links

These actions leverage the client-side execution of Active Links to enhance the user experience:

• Change Field: Modifies the properties of a field, such as making it visible, read-only, or changing its color. Great for dynamic UI adjustments.
• Close Window: Closes the current window or dialog box.
• Commit Changes: This action has a dual purpose. When used with a dialog box, it captures data entered in that box and pushes it to fields on the parent form. When used with a regular form, it actually initiates the major form action (like Submit, Search, or Modify) and saves the changes to the database.
• Open Window: Opens a new window, which can be another form, a dialog box, or a URL.
• Run Macro: Executes a macro created in BMC Remedy User. This is client-side specific and not supported in web clients.
• DDE Call: Allows data exchange with other applications using Dynamic Data Exchange. (Note: DDE is an older technology and less common now).

Actions Primarily for Filters and Escalations

These actions are often used when server-side processing and database interaction are key:

• Call Guide: Executes a defined “guide” (a sequence of workflow objects).
• Go to Guide Label: Redirects workflow execution within a guide to a specific labeled section.
• Goto: This action allows you to control the order of execution by jumping to another active link or filter based on a specified execution order. It doesn’t require a guide structure.

Comparing “Commit Changes” and “Run Process – PERFORM-ACTION-APPLY”

This is a common point of confusion. Both can result in saving a modified request:

• Commit Changes: When used on a regular form in a Modify operation, it performs the save. It’s a direct action to commit the current transaction.
• Run Process – PERFORM-ACTION-APPLY: This is a more programmatic way to trigger the “Apply” action of a form. It can be dynamically generated, making it powerful for dynamic workflow scenarios. The key difference in logging is that “Commit Changes” is explicitly logged, whereas the underlying action triggered by “Run Process” might be less obvious in the raw logs. For dynamic workflow generation where actions are determined on-the-fly, “Run Process” is often preferred.

Filter Execution Options: When Do Filters Spring to Life?

Filters are triggered by specific events that occur during a form transaction. Understanding these options is crucial for correctly defining when a filter should execute:

• Submit: Executes when a new request is submitted to the server. This is for new record creation logic.
• Modify: Executes when an existing request is modified. This is for handling changes to existing data.
• Delete: Executes when a request is deleted. This can be used for auditing or cascading deletions.
• Get Entry: Executes when a request is retrieved or viewed. Useful for pre-populating fields or performing read-time actions.
• Merge: Executes when a request is merged into the database. This typically happens during bulk data imports (like using BMC Remedy Data Import or DSO).
• Service: As mentioned, this option is used when the filter is intended to be called by a “Service” action from another workflow object. It doesn’t perform direct database write operations itself but processes data passed to it.

Audit Form Fields: Tracking Workflow Triggers

When you need to understand what caused a particular event or data change, auditing is your friend. The audit log (often associated with specific fields) captures the actions that triggered an audit. The common action types are represented by numerical values:

• 1 – GET ENTRY: A record was retrieved.
• 2 – Set: A field value was modified.
• 4 – Create: A new record was created.
• 8 – Delete: A record was deleted.
• 16 – Merge: A record was merged via import.

Understanding these codes can help you interpret audit trails and pinpoint exactly which operation led to a recorded change.

Cache Modes: A Behind-the-Scenes Performance Factor

The performance of your AR System server, especially during administrative operations, can be significantly impacted by its cache mode. There are two primary modes:

• Production Cache Mode (Default): In this mode, administrative operations (like deploying workflow changes) create a separate copy of the server’s cache. This allows regular application users to continue working seamlessly without interruption. It’s ideal for production environments with high user activity.
• Development Cache Mode: Here, administrative operations lock the shared cache, preventing other users from accessing it until the administrative task is complete. This can lead to significant delays for users, especially if long-running tasks like escalations or integrations are active. It’s generally unsuitable for production but can be useful during focused development to ensure changes are immediately reflected.

The choice of cache mode can have a profound impact on user experience and system responsiveness.

Advanced Actions and Considerations

Go To and Go to Guide Label: Controlling the Flow

These actions offer fine-grained control over workflow execution sequence:

• Goto: Allows you to jump to another Active Link or Filter based on its execution order. This can be useful for creating loops or executing common blocks of workflow multiple times within a single transaction.
• Go to Guide Label: This is used within the context of a “Guide” (a structured sequence of workflow objects). It allows you to jump to a specific labeled section within that guide. This promotes modularity, enabling you to create reusable workflow segments that can be branched to.

The Utility of arsignal

The arsignal utility is a powerful command-line tool used to force an AR System server to load or reload specific information. This is invaluable for administrators when changes made outside the normal interface need to be recognized by the server.

Some common arsignal options include:

• -c: Reloads the server’s configuration file (ar.conf or ar.cfg).
• -e: Recaches and reloads escalation definitions.
• -r: Recaches definitions from the database (e.g., forms, fields).
• -u: Reloads user information.
• -d: Transfers the signal to a DSO (Distributed Server Option) process, useful for synchronization.

Using arsignal correctly ensures that changes are picked up by the server without requiring a full server restart, minimizing downtime.

Troubleshooting Common Workflow Issues

Workflow misbehavior is a common challenge. Here are a few areas to investigate:

Conclusion

Mastering BMC Remedy AR System workflow fundamentals is an ongoing journey. By understanding the distinct roles of Active Links, Filters, and Escalations, the power of various workflow actions, and the nuances of execution and access control, you equip yourself to build highly efficient, automated, and robust ITSM solutions. Whether you’re an administrator troubleshooting a persistent bug, a developer building new functionality, or an analyst seeking to optimize processes, a solid grasp of these core concepts is your most valuable asset. Keep experimenting, keep learning, and keep automating!