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

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

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

You can access the Totara Support Helpdesk via

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 that may involve software fixes for resolution.

Who can use the helpdesk?

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

  • For 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. 
  • For direct subscribers: If you are a subscriber for a server or cloud-based Totara solution then you are able eligible for any required support.

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

What does Totara Support not cover?

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

Issue typeDescriptionNotes
System engineering issues

Totara server based installations must be run on a platform that includes a suitable operating system, database server, web server, and scripting software that 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.

3rd party plugins

Plugins that 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.


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 customisation 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 that the functional issue exists in a plain vanilla installation of Totara, outside the context of any customisation, if raising a helpdesk ticket with Totara Support.

Customisations 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 that are not resolvable and are beyond the scope of Totara Support.

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

Using the Totara Support Helpdesk

The Totara Support Helpdesk system can be used to:

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

When should the Totara Support Helpdesk be used?

A support ticket 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 site you are using.
  • You need to request access changes to Totara systems for your organisation.

Available self-help resources include:

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.

Logging in to the system

Go to the Totara Support Helpdesk URL and enter your login credentials.

The Forgot Password? Reset link (shown in the screenshot below) can be used to reset your password.

Totara staff cannot obtain or reset your password for you.

Creating a support ticket

Once logged in, create a new support ticket by navigating to the Submit a Ticket tab. Fields highlighted in red are required fields.

The Priority setting of Critical is reserved for data loss or security issues or issues involving the complete loss of a major functional component.

To ensure optimal issue investigations, please review and follow the Guidelines for Submitting Support Tickets when reporting issues to Totara Support.

Viewing your tickets

Navigate to the My Tickets tab to view a list of your tickets.  You can choose to view All Tickets, only Open Tickets or only Closed Tickets.

Clicking an individual ticket number / subject displays the details of the selected ticket and allows you to navigate forward and backward through the list of tickets.

You can view/hide additional ticket details by using the More/Hide toggle.

Guidelines for submitting support tickets 

Is it a bug or a feature?

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

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

The distinction is 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 major new release.

Making such a determination is often a grey area and somewhat subjective but it must take into account not only the desired behavioural change but technical aspects of the underlying implementation as well. Totara is open source and 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 major new 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 ticket (general)


Report only one issue per ticket

Reporting multiple issues in one ticket 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 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 ticket to capture and track each issue independently.

Be clear, specific and as detailed as possible

Totara provides complex, open source, enterprise level solutions that 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 ticket:

  • Exactly what are you trying to achieve?
  • Exactly how are you trying to achieve this?
  • Exactly what, if any, negative behaviour are you encountering that 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 that 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 that 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 that 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 plain vanilla 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 that could have an impact
  • Any screenshots that help demonstrate the problem scenario, of relevant settings pages and/or any 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.

  • 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 that may be required or that will assist with reproducing the problem scenario.

The issue is sporadic and/or cannot be reproduced

If a bug appears sporadically and cannot be reliably reproduced or if a data integrity issue is apparent but the causal steps that 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 often need a copy of the site database where the issue was observed.

Examples of Best Practice Bug Reports

Following are two actual Bug Reports demonstrating these best practice elements.

Example 1

Totara sync not assigning managers if their accounts are “revived”

If a user has previously had an account (now "deleted") which is revived during the user import, they cannot be assigned as a manager during the same import.

Steps to reproduce

  1. Configure Totara Sync so the user sync does not contain all records. The following user fields should be imported:
  2. Import attached file managers-1.csv.
    This will create three accounts: admin10, admin11 and admin12.
  3. Import attached file managers-2.csv.
    This will delete two accounts: admin11 and admin12.
  4. Import attached file managers-3.csv.
    This will revive update (and revive) all three existing accounts and also create six new users. This CSV specifies manager assignments for all six new users.

Expected outcome

All of the users from managers-3.csv should exist and the all of the ARTYxx accounts should have manager assignments.

Actual outcome

Only admin10 will be assigned as a manager; the other manager assignment are ignored.

There is no warning or error message in the sync log to indicate the manager assignments have not occurred.

Follow up

  1. Import managers-3.csv again.
  2. Observe that all manager assignments are now correct.

Example 2

Quiz submission emails do not contain body content

Reported by subscriber. Replicated in Totara 2.6.5.


The strings for 'emailconfirmbody' and 'emailnotifybody' is not present in the body of quiz notification emails, only the subject is shown.



  1. Create a course.
  2. Create 2 test users.
  3. Create a quiz with one question.
  4. Assign one test user to the course with a role of 'Trainer/Teacher' and assign the second test user to the course with a role of 'Learner/Student'.


  1. Go to 'Course > Users > Permissions'.
  2. Select 'Leaner/Student' from the 'Advance role override' drop-down and set 'mod/quiz:emailconfirmsubmission' to 'Allow'.
  3. Select 'Trainer/Teacher' from the 'Advance role override' drop-down and set 'mod/quiz:emailnotifysubmission' to 'Allow'.
  4. Log in as test user with 'Learner' role and complete quiz successfully.


Emails should be received for both the Learner and Trainer users, but no body content shown which should contain the content for strings 'emailconfirmbody' and 'emailnotifybody'.


Emails should be received for both the Learner and Trainer users, with body content shown from strings 'emailconfirmbody' and 'emailnotifybody'.

How does Totara provide bug fixes?

Software updates are provided via patches in minor point releases and/or major new releases.

Minor point releases (e.g. 2.7.6, 2.7.7, 2.7.8, etc.) predominantly contain bug fixes and minor improvements. These are referred to as "stable branches" and are delivered roughly on a monthly schedule.

Major releases (e.g. 2.7, 2.9, 9.0, etc.) predominantly contain new functionality and bug fixes that cannot safely be delivered in stable branches due to the nature of the software changes. These are delivered roughly 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 2.5.32, 2.6.25 and 2.7.8. However, patches are not backported to earlier point releases within the same stable branch. For example a patch that is provided in 2.7.8 will not be backported to 2.7.6.

On this page

  • No labels