- Scope of the Services
- Support Service Options
- Definitions of Incident Severity Levels
- Standard Support
- Silver Support
- Business Hours
- What is covered by Intland’s Support service
- What Inland’s Support Services Do Not Cover
- Support Incident Reporting, Contact Methods
- Required Information on Incidents
- API Support
- Incident Status and Workflow
- Incident and Bug Fixing Policy
- Customization, Feature and Change Requests
- Supported Version of the Software
- Hosting policies
- Appendix Definitions
Do you want to learn?
Before submitting a ticket, we suggest you search the Knowledge Base for advice!
Do you have a problem?
If the Knowledge Base wasn’t helpful in resolving your issue, it’s possible that you’re experiencing a bug. For the shortest response time, submit a ticket by logging in to codebeamer or codebeamer X and using the Service Desk. The severity rating you enter here will define the priority your issue is handled with. Support Services are only available for our customers.
Scope of the Services
Intland provides technical support (Support) for customers under a valid Intland LICENSE AGREEMENT and SUPPORT AGREEMENT for the licensed Intland products (codebeamer or codebeamer X, hereafter referred to as Software in this document).
Support Service Options
Options | Standard | Silver | |
---|---|---|---|
Knowledge Base access | Yes | Yes | |
Online download access to the latest releases and patches, and upgrades | Yes | Yes | |
Customer Service Desk | Yes | Yes | |
Phone | Yes | Yes | |
Live screen sharing | Yes | Yes | |
- | Yes | ||
Number of users able to create incidents | 2 | 4 | |
Support language | English | English / German | |
Support hours | 8×5 | 24×5 (for critical issues) | |
Initial Response Time(5) for different Incident Severity Levels | Critical(1) | 8 Business hours | 4 Business hours |
Major(2) | 2 Business days | 1 Business day | |
Medium(3) | 3 Business days | 2 Business days | |
Low(4) | 5 Business days | 5 Business days | |
Information Security Incident Response (ISIR) | See Chapt. Information Security Incident | See Chapt. Information Security Incident | |
Dedicated support | Support Engineer | Senior Support Engineer | |
Advice on installation | Yes | Yes | |
Log analysis | Yes | Yes | |
Upgrade support | - | Yes | |
Remote upgrade | - | Yes | |
Remote assistance | - | Yes | |
Resource and Performance monitoring | - | Yes | |
API support | - | Yes | |
Free staging server | - | Yes | |
Annual on-site visit | - | Yes |
Definitions of Incident Severity Levels
Intland will classify the normal incidents on their Severity Level according to the criteria below. Intland may re-classify Incidents if it believes that the original classification is incorrect. The Response Goal shall not apply if the Incident is caused by third party Software. Intland will not correct any Software Failure caused by modification or enhancement of the Software, or when the Failure is corrected by an existing Software release provided by Intland.
Severity | Definition | Response Goal |
---|---|---|
(1) Critical | The “Production system” is not available, substantially unavailable, or normal business operations are seriously disabled. The incident is preventing productive work on your production system, and it affects users performing a business-critical function. If Intland Software provides an acceptable workaround, the severity classification will drop to Medium or Low. | Intland will provide a response and begin to analyze the incident and verify the existence of the problem within the Initial Response Time(5) defined period. Intland will use commercially reasonable efforts to resolve Critical Incidents as soon as possible. The resolution will be delivered as a Workaround or Hotfix. If Intland provides an acceptable Workaround or Hotfix for the Incident, the severity classification will drop to Medium or Low. |
(2) Major | The “Production system” is available but the incident has a business-critical impact on your production system; a function or functions are not available or are not working properly, preventing productive work, and affecting people performing a business-critical function. | Intland will provide a response and begin to analyze the Incident and verify the existence of the problem within the Initial Response Time(5) defined period. Intland will use commercially reasonable efforts to resolve Major Incidents as soon as possible or in the next Maintenance Release. If Intland provides an acceptable workaround for the Incident, the severity classification will drop to Medium or Low. |
(3) Medium | The incident has business impact on your “Production system”, but does not prohibit the execution of productive work, or a reasonable workaround is available. | Intland will provide a response and begin to analyze the Incident and verify the existence of the problem within the Initial Response Time(5) defined period. |
(4) Low | The incident is not production-critical, or it is detected on your non-production system. The incident has no impact on the “Production System” performance, quality or functionality and no impact on productive work. | Intland will provide a response to the Incident and verify the existence of the problem within the Initial Response Time(5) defined period. Intland does not guarantee a resolution time for Low Severity incidents. |
Standard Support
With Standard Support two members (or more members, but only if this is agreed in writing in advance, depending on the End-User’s selected service package) of your team able to create an unlimited number of incidents on our Customer Service Desk, Standard Support includes support by phone, live screen sharing. Standard Support is available in both German and English, with a dedicated Support Engineer attending to your tickets 8 hours a day (9AM-5PM CET), 5 days a week (Mon-Fri).
Silver Support
Silver Support includes a wide range of support services. This flexible support plan lets 4 members of your team submit an unlimited number of incidents either using the Customer Service Desk or via e-mail, based on which your team may receive help via phone, e-mail, or live screen sharing over the web. Silver Support is provided in both English and German and includes 24×5 (Mon-Fri) support for critical incidents by our dedicated senior Support Engineers.
Business Hours
Intland Software’s business hours are 9:00 AM to 5:00 PM CET (GMT +1), Monday through Friday, excluding German national holidays. For detailed information on German public holidays, please see https://en.wikipedia.org/wiki/Public_holidays_in_Germany.
What is covered by Inland’s Support service?
- Root cause analysis, identifying and troubleshooting incidents
- Assistance on installation incidents
- Guidance on upgrade incidents
- Guidance on Intland’s supported integrations (3rd party integrations are not covered)
- Analysis of SSO, LDAP/AD connection problems
- Incidents are usually resolved in newer releases, thus an upgrade may become necessary to benefit from fixes.
What Intland’s Support Services do not cover?
- Technical Support for end of life versions (see currently supported versions). For a special support contract, please contact our sales team!
- When the software is used on a non-recommended platform or in a non-recommended environment. Recommended platforms and environments are described in the knowledge base.
- Customers without a valid software license, or a valid Support & Maintenance Agreement.
- Beta releases, release candidates, snapshots, and end-of-life releases, and for deprecated features.
- Customized product instances where the original source code was changed or extended.
- Programming-related or development related questions and requests.
- Product education questions.
- Professional services, including:
- Installation and upgrade services (Support helps with advice)
- Docker configuration issues
- Customization
- Performance tuning
- Infrastructural problems, configuration of SSO, OpenID Connect, LDAP/AD configuration, Apache & web server, Proxy and Firewall issues
- Database and clustering configuration
- 3rd party integrations
- Failures caused by software for which Intland is not responsible.
Support Incident Reporting, Contact Methods
The primary means of submitting issues is via Incident Trackers on our Service Desk. Tickets submitted using Incident Trackers are prioritized based on their severity rating defined by the user upon submission. Incidents may be submitted by Authorized Contact(s) only. Authorized Contact(s) must have received training to provide them with sufficient expertise in operating the Software. You can also contact us by emailing support@intland.com, or via phone:
- US phone number: 866-468 5210
- EU phone number (+49) 711-2195-420
Incidents submitted via email or telephone are automatically assigned a low severity rating.
Required Information on Incidents
All incident reports must, if applicable, include the following:
- The Licensee’s “account” which Intland provides to the Licensee on registration.
- The exact Version Number and the Platform that the Software is running.
- Before reporting an Incident, the Licensee must verify that the Incident is reproducible. The Licensee should provide a reproducible Test Case that demonstrates the specific use case causing the Software Failure being reported.
- Log files, screenshots, trace files relevant to the incident.
- The exact wording of all related error messages.
In case of reported Information Security Incidents the following data has to be provided:
- Name of the incident
- Summary of the incident (some evidence has to be provided, for example screen shot, alert notice etc.)
- Categorization
Please note that in this tracker Information Security incidents must be reported exclusively, not any feature request or improvement request can be submitted. If such a feature request or improvement request is included the incidents are going to be closed without further investigation.
Our Silver Support service covers remote upgrades & assistance, API support, a free staging server, and an annual on-site visit to your team by our experienced Support Engineers.
API Support
All incident reports must, if applicable, include the following:
- To analyze incidents reported against Rest- and/or OpenAPI (Swagger), a sample code that demonstrates the problem must be provided.
- API support does not include answering API related development questions.
Incident Status and Workflow
The table below describes Intland’s incident management workflow and the actions performed in various statuses as the incident progresses along the workflow:
Incident Status | Description |
---|---|
New | Every reported incident starts out in this initial status. Generally, only recently submitted incidents will have this status. |
Under Investigation | Intland’s Support Team is analyzing the incident. |
Pending | Intland’s Support Team requires (and waits for) further information about the incident. After receiving the required information, the incident should transition to the status Under Investigation. Items remaining in this status for 30 calendar days will be closed automatically. |
Short-term target | The reason of the incident is identified, and the fix is planned for the next upcoming release. |
Medium-term target | The reason of the incident is identified, and the fix is planned for one of the upcoming releases. |
Long-term target | The reason of the incident is identified, and the fix is planned to be delivered in subsequent future releases later on. |
Resolved | The incident is considered resolved. Items remaining in this status for 30 calendar days will be automatically closed. |
Closed | The incident is closed, no further activity is available. |
Incident and Bug Fixing Policy
Intland Support provides workarounds and advice to resolve specific product incidents:
Bug Fixes
Fixes for non-critical, non-security bugs will be provided by Intland Software in the next maintenance release, with the conditions that:
- The fix is technically feasible, and
- The fix doesn’t impact the quality or integrity of the Software.
Intland Software assesses and prioritizes bugs, and schedules fixes for non-critical incidents based on internal considerations. Factors considered in the analysis and prioritization of bugs include, but are not limited to:
- How many customers are affected by the problem?
- Is there an effective workaround or patch to the incident?
- How difficult is it to fix the incident?
- Whether the fix is already available in a newer release
- Will new already features on our roadmap make the bug obsolete when they’re released?
- Other internal factors within Intland’s judgement.
Hotfixes (Patches)
In special cases, Intland may provide Hotfixes (patches) when:
- the incident’s Severity is classified by Intland as “Critical”, or
- the incident is security-related.
As per our Severity Levels table above, Critical Incidents are defined as incidents that make the “Production system” is unavailable, substantially unavailable, or seriously disable normal business operations. When the incident prevents productive work on your production system and affects users performing a business-critical function, it is considered Critical.
Non-security Hotfixes are only available on a case by case basis as requested by our users. Intland reserves the right to charge for Hotfixes based on custom quotes.
Information Security Incidents Response
Any security events and information security weaknesses should be assessed immediately after the incident/event has been observed, and it should be decided if they are to be classified as information security incidents.
Information security events and weaknesses shall be classified under the below two severity levels:
- Major (Security) Incident
- Normal (Security) Incident
Security incidents need to be reported under the following links:
- codebeamer: https://codebeamer.com/cb/tracker/16949942
- codebeamer X: https://codebeamer-x.com/x/#/tracker/12613106/0
Classification/Severity | Event description | Action | Reaction Time |
---|---|---|---|
1. Major (Security) Incident | - Organization has lost the ability to provide a critical service to a subset (or all) of system users. - Personal or other sensitive data was compromised. |
- Time to recover is long enough, and additional resources are needed. - Escalation, internal and external communication. - Additional resources should be made available. |
4 working hours |
2. Normal (Security) Incident | - The company can still provide all critical services to all users but has lost efficiency. - No personal or other sensitive data was compromised. |
- Time to recover is predictable with existing resources. - Information Security Incident Response Team (ISIRT) can manage the whole incident handling process at its own discretion within a reasonable time frame. |
8 working hours |
Just for clarification: application security vulnerabilities are not considered as security incidents, application vulnerability management is governed by Secure SDLC.
Customization, Feature and Change Requests
Intland Software provides various extensions, templates, and other customization options with documentation and examples to support the customization of the Software.
Our product managers review Feature and Change Requests on a regular basis, however, we don’t guarantee that we implement or consider to implement such requests.
In addition, Intland Professional Services provides help with answering questions regarding customization, configuration, add-ons, product development, performance tuning, clustering, and creating integrations with 3rd party tools. For more information on Professional Services, please contact us at sales@intland.com.
Supported Version of the Software
codebeamer Version Lifecycle & End of Life policy
Intland regularly retires older versions of the Software to be able to focus on delivering high quality in upcoming releases. You’ll find the lifecycle details of recent and current Software versions (codebeamer) below:
Version | Code name | End of Life | Changes |
---|---|---|---|
22.04 | Felicity | 30 April 2023 | Release Notes |
21.09 LTS | Emma | 30 September 2023 * | Release Notes |
20.11 LTS | Carmen | 30 November 2022 * | Release Notes |
For support questions about older versions, please contact sales@intland.com for a special support contract.
* please contact sales@intland.com for extended End of Life support.
Upgrading codebeamer
Upgrading to the latest version of codebeamer is a necessary step to gain access to new features, performance improvements, bug fixes, and other advantages. See the upgrade paths that were tested by Intland Software below:
Target version | Tested upgrade path from version |
---|---|
22.04 |
|
21.09 LTS |
|
20.11 LTS |
|
9.5 LTS |
|
9.1 |
|
7.9.1 |
|
What are the differences between codebeamer’s LTS and non-LTS versions?
– A Validation Kit is available only for LTS versions
– LTS versions will be maintained for 2 years from the initial release date. For more information please refer to our Version Lifecycle & End of Life policy.
– Non-LTS versions are supported for 1 year from the initial release date. For more information please refer to our Version Lifecycle & End of Life policy.
codebeamer X (Intland Retina) Version lifecycle & End of Life policy
Find the lifecycle details of recent and current Software versions (codebeamer X, formerly Intland Retina) below:
Version | End of Life | Changes |
---|---|---|
4.2 | 01 April 2023 | Release Notes |
4.1 | 22 October 2022 | Release Notes |
4.0 | 01 July 2022 | Release Notes |
Upgrading codebeamer X (Intland Retina)
Upgrading to the latest version of codebeamer X (formerly Intland Retina) is a necessary step to gain access to new features, performance improvements, bug fixes, and other advantages. See the upgrade paths that were tested by Intland Software below:
Target version | Tested upgrade path from version |
---|---|
4.x | 2.1 or higher |
3.x | 2.1 or higher |
Hosting policies
Click the policies below for more information on the information security requirements for Azure VMs and AWS EC2 Cloud-hosted instances of Intland Software’s applications:
Appendix: Definitions
a) Production System means the Software that is being used as a regular part of actual day to day business operations.
b) Services refers to the Support Services listed in this document.
c) Version Number is a three-part version number in the form of A.BB.CCC which identifies Releases of Intland products.
d) Incident means bug or failure reported to Intland as a result of a reproducible operational deviation of the Software from the Software specifications.
e) Business Hours are 9:00 AM to 17:00 PM CET (GMT +1), Monday through Friday, excluding German national holidays. For information on German public holidays, see the following link.
f) Workaround means a Hotfix or other method used to avoid Software Failure.
g) Releases of codebeamer refers to any new version of Intland Software’s products that delivers extended functionality, performance and usability improvements, and bug fixes. In some cases, Intland Software may consolidate features due to global system improvement, resulting in the removal of certain features.
h) LTS – Long term supported release, is numbered with the abbreviation of “LTS”.
i) codebeamer releases on the roadmap or under development are named by English women’ names calendar- eg.: A(lice), B(etty), C(armen), D(orothy), E(mma) etc.- until its finally released and published.
j) codebeamer releases published are identified by the release date – eg. November 2020 is 20.11. For Example: * CB 20.11 LTS***
k) Service Packs are numbered by 1…n and abbreviated as “SP”. Service packs for certain releases are identified as eg.: CB 20.11 LTS – SP1
l) TÜV Validation: versions validated by TÜV Nord and further related information can be found on the Intland webpage under the following link.
m) Releases of codebeamer X refers to any new version of Intland Software’s products that delivers extended functionality, performance and usability improvements, and bug fixes with Angular frontend. In some cases, Intland Software may consolidate features due to global system improvement, resulting in the removal of certain features.
n) codebeamer X is numbered by 1…n and one decimal 1…n. eg: CB X 4.0, CBX 4.1.
Change in the first number means significant new features or changes in the next release eg. CBX 3.0 to CBX 4.0…4.1.
Change in the first decimal means minor improvements, usability development, bug fixing.