The Totara Helpdesk is a web-based system used to provide formal, ticketed support for Totara Partners and Direct Subscribers. It is the only official communications channel for Totara Support and other channels such as forums, email, chat and phone-based support are not currently provided.

Using the Totara Helpdesk

The Totara Helpdesk can be used to:

• Submit support requests
• Check on the status of previously created requests
• View the history of previously created requests

Accessing the Helpdesk

Visit the Totara Helpdesk and enter your username and password.

The Forgot your password? link can be used to reset your password. Please note that Totara staff cannot obtain or reset your password for you.

Creating a support request

Once logged in, create a new support request by choosing the appropriate request type and completing the required fields.

The request types are:

• Report a problem
• Ask for help
• Request a new feature
• Ask for access

Request types have been designed to only capture the information required for each type of request. Instructions for each field are also displayed to help you.

Support requests are for obtaining support and are different from issues accessible via the public issue tracker. Totara Support will submit any required bug reports, new feature suggestions and improvements following submission of a request which can be viewed in the public issue tracker. See Issue tracker FAQs for further information.

Viewing existing requests

View all of your existing requests by choosing My requests.

You can filter requests by status, creator and type. It is also possible to search using keywords.

Searching and viewing troubleshooting articles

Prior to submitting a support request, you can search across our troubleshooting articles for an answer to your query.

When submitting a request, articles which match the request summary are also displayed.

Select an article link to view it.

About Totara Support

Generally, Totara Support can help by investigating problems to provide assistance with technical and functional issues encountered with Totara products by Partners and Subscribers. If appropriate, they will direct users to relevant self-help and training resources.

Levels of support provided vary but include:

• Tier 1: Fielding questions and investigating issues of a general and basic nature regarding functionality.
• Tier 2: Investigation of more complex usage issues requiring extensive and in-depth expertise.
• Tier 3: Issues requiring the involvement of the Totara core development team which may involve software fixes for resolution.

Who can use the Totara Helpdesk?

The available tiers of support will depend on whether you are a Totara Partner or Direct Subscriber. 

Totara Partners: Tier 3 support only. Partners are required to provide Tier 1 and Tier 2 level investigation prior to escalating issues to Totara Support. 

Direct Subscribers: Eligible for Support Tiers 1-3.

Please note the services of Totara Support are available in English only. Multilingual support is not currently provided.

When should the Totara Helpdesk be used?

A support request should be submitted when:

• Totara’s available self-help resources do not provide the assistance you need to resolve a technical issue with the Totara product you are using.
• You need to request access or changes to Totara systems for your organisation.

Available self-help resources include:

• Help resources within the software via the help icon ()
• Totara documentation located at totara.help
• Totara Academy training located at totara.academy
• Totara Community forums and resources located at totara.community
• Totara YouTube channel located at www.youtube.com/user/Totaralms

Totara Community forums provide a mechanism for users to exchange ideas, share expertise and assist each other. Totara staff may participate in the discussions, however the forums are considered a self-help resource and are not an official support channel.

Requesting access to the Totara Helpdesk

To use the Totara Helpdesk, a user account must be set and activated by the requesting user via the link provided in a system invitation email.

Totara Partners and Direct Subscribers:

Please submit a request to support@totaralearning.com and ensure you provide your:

• Full name
• Email address
• Direct Subscriber name

Assisting Totara Support

You must provide reasonable assistance to us in determining and resolving problems you report. This assistance may include determination activities such as:

• Performing network traces
• Capturing error messages
• Collecting configuration information and other similar activities to allow us to reproduce the problem
• Resolution activities such as access to your personnel, remote access to the supported environment, or both

Closure of support requests due to inactivity

Totara Support will follow up any support requests awaiting a response from you which have not been answered after seven days. If Totara Support do not receive a response after a further seven days, the applicable support requests will be closed due to inactivity. This is so Totara Support maintain a clear queue of work and ensure issues are being dealt with promptly.

If you believe it may take some time to gather any information requested, you may ask for a support request to be placed on hold for a period of time (as determined by you) to prevent premature closure.

