Cross-Reference Notifications: Streamline Your Workflow & Reduce Errors

Cross Reference Notifications

In the complex world of IT service management and enterprise applications, keeping systems in sync and ensuring that users are informed about critical events is paramount. This is where the concept of “Cross Reference Notifications” comes into play. While the term itself might sound a bit technical, at its core, it’s about making sure that when something important happens in one part of your system, the right people are notified, and relevant information is updated across other interconnected parts. Think of it as a sophisticated “chain reaction” of information and action.

In the context of BMC Remedy AR System (now part of BMC Helix), this is achieved through its powerful workflow engine. This engine allows us to define automated processes that respond to various events, ensuring that data is consistent and users are kept in the loop. Understanding how these workflows interact, particularly how they trigger actions on each other, is key to building robust and responsive applications.

Understanding the Foundation: Workflows, Forms, and Access Control

Before we dive into the specifics of cross-referencing, it’s essential to have a solid grasp of the fundamental building blocks in BMC Remedy AR System:

Workflows: The Engine of Automation

A workflow in BMC Remedy AR System is essentially a set of predefined processes designed to automate business operations. These workflows are brought to life through three primary components:

Active Links: These are designed to respond to user actions on the client-side, like clicking a button, changing a field’s value, or opening a form. They are your first line of defense for immediate, interactive feedback and data manipulation.
Filters: Filters operate on the server-side and are triggered by transactions happening to data records. This includes submitting, modifying, or deleting requests (records) in a form. They are crucial for enforcing business logic and ensuring data integrity before or after a database operation.
Escalations: Escalations, also server-side, are time-based. They check requests in the database at predetermined intervals to trigger actions. Think of them for overdue tasks, aging tickets, or scheduled maintenance notifications.

These workflow objects can trigger actions based on specific conditions you define. In essence, they automate your company’s processes.

Forms: The Data Backbone

Forms in BMC Remedy AR System are the graphical user interfaces that represent the underlying database tables (schemas). They are where users interact with data and where data is stored.

Active Links: Operate based on user interaction within the current form window. They can display messages, change field appearances, or push/fetch data to/from other forms. It’s worth noting that renaming an Active Link might not copy it, but renaming a form will typically preserve its associated Active Links. Also, duplicate Active Link names are not allowed; the system appends `_c` if a conflict arises. An Active Link requires at least one action to be defined.
Filters: Execute on the server when a form transaction occurs (Submit, Modify, Delete, Get Entry, Merge). They are executed based on form-level qualifications and have an execution order (defaulting to 500). Filters interact directly with the database to retrieve and manipulate data.
Escalations: Similar to filters in that they are server-side and interact with the database, but their trigger is time-based rather than a specific user operation. They can act on multiple requests that meet a qualification, unlike filters that typically act on the current request.

Access Control: Guardians of Data

Permission Groups and Roles are fundamental for controlling who can see, access, and modify data within your AR System application. They ensure that sensitive information is protected and that users only interact with data they are authorized to.

The Magic of Cross-Referencing: How Workflows Talk to Each Other

Cross-referencing occurs when an action performed by one workflow object (like an Active Link or a Filter) triggers another workflow object, often on a different form or in a different part of the system. This creates a dynamic and interconnected application experience.

Active Links: Initiating Actions

Active Links are often the “initiators” of cross-reference notifications because they directly respond to user input. When a user interacts with a form:

An Active Link can be triggered.
This Active Link can then perform various actions. The most common actions that facilitate cross-referencing include:
- Push Fields: This is perhaps the most direct way to cross-reference. An Active Link can take data from the current form and push it to fields on another form, or even to another record on the same form. For example, when a user marks a task as “Complete” on a Task form, an Active Link could push the completion date and status to the parent Incident form.
- Open Window: An Active Link can open another form, potentially pre-filling some fields based on the current record. This is useful for drilling down into related information.
- Service: This action allows an Active Link to trigger a Filter that has its “Execute On” condition set to “Service.” This is a powerful mechanism for complex server-side processing initiated from the client.
- Run Process: Can execute an external script or application, which in turn could update other systems or send notifications.

Crucially, Active Links cannot be triggered by API programs; they are strictly tied to user interactions within the AR System client.

Filters: Enforcing Logic and Propagating Changes

Filters play a vital role in propagating changes and ensuring data consistency across forms:

