Demystifying Roles & Permissions in BMC Remedy AR System

In the intricate world of IT Service Management (ITSM), the ability to control who can see, do, and access what is paramount. BMC Remedy Action Request System (ARS), often simply referred to as Remedy, is a powerful platform that underpins many critical business processes. At its core, managing access and defining user capabilities hinges on a robust system of roles and permissions. This article dives deep into how Remedy handles these crucial aspects, providing practical insights for administrators, developers, and anyone looking to master its access control mechanisms.

Before we get into the nitty-gritty of roles and permissions, let’s clear up a common point of confusion. The terms “Remedy” and “Action Request System” are often used interchangeably. To be precise, BMC Remedy Action Request System is the full, current name of the application. It originated with Remedy Corporation, was later acquired by BMC Software. Understanding this historical context helps appreciate the platform’s evolution.

The AR System architecture is a layered approach designed for scalability and modularity:

• Client Tier: This is where user interfaces and administration tools reside. Think of the BMC Remedy User tool, Developer Studio, or even web browsers accessing the system via the Mid Tier.
• Mid Tier: Acts as a crucial bridge, translating client requests into a format the Server Tier understands and vice-versa. It’s essential for web-based access.
• Server Tier: The brain of the operation. It manages workflow processes, interacts with the data tier, and hosts critical components like the Approval Server and Email Engine.
• Data Tier: Where all your data lives – typically database servers like SQL Server, Oracle, or DB2.

Understanding the Pillars of Access Control: Groups

In Remedy AR System, the primary mechanism for managing permissions is through Groups. Think of groups as containers that hold users and are then assigned specific access rights to various system objects (forms, fields, etc.).

Types of Groups

Remedy distinguishes between two fundamental types of groups:

Explicit Groups

These are groups that you, as an administrator, manually create and to which you assign users directly. When a user is a member of an explicit group, they inherit all the permissions granted to that group. For instance, you might have an ‘IT Support’ explicit group. Anyone added to this group automatically gains access to ITSM-related forms and data.

Key Characteristics:

• Manual Assignment: Users are explicitly added to these groups.
• Server-Specific: Explicit groups are typically defined for a particular AR System server. If you move objects to a new server, you might need to re-establish these group mappings.
• Role-Based: They are often used to implement roles like ‘admin’, ‘sub-admin’, ‘customizer’, or ‘struct admin’.

Real-world Analogy: Imagine a company club. You have to actively sign up and be approved to join. Once in, you get all the club’s benefits.

Implicit Groups

Implicit groups are more dynamic. Users automatically become members of these groups based on specific conditions or circumstances, rather than direct manual assignment. The system determines membership based on data within requests or special user attributes.

Key Characteristics:

• Condition-Based: Membership is determined by system logic and data.
• Automatic: Users don’t need to be manually added; they are assigned based on predefined rules.
• Dynamic: Membership can change as the underlying data or user context changes.
• Examples: ‘Submitter’ (the person who created the request), ‘Assignee’ (the person assigned to the request), ‘Public’ (generally available to all logged-in users), ‘Arsystem’ (internal system group).

Real-world Analogy: Think of being automatically put into a “mailing list” for your department once your HR record shows you belong to that department. You didn’t have to ask; it happened based on a rule.

Group Categories and Ranges

The AR System uses specific integer ranges to categorize groups, helping to distinguish their purpose and potential usage:

• 0-1000: Primarily for AR System internal groups and core applications.
• 1000-14999: This broad range is common for Regular and Computed groups. These are typically explicit groups used for general access control.
• 13005-13006: Reserved for CMDB (Configuration Management Database) specific groups.
• 14999-59999: Designated for future AR System applications, providing room for expansion.
• 60000-60999: Reserved for Dynamic groups. These are often implicit groups where the system automatically assigns membership. Examples include specific IDs for dynamic groups like 60001, 60002, 60003.

Group ID to Type Mapping (Common Examples)

Here’s a helpful breakdown of some common group IDs and their implicit/explicit nature:

