Mastering Access Control in Remedy: A Deep Dive into Permissions, Groups, and Overlays

In the intricate world of IT Service Management (ITSM) and particularly within platforms like BMC Remedy, robust access control is not just a feature; it’s the bedrock of security, compliance, and operational integrity. Think of it as the digital bouncer at the club, ensuring only the right people get into the right areas, with the right privileges. Without a well-defined access control strategy, your sensitive data is vulnerable, your workflows can be disrupted, and your system’s stability is compromised.

This article aims to demystify Remedy’s access control mechanisms. We’ll move beyond the jargon and provide practical, human-readable explanations of how permissions are managed, the crucial roles of groups and roles, the nuances of overlay groups, and the power of granular overlays. Whether you’re a seasoned Remedy administrator, an aspiring ITSM professional, or a developer looking to understand the impact of your code on user access, this guide is for you.

We’ll explore the “why” behind these controls, the “how” they operate, and crucially, how to troubleshoot common access-related issues. By the end, you’ll have a much clearer picture of how to design and maintain a secure and efficient access control framework within your Remedy environment.

The Foundation: Permission Groups and Roles

At its core, Remedy’s access control hinges on two primary objects: Permission Groups and Roles. These are your primary tools for dictating what users can and cannot do within the system. They work in tandem to define the boundaries of access at various levels:

• Forms: Controlling who can view, create, modify, or delete records within a specific form.
• Rows: This refers to record-level access. For instance, a user might be able to see all incidents, but only edit those they are assigned to.
• Columns: This is about field-level security. A user might be able to see an incident record but have certain sensitive fields (like salary information or internal notes) masked or hidden.

Understanding these objects is fundamental. A Role often represents a job function or a broad set of responsibilities (e.g., “IT Support Technician,” “System Administrator”). Permission Groups are more granular and are assigned to users to grant specific rights that align with their roles. A user typically belongs to multiple groups, each granting different permissions, which are then aggregated to form their overall access profile.

Understanding Group IDs: The Unique Identity

Every group in Remedy has a unique identifier, the Group ID. This integer ID is crucial for how Remedy internally recognizes and manages group memberships and permissions. The ranges assigned to these IDs are not arbitrary; they often signify the purpose or origin of the group. Knowing these ranges can help you quickly understand the nature of a group:

• 0-1000: Reserved for core AR System groups and current AR System applications. These are often system-managed.
• 1000-13004 and 13007-14999: This broad range is designated for regular and computed groups, which you’ll likely be creating and managing for your specific business processes.
• 13005-13006: Specifically allocated for CMDB (Configuration Management Database) groups, reflecting their specialized role.
• 14999-59999: This expansive range is reserved for future AR System applications, allowing for growth and extensibility.
• 60000-60999: This range is dedicated to dynamic groups. These are groups whose membership can change automatically based on certain conditions, offering a flexible way to manage access.

Real-world Example: If you see a group with an ID in the 60000s, you immediately know it’s likely a dynamic group, meaning its members aren’t manually assigned but rather determined by system logic. This is a key piece of information for troubleshooting access issues, as the conditions defining membership might need review.

Types of Groups: Explicit vs. Implicit

Groups in Remedy can be broadly categorized into two types: Explicit and Implicit. This distinction is vital for understanding how users gain membership and, consequently, their access rights.

Explicit Groups: The Hand-Assigned Members

Explicit groups are those where user membership is manually managed. An administrator directly assigns users to these groups via the User form. Once a user is a member of an explicit group, they automatically inherit all the permissions that have been granted to that group. This is the most straightforward way to grant access.

• Characteristics:
  • Direct user assignment required.
  • Permissions are inherited upon membership.
  • Defined for a specific AR System server.
• Considerations: When you move your Remedy application or configuration to a new server, you might encounter permission conflicts if the explicit groups are defined independently on each server. To mitigate this, consider using deployable applications. These leverage role-based permissions that can be mapped to different groups on different servers, offering a more portable and manageable approach.
• Examples: admin, sub-admin, customise, struct admin, struct sub-admin. These names often hint at the administrative or structural privileges the group confers.

Interview Relevance: An interviewer might ask about the difference between explicit and implicit groups and when you’d prefer one over the other. Emphasize the control and simplicity of explicit groups for defined roles, while highlighting the potential management overhead.

Implicit Groups: The Situationally Aware Members

Implicit groups are quite different. Users belong to these groups based on specific conditions or circumstances related to their user profile or the data they interact with. You don’t directly add users to implicit groups; rather, the system automatically determines their membership. This offers a dynamic and often more efficient way to manage access for broad categories of users.

