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

BMC Electronic Product Distribution (EPD) is the main interface for downloading products, patches, and updates from BMC.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 (EPD)

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-Upgrade-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-Upgrade-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-Upgrade-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, see KB 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, see BMC 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, you can work with them to schedule an upgrade for you. Once scheduled, you will receive an email notification at least 7 days before your DEV upgrade date.  

If you don´t have an assigned CSM, you will receive an email from our Success team (success@bmc.com) with upgrade dates if you are not in compliance with our Service Update Policy. You will be notified 30 days in advance of the DEV upgrade date, followed by 2 reminder emails sent 15 days and 7 days before the upgrade.  

Zero Downtime Service Updates are in-place upgrades with no impact to end users. The Production environment remains accessible throughout the update for end-user operations; i.e., 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.

Note: Your Development and QA environments may be unavailable for up to 30 minutes during the update window. However, your Production environment will be fully available.  

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 

The first answer is simple: so you can take advantage of all the new enhancements, features, and fixes that the newer versions offer. And let´s not forget the cool agentic AI capabilities launched with every version.  

You can find more information about the features and enhancements for each version here.

Also, at BMC Helix, we follow a strict Service Update Policy, which states:

“Service Update” refers to releases of a new version or patch as part of your BMC Helix subscription services. BMC Helix service updates enable new features, enhancements to existing capabilities, fixes, and vulnerability patches. You can stay on a version no less than n-2 of the current BMC Helix ITSM version, where “n” refers to the latest version of BMC Helix ITSM available generally.  

This means customers must accept the latest service update if their current BMC Helix ITSM version is more than n-2 versions behind the latest release. All future releases will have 2X.X.00, 2X.X.01, 2X.X.02 before upgrading to the next major 2X.X.00 release.    

For example, you are required to accept the service update if the version being released is 25.3.00 and your BMC Helix ITSM is currently on 25.2.00 version or lower. However, you may opt out if you are currently on 25.2.01 (within n-2) of the latest release. ¨

Our standard upgrade window is 24 hours. If the upgrade completes sooner, the environment is released immediately.

Based on your location, service updates are scheduled to begin outside core business hours on weekdays.

The following table lists the regions and their respective update start time: 

Since these are ZDT and in-place upgrades with no impact to end users, the Production environment is accessible throughout for end user operations, i.e., end users can continue to do their daily transactional work in the Production environment while the update is being completed, hence these are scheduled on weekdays, and the same process is being followed by all our customers. This is a well-tested, established process in which we upgrade multiple customers on weekdays. We have successfully upgraded 600+ customers in FY26 using the same process.

There are no prerequisites; the system is upgraded as is.

However, if you have any specific requests, such as a database refresh, make sure they are completed 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 often as required to ensure you are on the latest version.

You can find them here: Release notes.

The service update schedule will be visible to you on the Change Calendar 7 days prior to the start of the DEV update.

Yes, you can opt out of a scheduled service update.

BMC Helix does not recommend that you opt out of a scheduled service update. However, 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, use Support Central to submit a support case at least 4 calendar days before the scheduled service update. In the request, include the business justification for the opt-out and the duration.

In preparation for your zero-downtime service updates, BMC Helix performs pre-checks and always starts with the Development and/or QA environments. Any fixes for regressions reported on your lower environments will be applied to Production.

In the event of a failure during the zero-downtime service update window, BMC Helix will actively investigate and resolve issues promptly to prevent delays.

We do not recommend rolling back, as it would incur data loss and undermine the ZDT process. However, if you require a rollback plan for service updates, the rollback process involves a full database restore from a backup you requested or took prior to the start of the change window. Any data generated within your Helix applications from the time the backup was taken until the database restore occurs will not be reflected post database restore.  

Please note that performing rollbacks will require downtime for your service update. End users will not be able to access your service during the entire service update change window (typically 24 hours). 

Our standard service update process involves scheduling all three environments within a month, with a 1-week testing period between DEV and QA, and 2 weeks between QA and Prod.

At the end of each environment update, we perform basic sanity checks. However, it’s recommended that customers use their discretion to decide the test cases to validate their environments. If they have any issues, they can always submit a support ticket.  If there are open blocker issues after DEV and QA upgrades, the customer can request a pause for the Prod upgrade. Until these blocker issues are resolved, we will not proceed with the Prod upgrade. 

This is a well-tested, established process where we upgrade multiple customers on weekdays. We have successfully upgraded 600+ customers in FY26 using the same process.

During the update of your environments (Development, QA, and Production), you can perform all end-user operations. 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.

Your Development and QA environments may be unavailable for 30 minutes during the update window. However, your Production environment will be fully available to end users.

At the end of each environment update, BMC Helix performs basic sanity checks (such as the availability of URLs, log-in, and log-out). 

We recommend that you use your discretion to decide the test cases to run in your environments. To accommodate testing during the update window, BMC Helix has set aside a one-week rest period between the update of your DEV and QA environments and a two-week rest period between the QA and PROD environments. If you face any issues during this period, please submit a support ticket. We recommend submitting one support ticket per use case.  

If there are open blocker issues after DEV and QA upgrades, the customer can request a pause for the Prod upgrade. Until these blocker issues are resolved, we will not proceed with the Prod upgrade. 

We do not recommend having significant gaps between the environments. The difference in version between DEV/QA and PROD (until PROD is upgraded) is not advisable due to the following reasons:

1. Any issues observed in PROD may not be reproducible in DEV/QA.

2. Code migrations involving new OOTB workflows from DEV/QA to PROD may not be supported.

3. DB refresh from PROD to lower environments will not be supported due to version mismatches.

The Service Update email notifications will be sent to your "Maintenance Contact" listed in Support Central, and they will come from "BMC Helix SaaS Operations".

There would be 5 notifications which would be sent out during the upgrade process for each environment:  

1. Start 

2.  Platform Apps Completion 

3.  ITSM Apps Completion 

4.  Smart Apps Completion 

5. Overall completion. 

If the upgrade window is going to be exceeded, we send a notification letting the customer know how much longer the window will be extended.

BMC Helix plans the service update and shares a schedule with you. The service update schedules are shared via email 7 days prior to updates to your non-production environments and 21 days prior to updates to your production environment.

The service update schedule will be visible to you on the Change calendar 48 hours before the update begins.

ITOM and Common Services Updates are scheduled for each Data Centre at a given time; therefore, it is not possible to customize the schedule for a customer, nor to opt out of these service updates.

The service update schedules, shared via email notifications, include the start and end times of the update. If the update takes longer than expected, the customer will receive an extension notification. There will be no impact on customers as the update is ZDT.

No, there are no prerequisites.  

We perform service updates monthly for customers’ non-prod and prod environments. The customer will be notified of the upgrade in advance via email, and it will also appear on their change calendar.

No, this is not possible for ITOM and Common Services updates.

Use BMC Support Central portal, which requires registration. 

Access to the BMC 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 BMC 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.