• Public (0): Implicit – Generally accessible to all logged-in users.
• Administrator (1): Explicit – Full system access.
• Customize (2): Explicit – For customizing forms and applications.
• Submitter (3): Implicit – Refers to the creator of a request.
• Assignee (4): Implicit – Refers to the user currently assigned to a request.
• Sub Administrator (5): Explicit – A more restricted administrative role.
• Assignee Group (7): Implicit – Refers to a group assigned to a request.
• Struct Admin (8): Explicit – Structural administrator, often for form structures.
• Sub Struct Admin (9): Explicit – A subordinate structural administrator.

Overlay Groups: Mastering Customization and Upgrades

One of the most critical aspects of maintaining and customizing Remedy is managing changes effectively, especially during upgrades. Overlay Groups are a powerful feature designed to facilitate this by allowing you to define different levels of access and modification rights for users working with customized objects.

When you assign a user to a group with specific Overlay Group settings, you dictate their interaction with base system objects and their customizations:

• Overlay Group field set to 1: Users in this group are restricted to working only on overlay and custom mode objects. In BMC Remedy Developer Studio, they will primarily operate in Best Practice Customization mode. This is ideal for developers who are building new features or modifying existing ones without directly touching the original, out-of-the-box objects.
• Overlay Group field set to 0: Users in this group are restricted to working only on base mode objects. In Developer Studio, they will work in Base Developer mode. This is useful for administrators or support staff who need to view or troubleshoot the original system without accidentally altering it.
• Overlay Group field set to (clear): This is the most permissive setting. Users in such a group face no restrictions and can work with base objects, overlay objects, and custom objects freely. This is typically reserved for highly trusted administrators.

Types of Granular Overlays

Granular overlays allow you to apply different overlay types to specific subcomponents of an object. This provides finer control and minimizes conflicts during upgrades.

1. Additive Overlay (Extensions Overlay): Used to add custom information or functionality to an existing object without altering the original definition. If the origin object changes during an upgrade, your additions are appended. Think of adding extra fields or logic.
2. Overwrite Overlay: The entire overlaid object replaces the origin object. Any changes made in the origin object are ignored. This is useful for scenarios where you need to completely replace a component, such as removing inherited permissions.
3. No Overlay (Inheritance Overlay): This is the default. If you don’t explicitly create an overlay for a part of an object, it will inherit its properties directly from the origin object. This ensures that your customizations only apply where you intend them to, while unchanged parts automatically inherit from the latest version.

Permissions: What Can Users Actually Do?

While groups define who has access, permissions define what they can access and how. Remedy offers granular control over permissions at various levels:

Form Permissions

This is the most fundamental level. You can grant users (via their groups) the ability to:

• View: See the form and its data.
• Change: Modify existing records on the form.
• Submit: Create new records on the form.
• Delete: Remove records from the form.

These are often managed by assigning groups to specific permissions on a form’s properties.

Field Permissions

Within a form, you can further refine access to individual fields. This is crucial for protecting sensitive data or controlling specific actions:

• View Access: Allows users to see the field’s data.
• Change Access: Allows users to modify the field’s data.

You can assign permissions to fields based on groups, ensuring that only authorized users can view or edit certain pieces of information.

Workflow Permissions

Active Links, Filters, and Escalations also have associated permissions. This controls which groups can view, modify, or create these workflow objects. This is generally managed within Developer Studio when configuring these components.

Key AR System Components Related to Permissions

Several AR System objects and concepts tie directly into how permissions are managed:

Forms

Forms are the fundamental building blocks for data presentation and interaction in AR System. Their type and associated permissions are crucial:

• Regular Form (Type 1): The standard form type.
• Join Form (Type 2): Combines data from multiple forms. Permissions need to be managed across joined forms. BMC recommends joining up to 6 forms for optimal performance.
• View Form (Type 3): A read-only view of another form or a join form.
• Display Form (Type 4): Similar to View Form, often used for presentation.
• Vendor Form (Type 5): Allows AR System to access external data sources. Permissions here might involve controlling access to the underlying external system.

Menus