• Characteristics:
  • Membership is determined by system conditions.
  • Users are not directly assigned.
  • Any dynamic groups you create are also considered implicit groups.
• Examples:
  • Arsystem: Often a default group for all users on the system.
  • public: Grants very basic, often read-only, access to all users.
  • assignee: A user automatically becomes a member when they are assigned a specific record (e.g., an incident).
  • submitter: A user might be implicitly added when they create a record.
  • assignee group: A user belongs if they are part of a team assigned to a record.

Practical Application: Imagine an implicit group like “Assigned to Ticket.” When a user is assigned an incident, they automatically become a member of this group, gaining permission to edit that specific incident without an administrator needing to intervene. This is highly efficient for workflow management.

Group Categories and Ranges: A Quick Reference

To solidify your understanding, here’s a summary of group categories and their typical ID ranges:

• Regular: Range 1000 – 14999. These are typically Explicit groups you create for specific user roles or functions.
• Computed: Range 1000 – 14999. Also Explicit, but their membership might be defined by a query or a more complex set of criteria, though still managed through direct assignment or role definitions.
• Dynamic: Range 60000 – 60999 (e.g., 60001, 60002, 60003). These are inherently Implicit groups where membership is determined by system logic and conditions.

Predefined Implicit and Explicit Groups

Remedy comes with several built-in groups that are essential to understand:

• public (ID 0): Implicit. Offers basic access, often read-only, to all users.
• Administrator (ID 1): Explicit. Grants full administrative privileges. Handle with extreme care!
• customize (ID 2): Explicit. Typically grants permissions to modify the application structure and forms.
• Submitter (ID 3): Implicit. Users are members when they submit a request.
• Assignee (ID 4): Implicit. Users are members when they are assigned a request.
• Sub Administrator (ID 5): Explicit. A less privileged administrator role.
• Assignee Group (ID 7): Implicit. Users are members if they belong to a group assigned to a request.
• Struct Admin (ID 8): Explicit. For structural administration of forms and fields.
• Sub Struct Admin (ID 9): Explicit. A lesser role for structural administration.

The Power of Overlay Groups: Controlling Customization Modes

This is where things get particularly interesting for developers and administrators working with customizations. Overlay Groups are a sophisticated feature that allows you to control the context in which users interact with system objects, particularly in relation to customizations and best practices.

The Overlay Group setting, available on the Group Information form, dictates whether a user’s group assignment restricts them to working with base (out-of-the-box) objects, overlay objects, or custom mode objects. This is primarily relevant when using tools like Developer Studio.

Overlay Group Field Settings:

• Overlay Group field set to 1: When a user is part of a group with this setting, they are restricted to working within the overlay and custom mode. In Developer Studio, this means they can only operate in Best Practice Customization mode. This is crucial for ensuring that customizations are applied in a way that respects the original system definition and facilitates easier upgrades.
• Overlay Group field set to 0: If a group has this setting, users are restricted to working with base mode objects. In Developer Studio, they can only operate in Base Developer mode. This is typically for users who should not be making any customizations and should only be viewing or interacting with the original, untouched system objects.
• Overlay Group set to (clear): When this field is left blank or cleared, the group provides no restrictions on access to base, overlay, or custom objects. Users in such groups can freely access and potentially modify any of these object types. This is often reserved for highly privileged administrators or developers who need full visibility and control.

Practical Use Case: Imagine a team of developers who are tasked with customizing the Incident Management application. You would assign them to a group with the Overlay Group field set to 1. This ensures they are working in the best practice overlay mode, which prevents them from directly altering core system objects and makes their customizations more maintainable and upgrade-friendly. Conversely, a support agent might be in a group with the field cleared or set to 0 if they should only ever see the base system.

Granular Overlays: Precision Customization

Building on the concept of overlays, Granular Overlays represent a significant advancement in how customizations are managed. Instead of overlaying an entire object, granular overlays allow you to selectively overlay specific subcomponents of an object. This means you can apply different overlay types to different parts of the same origin object.

The benefits are immense: you can modify only the aspects you need to, while inheriting the rest from the origin object. This drastically reduces the complexity of reconciliation during upgrades or patches, as you’re only dealing with the specific changes you’ve made, not the entire object.

Three Types of Granular Overlays:

1. Additive Overlay (or Extensions Overlay)

   This is your go-to for adding new functionality or data to an existing object without altering its core. If the origin object changes during an upgrade, your additions are appended to the new definition, ensuring your customizations remain relevant and don’t conflict with the core. Think of it as adding a new wing to a building – the original structure remains intact.

   Example: Adding a new custom field to the OOTB (Out-of-the-Box) Incident form to capture a specific piece of information relevant to your organization.

