Share This:

BMC Remedy AR System Server version 7.6.04 introduced overlay functionality to separate out of the box objects from customizations. The Overlay is the substitute of original object which can be modified without affecting origin objects. During upgrades or when patches are applied, the out of the box objects are modified and customizations are preserved in the overlay.

BMC Remedy 8.x version introduces further enhancements to overlays and it’s tagged as ‘Granular Overlay’. Let’s get to know more about it and how to use it effectively.

First, a quick overview of the Overlay:

When we create an overlay, it copies the definition of the object but does not create a new copy of database tables or columns - that’s why the same data is available through the origin object or the overlay.

Applications use overlay objects in place of the origin objects. For example, if a filter is used during an operation and AR System server detects the filter has an overlay; the server executes the overlay filter instead of the origin filter. During upgrades, AR System installation ignores overlays and only the out of the box objects are modified so new functionality is added without impacting customizations.

Remedy Developer Studio has two modes to view origin objects vs overlaid objects. The following picture shows how to switch between these modes:
  1. Best Practice Customization Mode (BPC Mode)
  2. Base Development Mode
A new object created in BPC mode can be modified without creating a overlay as it is a custom object.  When new forms or fields are created in BPC mode, Developer Studio appends the ‘__c’ string to the default name of the object. For example: ‘Character Field__c’

Let’s get to the granular portion of Overlay:

Now, a further enhancement to overlay functionality is Granular Overlays which means you can choose subcomponents of an object and apply different overlay types to them. Granular overlays allow you to modify only some aspects of an origin object and inherit other aspects from the origin object.

Using granular overlays minimizes how much you must reconcile after you upgrade or apply patch.

Now, as described below we have three types of granular overlay.

Additive Overlay OR Extensions Overlay:  It is used when you would like to add customized information to what is already available in the origin object. If the origin object changes during an upgrade the additions are appended to whatever is in the new origin definition.

Overwrite overlay: The entire overlaid object is used and the origin object is ignored. This is the same behavior as earlier versions – in non-granular overlays.  For example, removing permissions from an object is a case where an overwrite overlay would be appropriate.

No Overlay OR Inheritance Overlay: Though its name is ‘No Overlay’, it is still technically an overlay. This type of overlay is the default for all types of objects and their parts. If you do not touch the out of the box object or its part, it would take inherit its properties during upgrade.  Inheritance overlays are used for the object properties which should be inherited from the origin object with no changes.

You may want to review our video clip on Granular Overlays to understand the different kinds of overlays @ Please click here

Now, let’s work through an example of how to use granular overlays:


The details of the customization are not important here except to illustrate an example of different workflow changes that may be required and what kind of overlays to use for each.

Requirement example 1 (Make use of Additive and No Overlay): -
The People form (CTM:People) has fields to indicate VIP and Sensitive contents. The customization requirement is to update these field values via integration with Active Directory, and remove permissions from the fields so only restricted groups can update them.

Scope of workflow changes:
  • Create a custom vendor form to display VIP and Sensitive attribute values from Active Directory
  • Create a new custom filter and escalation to push the data to the People form
  • Remove permissions from out of box fields on the CTM:People form

Using overlays to implement the customization:
Use BPC mode in Remedy Developer Studio to implement the customization. Access Form Properties on the Definitions tab in Form Editor, as shown above and mark them as described below:

  • Remove ‘Public’ permission for the fields. Create a new permission group and add it to the fields using ‘Overwrite Overlay’.  Before an upgrade or applying a patch, I would be able to determine if this is one of the objects updated during the installation and reconcile the customizations implemented in the overlay with the product changes. I would not use the Additive Overlay because it would replace out of the box permission after upgrade.
  • I would not touch the rest of the objects or sections of CTM:People form. Looking at the scenario I would not modify out of the box fields on the form. Protecting other parts or grains as it is, and hence that should be type as ‘No Overlay’. It would make easy for me during upgrade as I don’t have to reconcile unmodified sections.

Requirement example 2 (Make use of Overwrite Overlay): 
Create service request using advance interface form

Scope of the workflow changes:
  • Create custom form for Advanced Service Request
  • Modify existing workflows

Using overlays to implement the customization:
  • Create custom forms as per new requirement in service request. Add newly created custom forms in to the out of the box workflows (Active Links, AL Guide and Filter Guide) with overlay type as “Additive Overlay”.


Granular Overlay Utilities:In Developer studio, open objects and highlight one or more objects. Right click and select Analyze Overlay to get options of utilities.

•Object Granularity Level: - It would compare the selected object with the origin object and report its suggestion on the granular overlay.
•Unmodified Fields in View: - We can see all of the fields on this form that are in the view overlay, but that are never modified

Imparting some useful links:

Please find information on “Upgrade applications and adjust customizations with new overlays” @

For Information on “Adjusting customizations when upgrading”

We can identify what addition has been made to such granular overlay section, by looking at the overlay information in the migration. Overlay details in Migrator difference report shows which component of which object has set to overwrite or no overlay. @

I would suggest:

Please do not add overlays to AR System and CMDB forms, because they are back-end data forms.  For CMDB forms, make changes in the Class Manager. CMDB knows how to retain customizations if they are made through the Class Manager. See system objects that might be overwritten during an upgrade for specific AR System objects.

This post discusses how to use granular overlays to make customizations to the ITSM applications, so you can upgrade to later versions to get defect fixes and feature additions without overwriting your customizations. It is good practice to use Best Practice Mode when making changes and to use Inherit or Additive overlays whenever possible to ensure your customizations have the minimal impact on the out of box application. We also described how to use the product and documentation to identify overwrite overlays, compare against items that are updated by an upgrade, and identify cases where your custom workflow should be updated.

In my experience, the granular overlays feature makes the upgrade process more manageable and removes a major obstacle in both customizing and in upgrading. I would like to know your experience, please add comments below.