Menus (attached to character fields) provide a selection of options. While you cannot directly assign permissions to menus themselves, the permissions of the character field to which the menu is attached will govern access. For example, if a user cannot see or change a character field, they won’t be able to access the menu attached to it.

Menus have refresh modes that determine how often their content is updated:

• On Connect: Refreshes when the user connects to the form.
• On Open: Refreshes every time the menu is opened (can impact performance).
• On 15 Minute Interval: Balances freshness with performance.

Character menus are static and not refreshed.

Core Fields and Their Significance

Certain fields are fundamental to tracking and managing requests, and their permissions are often implicitly managed by the system:

• Request ID (1): The unique identifier for each request.
• Submitter (2): The user who created the request.
• Create Date (3): When the request was created.
• Assigned To (4): The user currently responsible for the request.
• Last Modified By (5): The last user who modified the request.
• Modified Date (6): When the request was last modified.
• Status (7): The current stage of the request (e.g., New, Assigned, Resolved, Closed).
• SD (8): Likely stands for ‘Short Description’ or a similar summary field.
• Status History (Hidden – 15): Tracks changes to the Status field.

Workflows and Access Control

Workflows in AR System (Active Links, Filters, Escalations) are the engines that automate processes. Their interaction with permissions is key to ensuring secure and controlled operations.

Workflows: The Automation Engines

• Active Links: Triggered by client-side user operations (e.g., clicking a button, changing a field). They operate in the user’s client session.
• Filters: Execute on the server-side in response to form transactions (submit, modify, delete). They are the workhorses for data manipulation and workflow logic.
• Escalations: Periodically check the database for requests that meet specific criteria and trigger actions. Ideal for time-based events (e.g., overdue tasks).

When designing workflows, consider:

• Permissions for Workflow Objects: Ensure that only authorized groups can modify or even view these critical automation components.
• Workflow Logic and Permissions: Workflows often check user permissions before executing certain actions. For example, a filter might verify if the current user has “Change” permission on a form before allowing a status update.

License Management and Login Scenarios

While not strictly “roles and permissions” in the access control sense, license types directly impact user access and system availability. Understanding this is vital for effective administration.

Fixed vs. Floating Licenses

• Fixed Licenses: These are permanently assigned to a specific user. That user can log in and use their license whenever they want, regardless of whether other users are logged in.
• Floating Licenses: These are shared among a pool of users. When a user needs to log in and use a floating license, one is “checked out” from the pool. When they log out, it’s returned. This is more cost-effective for organizations with shift work or where not everyone needs 24/7 dedicated access.

Scenario: If you have 5 fixed and 5 floating licenses, can more than 10 users log in?

Answer: Yes, users can log in, but only 10 can actively use licensed functionality simultaneously. Once the fixed licenses are in use, additional users attempting to use functionality requiring a fixed license will be unable to proceed. For floating licenses, users will have to wait for a license to become available. If no licenses are available, some license types might allow login as a “Read User” with limited capabilities.

Database and Configuration Details

Understanding how Remedy stores its configuration and data is key to effective administration and troubleshooting.

Database Configurations

The choice of operating system and database for your AR System installation is critical and depends on your existing infrastructure and expertise:

• Most Popular: Windows / SQL Server, Windows / Oracle, Solaris / Oracle, HP-UX / Oracle, AIX / DB2, AIX / Oracle, Red Hat / Oracle.
• Large Customers: Tend to favor UNIX-based systems for their robustness.
• Mid to Smaller Companies: Often opt for Windows / SQL Server for ease of administration.

Key Configuration Files

• ar.cfg (Windows) / ar.conf (Unix): This is the primary configuration file for the AR System server. It stores various server settings, and yes, passwords can be saved in this file in an encrypted format (though direct plaintext passwords are a major security risk).

Database Table Mappings (Common Examples)

• Active Links: `dbo.actlink` (with `_` appended for actions)
• Filters: `dbo.filter` (with `_` appended for actions)
• Escalations: `dbo.escalation`
• Menus: `dbo.char_menu`
• Group Information: `dbo.group`
• User Information: `dbo.arschema` (This is a fundamental schema table, not just for user info).

Installation Sequence of Core Tables

