Demystifying the Approval Server in BMC Remedy AR System: A Deep Dive

In the intricate world of IT Service Management (ITSM) and enterprise application platforms, efficient workflow automation and robust security are paramount. BMC Remedy AR System, a long-standing leader in this space, provides a powerful framework for managing complex business processes. At the heart of many approval-driven workflows lies a critical component: the Approval Server. While it might not be the most visible part of the AR System architecture to an end-user, its role is indispensable in ensuring that changes, requests, and other critical actions are properly authorized before execution. This article will delve into the Approval Server, its place within the AR System architecture, and how it interacts with other components to enforce business policies.

Understanding the AR System Architecture: Where the Approval Server Fits In

To truly appreciate the Approval Server’s function, we first need to understand its context within the broader AR System architecture. The AR System is designed in a tiered model, each tier serving a distinct purpose. The Server tier is where the magic of workflow automation and data management happens. It’s the central nervous system of the AR System environment.

The Server tier is home to several key components, and the Approval Server is one of them. Think of it as a specialized application running alongside the core AR System server. This tier also houses other vital server-side applications like the Email Engine (for handling email notifications and processing) and the BMC Remedy Flashboards server (for data visualization). Furthermore, it hosts the C and Oracle Java plug-in servers, which provide extensions and custom functionalities through various plug-ins. Essentially, the Server tier is where the business logic is executed, data is processed, and interactions with the data tier (databases) are managed.

The AR System server itself is the orchestrator, controlling workflow processes and dictating how data is accessed and manipulated in the underlying databases. The Approval Server, as a server-side application, leverages this infrastructure to manage its own specific workflows – the approval processes.

What Exactly is the Approval Server?

The Approval Server is an integral part of BMC Remedy AR System designed to manage and enforce approval workflows. It acts as a central hub for defining, routing, and tracking approval requests. In essence, it automates the process of obtaining necessary sign-offs from designated individuals or groups before a specific action can proceed.

Consider a scenario where an IT department needs to implement a change to a critical server. This change typically requires authorization from multiple stakeholders: the IT manager, the application owner, and perhaps even a security officer. The Approval Server orchestrates this entire process. It:

• Defines Approval Chains: You can configure sequential or parallel approval steps, specifying who needs to approve at each stage.
• Routes Requests: It automatically sends approval requests to the designated approvers.
• Tracks Status: It keeps a meticulous record of whether an approval is pending, approved, rejected, or cancelled.
• Triggers Actions: Once all necessary approvals are obtained, it can trigger the next step in a workflow (e.g., proceeding with the change implementation).
• Manages Notifications: It can send out notifications to approvers about pending requests and to requesters about the status of their approvals.

Without the Approval Server, managing such multi-stakeholder approvals would be a manual, time-consuming, and error-prone process, often relying on emails, spreadsheets, or informal communication. The Approval Server brings structure, auditability, and efficiency to this critical business function.

Key Concepts: Groups, Permissions, and Access Control

The effectiveness of the Approval Server is deeply intertwined with how AR System manages users, groups, and their permissions. Understanding these concepts is crucial for configuring and troubleshooting approval workflows.

Understanding Group Types in AR System

AR System categorizes groups to manage user access and define roles. There are primarily two types:

1. Explicit Groups

These are groups to which users are manually assigned. When a user is a member of an explicit group, they inherit all the permissions granted to that group. Examples include ‘Administrators’, ‘Sub-Administrators’, ‘Customizers’, etc. These groups are typically defined for a specific AR System server. If you migrate your application to a new server, you might need to re-map or resolve permission conflicts if the explicit groups aren’t identically defined across servers.

2. Implicit Groups

These groups are based on specific user circumstances or conditions, rather than manual assignment. Users belong to implicit groups based on criteria such as the content of special fields within a request or their role within a process. Dynamic groups, where membership changes based on real-time conditions, are also a form of implicit group. Examples include ‘Public’, ‘Submitter’, ‘Assignee’, ‘Assignee Group’, etc.

The distinction between explicit and implicit groups is fundamental to how access control is implemented, which directly impacts who can perform actions and who can approve them.

Group Categories and Ranges

AR System assigns integer IDs to groups, which are categorized as follows:

• 0-1000: AR System groups and current AR System applications.
• 1000-13004 and 13007-14999: Regular and computed groups (typically explicit).
• 13005-13006: CMDB groups.
• 14999-59999: For future AR System applications.
• 60000-60999: For dynamic groups (implicit).

The category of a group (regular, computed, dynamic) often dictates whether it’s explicit or implicit, and this is crucial for understanding how membership and permissions are managed.

Overlay Groups: Controlling Customization and Development