When a record is submitted, modified, or deleted, a Filter can be triggered.
Filters can perform actions that affect other records or forms:
- Push Fields: Similar to Active Links, Filters can push data to other forms or records. For instance, when an Incident is resolved, a Filter might push the resolution details to a related Problem Investigation record.
- Service: A Filter can be triggered by a Service action from an Active Link, allowing for complex server-side logic to be executed.
- Run Process: Can execute external scripts or applications to update other integrated systems or trigger external notification mechanisms.
- Direct SQL: For advanced integrations, a Filter can execute direct SQL commands against non-AR System databases, allowing for sophisticated cross-database data synchronization.

Filters execute on the AR System server with administrator privileges, making them powerful tools for data manipulation and system integrity.

Escalations: Time-Based Cross-Referencing

Escalations bring a temporal dimension to cross-referencing:

At scheduled intervals, Escalations scan the database for records meeting specific criteria.
When found, they can trigger actions similar to Filters, including:
- Push Fields: For example, an escalation might check for overdue Change requests and push a “Notification Sent” flag to a related Change Request form.
- Run Process: Could initiate a nightly process to update a data warehouse with recent ticket information.
- Notify: While primarily for direct notifications, the ‘Notify’ action within an escalation can indirectly trigger further workflow if configured to do so on another form via subsequent filters.

This time-based nature makes escalations perfect for proactive alerts, automated clean-up tasks, or reporting that requires periodic data aggregation.

Key Workflow Actions for Cross-Referencing

Let’s examine some specific workflow actions that are instrumental in creating cross-reference notifications:

Action Type	Active Links	Filters	Escalations	Description
Push Fields	☑	☑	☑	Transfers data from selected fields in the current request to another request (on the same or a different form). This is the workhorse of data synchronization.
Notify	☑	☑	☑	Sends notifications (email, SMS, etc.) to users. While not directly cross-referencing data, it informs users about events, which might trigger their own actions.
Run Process	☑	☑	☑	Executes an external program or script on the client or server. This allows for deep integration with other systems.
Service	☑	☑	☑	Triggers filters with an “Execute On” condition of “Service.” This is a way to initiate server-side processing from client or other server processes.
Direct SQL	☑	☑	☑	Allows execution of raw SQL commands against external databases. Use with caution and for integrations only.
Open Window	☑			Opens another form, often for navigation or displaying related details. Can be used to present cross-referenced data in context.
Change Field	☑			Modifies the properties of fields on the current form (e.g., making them visible, hidden, read-only, or changing their color). Can be used to highlight cross-referenced information.
Commit Changes	☑			Saves changes made to the current form. It’s crucial when Active Links perform multiple field modifications before the user explicitly saves.
Goto	☑	☑		Allows redirection of workflow execution to another active link or filter, enabling conditional branching and complex logic flow.
Go to Guide Label	☑	☑		Redirects workflow execution within a defined “guide” (a sequence of workflow objects). Essential for organizing and reusing workflow logic.

Understanding the Nuances: Specific Action Differences

Some actions have specific contexts:

DDE (Dynamic Data Exchange): This action is exclusively used in Active Links to facilitate data exchange between a client and server using DDE. It’s an older technology for inter-application communication on Windows.
Run Macro: This action is also specific to Active Links and runs macros created in the BMC Remedy User client. It’s not supported in web clients.
Commit Changes vs. Run Process “PERFORM-ACTION-APPLY”: Both can save a request. However, “Commit Changes” is clearly logged, while the action within “Run Process” might not be as transparent. For dynamic workflow generation where the action itself is derived from data, “Run Process” is often preferred.

Practical Examples of Cross Reference Notifications

Let’s illustrate with some real-world scenarios:

Scenario 1: Incident Resolution Update

When an IT Support agent resolves an Incident, they update the Incident form. A Filter on the Incident form, triggered on ‘Modify’, can then:

Check if the Incident Status has changed to “Resolved”.
If true, use the Push Fields action to copy the “Resolution Details” and “Resolved Date” from the Incident form to corresponding fields on a related Problem Investigation form.
Optionally, use Run Process to send an email notification to the affected business unit manager informing them of the resolution.

This ensures that the Problem Management team has the latest resolution information and that stakeholders are informed, all automatically.

Scenario 2: Change Request Approval Notification

A Change Manager approves a Change Request. An Active Link on the Change Request form, triggered by the “Approve” button click, can:

Update the “Approval Status” field to “Approved”.
Use the Push Fields action to copy the approved Change Request details (like Change ID, Summary, Scheduled Start Date) to a “Scheduled Changes” form.
Trigger a Service action to a Filter. This Filter then uses Run Process to call an external calendar API to add the approved change to a company-wide IT calendar.