You may reopen a closed support request at any time.

Support hours and response times

Support is made available from 8:00AM to 6:00 PM in the following timezones, Monday through Friday, excluding national and local holidays:

• Pacific (US)
• Eastern (US)
  
• UK
  
• Australian Eastern
• New Zealand

Severity level 1

Inability to use any major functions of the Totara Software, resulting in a critical impact on the user.

Time to respond is four hours, during extended support hours.

Severity level 2

Important existing functionality is not available and there is not an acceptable workaround. E.g. a course cannot be published or a previously published course is otherwise unavailable, or an administrator menu feature is not available.

Time to respond is six hours, during extended support hours.

Severity level 3

Incorrect behaviour of the Totara software. E.g. a cosmetic problem, applicable help files or an important existing functionality is not available but there is an acceptable workaround.

Time to respond is five business days.

Escalating issues

Please see the Escalation Process section of your Subscription or Partner Agreement.

What does Totara Support not cover?

Specifically, Totara Support does not provide support for the following.

System engineering issues

Totara server-based installations must be run on a platform which includes a suitable operating system, database server, web server, and scripting software which are configured to meet the needs of each installation. Beyond specifying minimum requirements and recommended specifications, Totara Support does not provide investigation of or assistance with system engineering issues related to the underlying platform on which the Totara instance is deployed.

This exclusion does not apply to subscribers of Totara Cloud solutions which include full platform support.

Third-party plugins

Plugins which are provided as part of the Totara software installation package are the only plugins which are supported by Totara Support.

Any and all other plugins are used at your own risk and are not supported by Totara Support.

Customisations

As open-source software, Totara instances are often customised to meet business-specific functional needs. While Totara fully endorses the open-source ecosystem, such code-level customisations are beyond the scope of the core Totara system.

Therefore, Totara Support does not assist with or provide support for such customisation. If you encounter an issue you think is a bug in Totara while working on a customisation, you must demonstrate the functional issue exists in a non-customised installation of Totara, outside the context of any customisation, if raising a helpdesk ticket with Totara Support.

Customisation includes manipulation of data within the Totara database by non-Totara core software, scripts, or manual processes. Totara’s data schemas are complex and such external data manipulation may introduce data integrity issues which are not resolvable and are beyond the scope of Totara Support.

Clients considering developing new functionality which may be applicable to Totara core are encouraged to contact their Channel Partner Manager to arrange a collaboration with the Totara core development team prior to beginning development.

Guidelines for submitting support requests

Is it a bug or a feature?

Before submitting a support request, it is important to consider whether the request being raised is for a bug or a new feature.

In the most straightforward cases, a bug is existing functionality which is clearly broken, and a feature or improvement is a desire for new or changed system behaviour which is different from the functionality currently implemented.

The distinction might seem like semantics as they will both ultimately require code changes, however the distinction is important as it determines whether or not the code changes can be delivered in a minor point release or only delivered in a new major release.

Making such a determination is often a grey area and somewhat subjective, however it must take into account not only the desired behavioural change but technical aspects of the underlying implementation as well. Individual instances are often heavily customised, therefore consideration must be given to the potential impacts any such technical changes would have across the entire customer base.

Such technical considerations include whether or not the software changes would:

• Produce a change to the user interface
• Require a database schema change
• Require an API change
• Have a high risk of introducing regression errors due to the area of code to be modified

These are often overriding factors in what appears on the surface to be a minor functional change, and determine whether or not the code changes can be delivered safely in a minor point release, or will only be delivered in a new major release with a full quality assurance process across Totara.

Totara senior architects and developers ultimately make the call taking into consideration all the factors noted above.

In general, due to complexity, code dependencies and UI/UX changes, new features and improvements are not backported into earlier releases.

Guidelines for raising a request

Report only one issue per request

Reporting multiple issues in one request impedes optimal issue resolution by:

• Creating unnecessary communication delays while trying to clarify the issues

