Page tree
Skip to end of metadata
Go to start of metadata

BMC provides a customization review process for its Helix ITSM customers. A Customization Review Board (CRB) is in place for this purpose. This process is not a mandatory requirement; customers may choose whether or not they want BMC to review their customization prior to development or promotion to the QA environment.

This topic describes the BMC Helix ITSM CRB process and related steps.


Opting out of customization review requires customer acceptance of the following criteria:

  • customer has followed BMC's published best practice design guidelines detailed on this page
  • the customization is saved in Best Practice mode
  • the customization contains no direct SQL calls
  • the customization uses field IDs within the customer range
  • the customization contains no unqualified searches

Best practices

When you are working on customizations, BMC requests that you follow these guidelines:

  • Request a design review as early as possible.
  • Carefully consider performance by table chunking (delaying table refresh until it is visible, and reading data from a form once to avoid multiple reads to the same form).
  • Check for missing workflow after an upgrade, because upgrades can delete objects.
  • Reduce the complexity of a customization by reducing code, simplifies reverification after an upgrade.
  • Consider having fewer languages and fewer custom fields, because additional languages increase the maintenance required.
  • Carefully review the requirement, and find ways of addressing it using combinations of configurations, which reduce the amount of customization and the upgrade risks.
  1. The customer's onboarding team designs and develops the proposed customizations. When creating customizations:

    Customers may...Customers may not...
    • Create overlay of forms, fields (including data, table, trim, and buttons), menus, views, active links and guides,
      filters and filter guides, escalations, applications, web services, and packing lists
    • Add new custom forms, fields, and workflows to enable required functionality
    • Hide existing non-mandatory fields
    • Mark an additional fields as required
    • Adjust appearance with skins
    • Adjust screens for branding (or use the standard Lifecycle Service request)

    For more information, see Customizing applications using overlays and custom objects.

    • Save in Base mode
    • Alter core functionality
    • Re-purpose fields even if they appear to be unused
    • Attempt to change a data type for a field
    • Use fields in reserved range
    • Perform direct SQL calls
    • Modify cascading style sheets
    • Leave any unqualified searches, for forms, workflow, table fields
    • Re-design what core application workflow does



  2. Customers submit customization review request(s) by completing and attaching the Customization Review Request form to a request in the support portal. Use the Request Something Else option within the portal. Additionally:

    • For Design Only requests, only the Customization Review Request form needs to be populated.

    • For As Developed requests, all required documentation, including but not limited to the review request form, .def files, BMC Remedy Developer Studio documentation, and applicable supporting files, should be submitted with the request.

      BMC recommends that customers compress (or zip) their attachments prior to submitting them. BMC will work with customers to provide alternative solutions for submitting attachments if attachment sizes exceed the file size limitations. 

  3. The submission creates a work order (WO) that is assigned to the CRB.
  4. The assigned CRB member sends an email to the requestor notifying the requestor that the WO has been assigned.

  5. The CRB member reviews the request and responds using one of the following options:

    • Approves the request and sends the notification of approval along with a PDF of the approved request to the requestor

    • Rejects the request and provide feedback to the requestor concerning the reason for rejection

    • Requests more information via email or sets up a call with the requester to re-review the request after clarifications are complete

  6. The CRB member attaches the PDF to the WO for future reference and linking to migration change requests.

    The PDF of the approved request contains the WO number that should be provided by the onboarding team when requesting migration of the customization to the QA and production environments using the change process.

  7. If the customizations are approved:

  • and the request is a Design Only request, then the project team develops the customizations, resubmits (step #2) for final CRB As Developed approvals, and references the previously approved design-only request WO number.
  • and the request was for an As Developed review, then the onboarding team updates their design document with this information and submits a change request for migration of the customization to the QA and production environments using the change process.


Pre-production customers who are still onboarding and have not yet gone live with their solution will normally create customizations in the development environment and submit a request to migrate the entire system to the QA and production environments. When the onboarding team submits a request for migration of the developed system to QA (executed using database copy), customizations developed in the development environment will be moved to QA for testing. The solution design document must be submitted along with the change request.