Click Submit New Case on the BMC Support Central Case Management quick access pane to create a case. For detailed information, see Create a new case.

Watch the YouTube video about how to create a support case(2:49s)

BMC Electronic Product Distribution (EPD) is the main interface for downloading products, patches, and updates fromBMC.com. You must be logged into Support Central to access the EPD. Under the Downloads & Products, click Downloads. 

For detailed information, see Use the Product Downloads tool.

Watch the YouTube video for an overview of BMC Electronic Product Distribution (6:29)

Because BMC Helix services are cloud-based, customers can connect to them via any supported web browser. BMC is fully responsible for the availability of the services.

For detailed information, see Service levels and support hours.

While we do our best to design our Support Central resources so you can easily track down the answers to your questions, you can always reach out to our Customer Care team directly, for one-on-one support.

For detailed information, see Contact BMC.

Lifecycle Requests are operations that customers can submit as part of their BMC Helix subscription ranging from configuration updates, administrative set up, among other activities. These may be requested at any time throughout your service term and the availability of Lifecycle Requests may differ depending on your lifecycle stage (ie. Onboarding, Live) and your data center.   

For detailed information, see Lifecycle-Requests. For any Lifecycle Requests you may not see in the available options, please submit a Change Request (RFC) or Support Case.     

Watch the YouTube video to learn how to create a Lifecycle Request (4:20s)

You use the request for change (RFC) process to request changes to your environments — for example, to request promotions from the development/tailoring environment to the QA environment, and from the QA environment to the production environment. 

The RFC form lists all of the information that the change submitter (BMC SaaS Operations, or customer or project teams, on behalf of a customer) must provide to fulfill the change request. It requires enough information in order to effectively plan, manage, track, and fulfill an RFC. 

For detailed information, see Request-for-Change-process. 

Customer-authorized change approvers will be contacted via email by BMC SaaS Operations to request authorization and in-application on Support Central > Case Management under Approve a Change.  

Watch the YouTube video to learn how to approve a RFC (7.11)

The BMC SaaS Operations team performs regular application and infrastructure maintenance to your non-production and production environments. 

For detailed information, see Maintenance-windows.

BMC has a highly skilled team dedicated to managing and executing service update projects. The Helix services are kept up to date with the latest enhancements, fixes, and features as each service reach production readiness.

For detailed information, see BMC-Helix-Update-policy.

BMC provides services to hundreds of customers worldwide. These customers are across multiple industries and include many global customers with complex security, compliance, integration, and performance requirements.

Yes. BMC SaaS Operations monitors all customer environments. For more information, see System-monitoring. 

In Support Central, select the Service Status Dashboard option within the Case Management view.

BMC frequently resolves potential issues before they are customer-impacting. Based on incident severity, issues are addressed so as to provide restoration of the service as soon as possible. If you are experiencing an issue, promptly submit an incident to BMC Support. For more information, see the BMC-Helix-Incident-Response-policy. 

Versioning has been updated to include four major releases per year based on the seasons: 

• year.Winter (also known as year.1)
• year.Spring (also known as year.2)
• year.Summer (also known as year.3)
• year.Fall (also known as year.4)

A minor release that occurs between major releases will be called major-release.minor-release. For example, 22.2.01 would represent the first minor release after the spring release. 

For more information, see BMC-Helix-Update-policy.

Yes. You will have an opportunity in user acceptance testing to determine if those customizations still make sense. If they do not, they can be disabled so that the out-of-the-box workflow is executed instead.  For more information, see BMC-Helix-ITSM-Customization-policy.

BMC SaaS Operations supports minor adjustments made to customizations as a part of the service update process. If a significant change to logic is required, you should work with BMC SaaS Operations to understand the impact. If a major change to the customized code is required, you can choose to implement it on an "as-is" basis, implement a small workaround, or disable the customized code. Any major changes to the customization can then be scheduled for implementation after the service update through the regular change control process. For more information, see BMC-Helix-Update-policy.