• Creating unnecessary communication confusion when trying to track the progress of the issues

• Creating the potential for issues to become lost in the mix if one of the issues turns out to be complex and requires significant, further joint investigation

• Limiting our ability to assign the issues across our global team to allow them to be worked on in parallel

Sometimes what initially appears to be a single issue, after further investigation, reveals itself to be a collection of separate issues. In this case, Totara Support staff will split the request to capture and track each issue independently.

Be as clear, specific and detailed as possible

Totara provides complex, open-source, enterprise-level solutions which have highly configurable functionality.

To minimise the potential for confusion and avoid unnecessary information-gathering delays, try to answer these questions as comprehensively as possible when creating a helpdesk request:

• Exactly what are you trying to achieve?
• Exactly how are you trying to achieve this?
• Exactly what, if any, negative behaviour are you encountering which is preventing you from achieving your goal?
• Exactly what behaviour were you expecting?
• What screenshots demonstrate the problem scenario clearly (including settings pages and error messages)?

Avoid cropping screenshots if possible. Sometimes surrounding information (such as the URL of the page or browser version) can be very valuable in understanding the problem.

We recognise helpdesk users have a wide range of knowledge and technical skills, so we will request any additional information needed to progress issue investigations.

Guidelines for reporting bugs

For reporting bugs, there are two key criteria to address in order to get from reporting the bug to a software fix as quickly as possible.

Clearly and unambiguously state the issue

A clear and unambiguous statement of the issue, including a description of the negative behaviour which is apparently revealing a bug and the expected behaviour, aids in focusing efforts towards a software fix.

A bug report ticket is not simply a mechanism to capture information. It is the mechanism used to communicate the issue you have encountered to someone else to a degree in which they can successfully progress towards a software fix.

As part of the issue description, consider and include if relevant:

• The software version affected (required).
• Is the installation non-customised or has it been customised?
• Is the issue being experienced on a single or multiple installations?
• Is the functionality broken or simply inconsistent with other system functionality?
• Any settings changed relating to the area of functionality which could have an impact.
• Any screenshots which help demonstrate the problem scenario, of relevant settings pages or any error messages, or both. Avoid cropping screenshots if possible. Sometimes surrounding information (such as the URL of the page or browser version) can be very valuable in understanding the problem.
• Any debug information available.
• Elements of a fix, if available (for technically advanced helpdesk users).

Provide step-by-step instructions to reproduce the problem scenario

The issue is consistently reproducible

In most situations a bug fix cannot effectively be tested if the reported problem scenario cannot be reliably reproduced. 

Clear, unambiguous reproduction steps allow a fix to be investigated, implemented and quality assurance tested without any delays due to the need to gather additional information to reproduce the problem scenario.

Attach any associated files which may be required or will assist with reproducing the problem scenario.

The issue is sporadic, cannot be reproduced, or both

If a bug appears sporadically and cannot be reliably reproduced, or if a data integrity issue is apparent and the causal steps which created the issue are unknown, provide as much detail as you can surrounding the observation of the issue. If possible, provide step-by-step instructions on what was being done when the issue was observed.

To investigate issues of this nature we sometimes need a copy of the site database where the issue was observed.

Best-practice bug report

Following is a real bug report example demonstrating best-practice elements.

How does Totara provide bug fixes?

Software updates are provided via patches in minor point releases, new major new releases, or both.

Minor point releases (e.g. 16.1, 16.2, 16.3, etc.) predominantly contain bug fixes and minor improvements. These are referred to as 'stable branches' and are typically delivered on a monthly schedule.

Major releases (e.g. 13.0, 14.0, 15.0, etc.) predominantly contain new functionality and bug fixes which cannot safely be delivered in stable branches due to the nature of the software changes. These are typically delivered on an annual basis.

As determined by the development team, patches may be backported to multiple releases. For instance, the fix for a given issue may be provided in 10.15, 11.11 and 12.2. However, patches are not backported to earlier point releases within the same stable branch. For example, a patch provided in 12.2 will not be backported to 12.1.