This keeps everyone informed about upcoming changes and integrates with other calendaring systems.

Scenario 3: Overdue Task Alert

An Escalation runs every hour and checks the “Task” form.

It identifies tasks where the “Status” is not “Completed” and the “Due Date” is in the past.
For each overdue task, it uses the Notify action to send an email to the assigned user and their manager.
It also uses Push Fields to update a “Follow-up Required” flag on the related Incident record.

This proactive alerting helps prevent tasks from slipping through the cracks and ensures that related incidents are not stalled.

Troubleshooting Cross Reference Notifications

When cross-reference notifications aren’t working as expected, here are some common areas to investigate:

Common Issues and Solutions

Incorrect Qualifications: The most frequent culprit. Ensure the qualification conditions for your Active Links, Filters, and Escalations are precise and accurately reflect the scenario you want to trigger. Test them thoroughly.
Execution Order Conflicts: Filters and Active Links have an execution order. If one workflow is supposed to trigger another, ensure it runs *before* the target workflow in the sequence.
Permissions Issues: The user context under which the workflow runs (especially for Filters and Escalations on the server) needs appropriate permissions to access and modify the target forms and records. Check the default and specific user permissions.
Disabled Workflows: It’s simple, but often overlooked – is the Active Link, Filter, or Escalation actually enabled?
Data Caching: AR System uses caching to improve performance. Sometimes, changes might not be immediately reflected. You might need to restart the AR System server or use the arsignal utility to force a reload of specific definitions. For example:
- arsignal -e serverName reloads escalation definitions.
- arsignal -r serverName recaches definitions from the database.
Understanding when to use different arsignal flags can be critical. For administrative operations that might interfere with users, consider if your server is in ‘Production cache mode’ (less interruption) or ‘Development cache mode’ (more locking).
Client vs. Server Execution: Remember Active Links run on the client and Filters/Escalations on the server. Ensure your workflow is designed to run in the correct environment for the action you need to perform. DDE and Run Macro, for instance, are client-side only (Active Links).
Logging: Enable detailed logging for your workflows. AR System’s logging capabilities can be invaluable for tracing the execution path and identifying where things go wrong. You can log workflow execution, filter activity, and more.
External System Connectivity: If your cross-reference involves external systems (via Run Process or Direct SQL), ensure network connectivity, correct credentials, and that the external system is operational and expecting the data/request.

Interview Relevance

Understanding cross-reference notifications is a fundamental aspect of AR System development and administration. In an interview, expect questions that test your practical knowledge:

Potential Interview Questions:

“Describe a scenario where you would use an Active Link to trigger a Filter.” (Hint: Active Link’s Service action)
“How would you ensure that when a high-priority Incident is created, a specific notification is sent to the on-call engineer, and a related task is automatically created?” (Tests knowledge of Filters, Push Fields, and potentially Run Process for complex notification logic.)
“What’s the difference between how a Filter acts on a request versus how an Escalation acts on requests?” (Focus on current vs. all matching requests and trigger types.)
“When would you choose ‘Commit Changes’ over ‘Run Process PERFORM-ACTION-APPLY’?” (Discuss logging and dynamic execution.)
“How can you use workflow to integrate BMC Remedy AR System with an external system for data synchronization?” (Focus on Run Process, Direct SQL, and potentially custom APIs.)
“You’ve created a Filter to update a related record, but it’s not working. What steps would you take to troubleshoot?” (Tests debugging methodology.)

Official Documentation and Resources

For the most accurate and detailed information, always refer to the official BMC documentation:

BMC Helix ITSM Documentation: https://docs.bmc.com/docs/helixitsm (Navigate to the relevant AR System or ITSM sections for workflow configuration details.)
BMC Helix Platform Documentation: https://docs.helixops.ai/ (Provides core platform capabilities and developer resources.)
General BMC Documentation: https://docs.bmc.com/ (Search for specific AR System workflow concepts.)

These resources offer in-depth guides, best practices, and the latest updates directly from BMC.

Conclusion

Cross-reference notifications are not just a technical feature; they are the backbone of intelligent, automated, and responsive business processes. By mastering the interplay between Active Links, Filters, and Escalations, and leveraging powerful actions like Push Fields and Run Process, you can build applications that proactively inform users, maintain data integrity, and seamlessly integrate with your broader IT ecosystem. Understanding these concepts is crucial for anyone working with BMC Remedy AR System or BMC Helix, ensuring that your systems work smarter, not just harder.