At present, BMC Helix does not support 2-way SSL (also known as mutual TLS, client certificate authentication) for the inbound REST API/ Web Service traffic. However, we are looking to provide this option in the near future.

The SMTP incoming and delivery servers are BMC-managed infrastructure. The only connectivity to external cloud allowed is Microsoft Exchange Web Services (EWS). Other external connections are considered to be prohibited. For the avoidance of doubt, the external cloud and on-premises infrastructure configuration, administrative settings, servers, logs, and your network environments are managed outside of BMC, therefore out of scope for BMC Support. 

 Custom headers are not supported.

The customer is responsible for obtaining and managing the client certificates for third-party integrations with the BMC Helix ITSM. The BMC SaaS Operations team will assist with the certificate installation into their BMC Helix environment.

For more information on obtaining and managing the client certificates, seeKB Article 000251885.

Masquerading outbound emails with a sender address on behalf of the customer’s domain or third-party network is allowed only if the following conditions are met:

• The customer or third-party must take steps to trust the BMC Helix SMTP servers to send emails on their behalf. This includes adding our SMTP server public IP addresses to their published Sender Policy Framework (SPF) record. 
• The customer or third-party must modify their email filters to accept the masqueraded email from BMC SMTP servers without flagging it as unsolicited.
• The customer or third-party must provide evidence showing the above steps have been addressed.

The following table lists the hosts for each region that need to be added to the SPF record. You only need to add the location that corresponds to your service location in the SPF record.

For more information, see Planning-email-integration-with-BMC-Helix-services.

Next Action: Raise a support case by providing the evidence that the above conditions are met. BMC will approve the masquerading configuration and move forward with the implementation.

Access to the mid-tier configuration page is restricted for security reasons. However, the customer can perform the cache flush on non-production using alternative steps.

For more information, seeBMC Helix ITSM Administrator Permissions policy.

Use this procedure if you need to encrypt a file within BMC Helix ITSM and transfer it over the SFTP to be used later. For example, you can encrypt a report extracted after processing data by an AI job. 

The following steps describe the process of decrypting a GPG-encrypted file in BMC Helix ITSM:

1. Generate a key using a GPG program.
   The steps shown in the following screenshot demonstrates how to generate a key using GPG in Linux. Follow your organization's security guidelines to meet the security requirements.
   

1. Export the public key using the GPG command.
   Example:
   gpg --output GPGKey_public.asc --armor --export GPGKey
2. Raise a support case to install the public key into your environment. The BMC Helix Operations team will upload the key into the AR System File form, ensuring that the key is uploaded every time the server is restarted.
   
   It is your responsibility to track the key expiry and renewal process. In the event that the key expires and needs to be regenerated, you must submit a support case to upload the renewed key.
3. Design an Atrium Integrator job that uses the Shell Script step to encrypt the GPG-encrypted file.
   A sample job is shown:
   
   The following screenshot shows a sample script (TrustKey Shell Script step):
   
   The following screen shot shows a sample script (Encrypt Shell Script step):
   

The encrypted file is available under the directory /opt/bmc/ars/data/FromOnDemand as per the sample script above. The sample script uses hard coded values. Replace with the variable as per the requirement.

If you need to upload an encrypted file to the BMC Helix ITSM, you can encrypt the file using a GPG program and then process it in BMC Helix environments.

The following steps describe the process of decrypting a GPG-encrypted file in BMC Helix ITSM:

1. Generate a key using a GPG program.
   The steps shown in the following screenshot demonstrates how to generate a key using GPG in Linux. Follow your organization's security guidelines to meet the security requirements.
   

1. Export the Private key using the following command.
   For example:
   

1. Raise a support case to install the private key into your environment. The BMC Helix Operations team will upload the key into the AR System File form, ensuring that the key is uploaded every time the server is restarted.
   
   It is your responsibility to track the key expiry and renewal process. In the event that the key expires and needs to be regenerated, you must submit a support case to upload the renewed key.