2. Overwrite Overlay

   With an overwrite overlay, the entire overlaid object takes precedence. The origin object is effectively ignored for that specific overlaid component. This is similar to the behavior in older, non-granular overlays. A common use case is when you need to completely replace a part of an object. For instance, removing permissions from an object might be achieved with an overwrite overlay.

   Example: If a certain default workflow on a form is causing issues, you might use an overwrite overlay to replace it entirely with your custom workflow.

3. No Overlay (or Inheritance Overlay)

   Despite its name, this is still technically an overlay. This is the default for all object components that you haven’t touched. If you don’t modify an OOTB object or its parts, they will inherit their properties during an upgrade. Inheritance overlays are used for object properties that should remain unchanged and simply follow the definition of the origin object.

   Example: For most fields on an OOTB form that you don’t need to customize, you would leave them as ‘No Overlay’ (Inheritance Overlay). They will automatically get any updates from BMC during a patch or upgrade.

View Related Complications: Controlling User Interface Access

Access control extends to how users interact with the system’s interface, particularly through Views. Views allow you to present different versions of a form to different users, tailoring the information and fields they see.

• View Field: Refers to the permissions associated with individual fields within a view.
• View Form: This is the overarching concept of a form presented via a specific view. The type of form being presented can be controlled.
• Form View: The ability to create a specific “view” of a form tailored for different users. This is a powerful way to simplify interfaces and focus users on relevant information.

Permissions can be set at the form and field level within these views, ensuring that users only see and interact with the data and controls relevant to their role. For instance, a service desk agent might see a simplified view of the Incident form, while a technical support specialist sees a more detailed view with additional fields and options.

Form Permission Scenarios: Putting it into Practice

Let’s look at a practical scenario to illustrate how form and field permissions can be applied:

Permissions and Menus: A Nuance

A common question arises: can you directly grant permissions to menus in Remedy? The answer is a bit nuanced:

You cannot directly give permissions to menus themselves. However, the permissions associated with the character field to which a menu is attached will be applied for the corresponding menu items. If a user doesn’t have access to the underlying field that a menu item uses, they won’t be able to use that menu item, even if the menu itself appears to be available.

Analogy: Think of the menu as a set of buttons. The character field is the underlying mechanism that determines if clicking that button actually does anything. If the mechanism is broken or locked, the button press has no effect.

Efficient Permission Management: Applying to Multiple Forms

Manually assigning permissions to forms one by one can be a tedious and error-prone process, especially when dealing with a large number of forms. Remedy provides a more efficient way to manage this:

1. Identify the Group: First, determine the group to which you need to assign form permissions.
2. Access Group Permissions: Right-click on the group name in the relevant form (e.g., Groups form).
3. Assign Permissions: Select the option to assign permissions.
4. Add Forms: You will then be presented with an interface to add the desired forms to the group’s permissions. You can typically select multiple forms at once.

This bulk assignment feature is a lifesaver for administrators, ensuring consistency and saving significant time.

Help Text Visibility: A User Experience Detail

Even seemingly minor details like how help text is displayed can be influenced by user context and permissions:

• Login by Demo User: When logged in as the Demo user (often used for initial setup or testing), the help text will display the Field Name (label Name); Field Id; and the Help Text value. This provides comprehensive information for debugging and verification.
• Login by Other Registered User: For any other registered user, only the Help Text value itself will be displayed. However, if there is no help text value defined, the system will fall back to displaying the field’s description, which includes details like its symbol, keyword, and length.

This difference is designed to provide developers and administrators (like the Demo user) with more technical detail, while end-users see a cleaner, more user-friendly explanation.

Troubleshooting Common Access Control Issues

Access control problems can be frustrating. Here are some common scenarios and how to approach them:

Interview Relevance: Key Concepts to Know

Understanding access control in Remedy is crucial for many ITSM roles. Here are some topics that frequently come up in interviews:

Conclusion

Access control in Remedy is a multifaceted yet essential component of system management. By understanding the interplay between permission groups, roles, group IDs, explicit and implicit groups, and the sophisticated control offered by overlay groups and granular overlays, you can build a secure, efficient, and maintainable ITSM environment.

Remember that access control isn’t a “set it and forget it” affair. Regular audits, a clear understanding of user roles, and a proactive approach to managing customizations are key to ensuring your Remedy system remains both functional and secure. Mastering these concepts will not only make you a more effective administrator or developer but will also make you a valuable asset in any ITSM team.