When AR System is installed, these core control tables are created in a specific order:

1. `control`
2. `controlRecordIds`
3. `arschema`
4. `schema_index`
5. `schema_group_ids`

Dates, Times, and Data Storage

Remedy’s handling of dates and times is precise and efficient.

Timestamp Representation

AR System stores all date/time values as the integer number of seconds since 00:00:00 GMT on January 1, 1970 (the Unix Epoch). This allows for efficient storage and calculation.

Date Range Limitations

This integer representation means that dates can be stored accurately from January 1, 1970, through January 18, 2038. Dates beyond this range may lead to overflow errors.

Diary Fields vs. Character Fields

A common distinction to understand:

• Character Fields: Can hold alphanumeric characters. Data in these fields can be overwritten. They can have menus attached and are often used for general text input.
• Diary Fields: Designed for logging information. When new data is added, it’s appended along with a timestamp and the username. This preserves the history of entries. Note: Web reports generally do not support diary fields or attachment pools.

Attachment Handling

Remedy provides robust capabilities for managing file attachments.

• Attachment Pool (Data Type): A field designed to hold multiple attachments.
• Attachment Field (Data Type): A field designed to hold a single attachment.

When attachments are stored, AR System typically creates tables like `BSchema_id` (which stores file path, original size, compressed size) and `Battachpoolid` (which links request IDs to binary data). The maximum size of attachments can be configured.

Menus and Their Management

Menus offer structured choices for users.

• Static Menus: Predefined lists of options.
• Dynamic Menus: Content is retrieved from sources like SQL queries or form data dictionaries.

When you delete a menu or the field associated with it, the menu definition itself in the database tables (like `dbo.char_menu`) is not automatically deleted. You would need to manually clean this up if required.

Developer Studio and Customization Best Practices

BMC Remedy Developer Studio is the primary tool for developing and customizing AR System applications. Understanding its interaction with permissions and overlays is key.

• Overlay Groups in Developer Studio: As discussed, setting Overlay Group permissions in the Group form dictates whether users can modify base objects or only work within overlay/custom modes.
• Best Practice Customization Mode: When using an Overlay Group set to ‘1’, Developer Studio operates in this mode, guiding you to make changes using overlays rather than directly altering OOTB objects.
• Base Developer Mode: For groups set to ‘0’, users work in this mode, primarily interacting with base objects.

Troubleshooting Common Permission Issues

Permission problems are frequent and can be tricky to diagnose. Here are some common scenarios and how to approach them:

• “You do not have the required license or permissions to perform this action.” This is the classic error.
  • Check Licenses: Ensure the user has an appropriate license type (Fixed, Floating, Read).
  • Check Group Membership: Verify the user is assigned to the correct groups that have been granted permissions.
  • Check Form Permissions: Review the ‘Permissions’ tab on the form itself to see which groups have View, Change, Submit, or Delete rights.
  • Check Field Permissions: If the issue is with a specific field, inspect the ‘Permissions’ tab on the field’s properties.
  • Check Active Links/Filters: Sometimes workflow can enforce its own access control checks.
• User sees fields/forms they shouldn’t: This indicates over-permissioning. Review group assignments and permission settings to restrict access.
• User cannot save changes: This usually points to missing ‘Change’ or ‘Submit’ permissions on the form or field.
• Cannot access Developer Studio: Ensure the user is part of a group with appropriate developer permissions (e.g., ‘Struct Admin’, ‘Customize’, or a custom role with Developer Studio access). Often, being added to the ‘struct sub-admin’ group is required for basic Developer Studio access.

Final Thoughts

Mastering roles and permissions in BMC Remedy AR System is not just about clicking buttons; it’s about understanding the intricate web of groups, permissions, overlays, and workflows that safeguard your ITSM processes. By diligently applying these concepts, you can ensure a secure, efficient, and maintainable AR System environment.

Remember, consistency in your naming conventions for groups and a clear strategy for customization using overlays will save you immense headaches during upgrades and ongoing maintenance. The platform’s power lies not only in its automation capabilities but also in its granular control over who can do what.