2. Design an Atrium Integrator job to download the GPG-encrypted file from the BMC Helix SFTP server to the local AR System directory. Use the Get a file with SFTP step to upload the file.
   File Path to be used to download the GPG-encrypted file: /opt/bmc/ars/data/ToOnDemand
3. Design an Atrium Integrator job that uses the Shell step to decrypt the GPG-encrypted file. 
   A sample job is shown:
   
   
   

The following screenshot shows a sample script:

Important: In GPG command, the escape character for special characters is the backslash "\". If you need to use a special character in a command or in a passphrase, you can use the backslash to escape it and prevent it from being interpreted as a command or separator.

If you have a CSM  assigned to your account, work with them to schedule your service update. After the update is scheduled, you receive an email notification at least 7 days before your DEV upgrade date.  

If you do not have an assigned CSM and your environment is not compliant with the Service Update policy,​​​​​ the BMC Success team (success@bmc.com) emails you with the scheduled service update dates.

You receive notifications:

• 30 days before the DEV upgrade date
• 15 days before the DEV upgrade date, and 
• 7 days before the DEV upgrade date

A Zero Downtime (ZDT) service update is an in‑place upgrade that does not impact end users.

The production environment remains accessible throughout the update. End users can continue their daily transactional work while the update is in progress.

However, admin user operations, including metadata operations, are not allowed. For more information, see Zero-downtime (ZDT) upgrade for BMC Helix Innovation Suite and applications.

The following components are included in the service update: 

• BMC Helix ITSM 
• BMC Helix Smart IT 
• BMC Helix CMDB 
• BMC Helix Digital Workplace Basic 
• BMC Helix Digital Workplace Advanced 
• BMC Helix Innovation Suite 
• BMC Helix Innovation Suite Apps 
• BMC Helix Action Request System 
• BMC Helix Multi-Cloud Broker 
• BMC Helix Business Workflows 

Staying on the latest version of BMC Helix ensures that your environment remains secure, supported, and up to date with the latest capabilities.

By upgrading regularly, you benefit from:

• New features and enhancements
• Fixes for known issues and defects
• Security updates and vulnerability patches
• Performance, stability, and usability improvements
• Access to the latest AI‑powered and automation capabilities introduced in each release

Review the features and enhancements included in each release in the product release documentation.

BMC Helix also follows a strict Service Update policy to ensure that all customers remain on supported versions. 

The standard service update window is up to 24 hours. If the update is completed earlier than expected, the environment is made available immediately.

Yes. Based on your region, production updates are scheduled to begin outside core business hours on weekdays to minimize impact on your operations.

The following table shows the update start times by region (in UTC): 

Because service updates are Zero Downtime (ZDT), in‑place upgrades, there is no impact to end‑user operations. The production environment remains accessible throughout the update, allowing end users to continue their daily transactional work.

As a result, service updates are scheduled on weekdays by using a standardized, well‑established process consistently followed for all customers. We have successfully upgraded 600+ customers in FY26 by using the same process.

No. There are no prerequisites for a service update. The system is upgraded as is.

However, if you have any specific requests, such as a database refresh or changes related to customizations or configurations, you must complete them before the service update. Use the standard change request process or raise a support case (for customizations or configurations) to address any specific request.

BMC Helix performs service updates as needed to ensure your environment remains on a supported, up-to-date version.

You can find the latest release notes and details about new features, enhancements, and fixes on the BMC Helix ITSM Release Notes and Notices page.

Yes. The service update schedule is displayed on the Change Calendar 7 days before the start of the Development (DEV) environment update.

Yes, you can opt out of a scheduled service update. However, BMC Helix does not recommend opting out, as service updates help keep your environment secure, stable, and supported.

If you do not want to update your environment on the scheduled dates, you can request a date change or opt out of service updates for a limited period.

To reschedule or opt out of a scheduled service update, submit a support case through Support Central at least 4 calendar days before the scheduled service update. In your request, include the business justification and the duration of the opt‑out.

No. Service updates cannot be reverted or rolled back.