While not directly related to Approval Server’s *runtime* function, Overlay Groups are a critical concept for developers and administrators managing customizations. They control a user’s ability to modify base AR System objects versus working solely on overlays (customizations). This is important for maintaining system integrity and ensuring smooth upgrades.

• Overlay Group set to 1: User is restricted to working on overlay and custom mode objects. In Developer Studio, they operate in Best Practice Customization mode.
• Overlay Group set to 0: User is restricted to working on base mode objects. In Developer Studio, they operate in Base Developer mode.
• Overlay Group cleared: No restrictions; the user can access and work on base, overlay, or custom objects.

This concept ensures that developers working on customizations don’t inadvertently alter core system functionality, which is vital for stability and future maintenance.

How the Approval Server Works: A Workflow Perspective

The Approval Server operates by integrating with AR System workflows, primarily using filters and active links to trigger and manage approval processes. When a business process reaches a point where an approval is required, the workflow is designed to interact with the Approval Server.

Workflows in AR System are the automated processes that drive business logic. They consist of components like Active Links (client-side actions), Filters (server-side actions triggered by form transactions), and Escalations (time-based actions). The Approval Server leverages these to:

• Initiate Approval Requests: A filter might detect a specific condition (e.g., a change request status is set to ‘Pending Approval’) and then call an Approval Server API or execute an Approval Server workflow to create a new approval record.
• Route Approval Tasks: Based on predefined rules, the Approval Server determines who the approvers are and assigns the approval task to them. This might involve looking up user information, group memberships, or specific fields on the request itself.
• Present Approval Options: Approvers receive notifications and can access a dedicated interface (often a form) to review the request and make their decision (Approve, Reject, etc.).
• Process Decisions: When an approver submits their decision, the Approval Server updates the status of the approval record.
• Continue Workflow: Based on the aggregate approval status (e.g., all required approvals received), the Approval Server can signal back to the originating workflow to proceed. If rejected, it might trigger a different set of actions, such as notifying the requester or closing the request.

Granular Overlays: Advanced Customization for Approval Workflows

As AR System environments evolve, customizations become a necessity. However, applying customizations directly to out-of-the-box (OOTB) objects can lead to significant reconciliation challenges during upgrades or patch application. This is where Granular Overlays come into play. They allow developers to modify specific sub-components of an object rather than the entire object, enabling more precise and manageable customizations.

For the Approval Server and its related forms/workflows, granular overlays offer flexibility:

• Additive Overlay (Extensions Overlay): Use this when you want to add new functionality or fields to an existing approval form or workflow without altering the original. During an upgrade, your additions are appended to the new base definition, minimizing conflicts.
• Overwrite Overlay: This approach completely replaces the origin object’s definition with your overlaid version. It’s suitable for scenarios where you need to remove existing functionality or significantly alter behavior. However, it requires careful management as it bypasses the origin object’s properties.
• No Overlay (Inheritance Overlay): This is the default. If you don’t explicitly modify a part of an object, it inherits properties from the origin object. This is crucial for OOTB components that you want to leave untouched, ensuring they automatically inherit changes from future system updates.

By judiciously using granular overlays, administrators and developers can customize approval workflows to meet specific business needs while significantly reducing the overhead of system maintenance and upgrades.

Practical Considerations and Best Practices

Implementing and managing Approval Server workflows effectively requires careful planning and adherence to best practices:

• Simplify Approval Chains: Overly complex approval processes can lead to delays and frustration. Design workflows that are as straightforward as possible while still meeting business requirements.
• Leverage Groups Effectively: Use explicit and implicit groups to manage approver assignments. This makes the system easier to administer and update.
• Clear Documentation: Document all approval workflows, including conditions, approvers, and expected outcomes. This is invaluable for troubleshooting and training.
• Test Thoroughly: Before deploying any approval workflow to production, test it rigorously with various scenarios, including approvals, rejections, and escalations.
• Audit Trails: Ensure that all approval actions are logged. The Approval Server typically provides this by default, but verify its integrity.
• Performance Monitoring: Keep an eye on the performance of your AR System server, as complex approval workflows can sometimes impact system responsiveness.
• Version Information: Always be aware of the version of AR System and its components you are using. You can find this information via the ‘application properties form’. This is crucial for compatibility and understanding feature sets.

Conclusion

The Approval Server is a powerhouse within the BMC Remedy AR System, enabling organizations to implement robust, auditable, and automated authorization processes. By understanding its role in the AR System’s server tier, its relationship with groups and permissions, and how it integrates with workflows, administrators and developers can effectively design, deploy, and manage critical approval mechanisms. As businesses continue to rely on efficient and secure processes, the Approval Server remains an indispensable tool for maintaining control and compliance in any AR System-based environment.