As part of your zero-downtime service updates, BMC Helix performs pre-checks and always starts with the development and/or QA environments.

Any fixes for regressions identified in the lower environments are applied before updating production.

If an issue occurs during the ZDT service update window, BMC Helix actively investigates and resolves the issue to minimize impact and prevent delays.

BMC Helix does not recommend rolling back a service update, as a rollback can result in data loss and undermine the ZDT update process.

If a rollback plan is required, rollback is performed by completing a full database restore from a backup that you requested or took before the start of the service update change window. Any data generated in your BMC Helix applications after the backup was taken and before the database restore will not be available after the rollback.

The standard ZDT service update process schedules updates for Development (DEV), Quality Assurance (QA), and Production (Prod) environments within a single month.

The process includes:

• A one‑week testing period between the DEV and QA updates
• A two‑week testing period between the QA and Prod updates

After each environment update, BMC Helix performs basic sanity checks. Customers are responsible for determining and executing any additional validation or test cases required for their environments.

If issues are identified, customers can submit a support case. If there are open blocker issues after the DEV or QA updates, customers can request a pause of the Production update. The Production update does not proceed until all blocker issues are resolved.

This is a well‑tested and established process that BMC Helix follows to perform service updates for customers on weekdays.

We have successfully upgraded 600+ customers in FY26 using the same process.

During the service update window for Development (DEV), Quality Assurance (QA), and Production environments, you can continue to perform all end‑user operations.

However, administrator operations are not allowed, including metadata‑related activities, while the update is in progress.

For more information, see  Zero-downtime (ZDT) upgrade for BMC Helix Innovation Suite and applications.

There is no downtime for end users in the Production environment during a Zero Downtime (ZDT) service update.

During the update window:

• Development (DEV) and Quality Assurance (QA) environments may be unavailable for up to 30 minutes
• The Production environment remains fully available to end users throughout the update

Yes. After each environment update, BMC Helix performs basic sanity checks, such as verifying URL availability and login and logout functionality.

Customers are responsible for deciding and executing additional test cases to validate their environments in line with their business requirements. To support customer testing, BMC Helix provides:

• A one‑week testing window between the Development and Quality Assurance (QA) updates
• A two‑week testing window between the QA and Production updates

If you encounter any issues during these testing windows, submit a support case. We recommend submitting one support case per use case.

If there are open blocker issues after the DEV or QA updates, you can request a pause of the Production update. The Production update does not proceed until all blocker issues are resolved.

We do not recommend extended testing gaps between environments during a service update.

Keeping Development (DEV), Quality Assurance (QA), and Production (Prod) environments on significantly different versions is not advisable for the following reasons:

• Issues observed in Production may not be reproducible in DEV or QA
• Code migrations involving new out‑of‑the‑box (OOTB) workflows from DEV or QA to Production may not be supported
• Database refreshes from Production to lower environments are not supported due to version mismatches

For these reasons, customers are encouraged to complete testing within the recommended testing windows between environment updates.

Service update email notifications are sent to the Maintenance Contact listed in Support Central. All notifications are sent from BMC Helix SaaS Operations.

For each environment update, you receive the following five notifications during the service update process:

• Start
• Platform applications update completion
• ITSM applications update completion
• Smart applications update completion
• Overall completion

If the service update window is expected to exceed the scheduled duration, an additional notification is sent to inform you of the extended window and revised timeline.

You do not need to request a service update. BMC Helix automatically plans and schedules service updates, and shares the schedule with you.

Service update schedules are communicated as follows:

• 7 days in advance for updates to non‑production environments
• 21 days in advance for updates to Production environments

The service update schedule is also displayed on the Change Calendar 48 hours before the update begins.

No. Opt‑out is not supported for IT Operations Management and Common Services service updates.

IT Operations Management and Common Services updates are scheduled at the data‑center level. Because these updates are applied to all customers within a data center at the same time, it is not possible to customize the schedule for an individual customer or opt out of these service updates.

The service update schedule shared with you via email notifications includes the start and end times for each update.

The standard service update window is up to 24 hours. If the update is completed earlier than expected, the environment is made available immediately.

If the service update is expected to take longer than planned, you will receive an extension notification with the revised timeline. There is no impact to end users, as the update is performed by using a zero‑downtime (ZDT) process.​​​​​

No. There are no prerequisites that you must complete before a BMC Helix service update.

BMC Helix performs service updates monthly for customers’ non‑production and Production environments.

Customers are notified in advance of each service update via email notifications, and the update schedule is also displayed on the Change Calendar.

No. Revert or rollback is not supported for IT Operations Management and Common Services updates.

UseBMC Support Central portal, which requires registration. 

Access to theBMC Support Central portal first requires registration through BMC Support Central. You will log in using the credentials you set up during that registration process.  Your username is usually your employer-provided email address.

To register for access to the portal, see the BMC Support Central User Guide. 

If you are having trouble accessing either portal, contact your Customer Success Specialist or have a co-worker submit a support case on your behalf. You may also initiate a live chat (during business hours) from the BMC Support Central site.

BMC Support Central is available via a desktop application only.

See Change-documentation for a complete list of the information you must provide when submitting a change within Support Central. Failure to provide the required information will result in scheduling delays for your request.

Scheduling is based on the date and time you request from the Requested Window Start Date and Requested Window Start Time fields. If there are any conflicts or concerns with these inputs, BMC SaaS Operations will contact you. BMC recommends a minimum of 72 hours notice for RFC scheduling.

Within BMC Support Central, you may cancel the case by opening it and selecting the Cancel button.

If you are using BMC Support Central, you have to state the related request in plain text. 

No. Email communication will continue, with the added benefit of communication through the RFC request within the portal.

No. Although you may summarize the type of change in the Summary field, BMC SaaS Operations actually determines the type of change and categorizes it in the internal change management system. Customer input is not needed for this field.

No. BMC allows you to opt-out of CRB review and approval, assuming the customization was designed and developed using we recommended best practice guidelines. See BMC Helix Customization policy for more information.

Yes. Customers may add a comment to the RFC form requesting an adjustment to the date and time originally requested.

No. Regardless of whether or not you have CRB approval, it is your responsibility to maintain your customizations on an ongoing basis. For additional information, see the BMC Helix Customization policy.

BMC will first review the RFC inputs for completeness. Every effort will be made to schedule the requested change based on the date and time you requested. If there are any issues with the RFC scheduling, BMC SaaS Operations will contact you with a suggested alternate date and time. You will then have the option to accept or reject the proposed change window. If you need to reject it for any reason, please provide a reason for a rejection or another alternate date and time that works for you.

You may add a comment to the original RFC request and the assigned Support Manager can contact you.

In BMC Support Central > Case Management and select the Change Calendar option to see your scheduled change in the calendar view. If the RFC is not yet scheduled, you can view it under Case Management Details menu. This menu displays all requests that you have submitted, including incidents, service requests, and change requests. Various filtering options are available from the list view.

In BMC Support Central > Case Management, select Change Calendar. This option displays a calendar view of all scheduled (past 90 days plus future) changes.

1. From the Support Central, select Case Management > Lifecycle Requests.
2. Select a -dev environment.
3. Under Lifecycle Requests, select Database Backup.
4. Based on the requirements, provide one of the following file suffixes when raising the service request:
   • FIXES_ONLY
   • FIXES_AND_DATA
   • FULL_FIXES_DATA_DELTA
   • HOTFIX_PHASE

For more information, see Database-backups-and-restores.

1. From the Support Central, select Case Management > Lifecycle Requests.
2. Select a -dev environment.
3. Under Lifecycle Requests, select Database Backup.

For more information, see Database-backups-and-restores.

1. From the Support Central, select Case Management > Lifecycle Requests.
2. Select a -dev environment.
3. Under Lifecycle Requests, select Stop/Start Applications.

For more information, see Stop-Start-Applications.