HelpDesk

Terminology
Decide on the structure of HelpDesk projects
Connecting mailbox to Easy Redmine
How to set up project configuration
How to set up project configuration – details
How to work with ticket processing
How to configure mail templates
How to configure global settings
Filter "Need reaction"
HelpDesk-users
Corner situations

These instructions will go through all the steps to configure HelpDesk from the UI. From connecting mailboxes to Easy Redmine, through project settings, to finetuning the dashboards. This is not a technical manual to configure cron (or scheduled tasks on the server side). Cron must already be configured in order for HelpDesk to function. Instructions to set cron are here.

 

0 Terminology

Let's first start with a glossary of used terms in the following manual.

Mailbox - an email address connected to Easy Redmine, from which received emails are processed into tickets in respective HelpDesk projects
Ticket - task created from a received email in a mailbox, or a task internally created by clients in a HelpDesk project
HelpDesk project – a project connected to HelpDesk, where tickets can be created
Domain – the second part of an email address. For example, from email worker.Joe@client.com domain is just client.com
Keyword – word or a string of words contained in the mail subject
SLA - service level aggreement. In simplified meaning used in Easy Redmine, contracted time to react by company to tickets submitted by client. Calculated in hours
Original email – Email sent to a HelpDesk mailbox from which the ticket was created
Operator - this terms is going to be used for the support worker, who works with the tickets

 

1 Decide on the structure of HelpDesk projects

Depending on whether you want to have a single project for all tickets or differentiate HelpDesk mailboxes, or even have special projects for different clients, you need to decide about the structure of the projects before any configuration starts. This decision will affect some further steps listed in this manual.

Here are the possibilities:

1.1 Single project for all tickets

If you are only going to have one project, which gathers emails from a single mailbox, there is no decision to make >> all emails sent to the mailbox create tickets in the same project.

Example: All your clients send support requests to support@mycompany.com

It doesn't matter which level this project is, basically it lives its own life within any part of your project structure. However, if you are planning to start with a single project and later continue expanding HelpDesk, you should see the options below.

1.2 One mailbox, more HelpDesk projects

Example: You use the mailbox support@mycompany.com. All emails received go into a general project. But you have one client, who has a special project and special conditions > emails FROM domain client.com are processed in the special project.

Of course, you can have a more customers separated this way. In this case, the project structure may look like this:

Another option is to have the Default HelpDesk project on the first level and the special projects beneath it.

A different way, which sometimes may be used is a structure:

>Client1
>>Project for commerce
>>Project for implementation
>>Project for HelpDesk

>Client2
>>Project for commerce
>>Project for implementation
>>Project for HelpDesk

However, this is not recommended if you are planning to gather tickets from various problems to some aggregate lists, statistics or summaries.

1.3 More mailboxes, no special client projects

Example: You are using mailboxes support@mycompany.com, info@mycompany.com, it@mycompany.com and emails are only sorted according to the mailbox, not according to the sender.

In such case, you can have the 3 projects on the same level and possibly beneath a main project covering them all.

These projects can be completely unrelated and falling to separate sections of your organization, they can be in different project trees (under different top projects).

1.4 More mailboxes, with special client projects

Current Easy Redmine HelpDesk functionality allows to separate clients solely by the sender and not by a combination of sender and receiving mailbox.

Example: You are using mailboxes support@mycompany.com, info@mycompany.com, it@mycompany.com. You have a special client sending support requests from domain client.com

The recommended structure is:

When we return to the project structure in general, there is some further consideration to be done. If you are aiming to integrate HelpDesk processing with a different department of your organization (for example development), you may want to consider putting HelpDesk projects a little bit deeper in the project structure.

Correct project structure will enable you to generate various reports, listings, statistics across more phases of your business.

 

2 Connecting mailbox to Easy Redmine

Now we can start with the actual setup of HelpDesk components. To have Easy Redmine process mailboxes, they need to be connected in the following way.

2.1 Administration >> HelpDesk >> All Mailboxes >> Add Mailbox

2.2 Enter valid credentials of your mailbox – click Test to make sure Easy Redmine can reach the mailbox

Setting notes:

• Active - mailbox is scanned regurarly by Easy Redmine for new unread messages. If disabled, Easy Redmine doesn't check the mailbox. But you can keep the mailbox in Easy Redmine for possible future use.
• Use different sender - when user on the mail server is not the same as mailbox (for example, HelpDesk-mail-user). Enter here the valid malibox, which is represented by the user.
• SSL - if you use an SSL certificate on your mailserver
• Enable OAuth – OAuth 2.0 protocol is used by hundreds of well-known services as an alternative authentication method. As for the HelpDesk's mailbox, it can be used to verify the sender's credentials using an external application, currently supported are Google Workspace (formerly G Suite) and Microsoft Exchange accounts. You need to read OAuth 2.0 documentation of the other application to know what exactly to enter in each field. Of course, you need to have admin access to the other application to find the required information, such as site URL, client ID, client secret, authorize URL, token URL, scope, etc.
  
• Folder - if you want Easy Redmine to only check certain folders for unread emails.
• In success move to – if an email is processed correctly by Easy Redmine (ticket has been created), it will be moved there
• In failure move to – if an email is processed incorrectly (ticket has not been created), it will be moved there

After testing the connection, click Save.

2.2.1 Where to find OAuth 2.0 credentials for Microsoft and Google accounts

To connect Easy Redmine with a Google Workspace account using OAuth 2.0 protocol, you need to create an account on the Google Cloud Platform, obtain the necessary credentials provided in there, and copy them into the mailbox settings in our application. Some useful instructions can be found here.

To connect Easy Redmine with a Microsoft Exchange account using OAuth 2.0 protocol, you need to create an account on the Microsoft Azure portal, obtain the necessary credentials provided in there, and copy them into the mailbox settings in our application. Some useful instructions can be found here.

Access tokens have a limited lifespan (maximum 6 months), you cannot create unlimited ones. After this time, the mailbox will stop working and a new token will need to be generated and re-entered into the application.

An OAuth 2.0 access URL of the form "/organizations/oauth2/v2.0/authorize" is valid only if access to the application is enabled within the organization. Otherwise, the access URL must be of the form "/[TENANT_ID]/organizations/oauth2/v2.0/authorize". The correct settings can be found in the Endpoints section.

When two-factor authentication (2FA) is set up in Microsoft Azure, all connected mailboxes need to be refreshed.

2.2.1.1 Error "User is authenticated but not connected"

This is because the selected Azure user through whom the mailbox is registered does not have permission to access the mailbox. In this case, it is not enough if the user is an administrator as he needs to be licensed to use Office 365. If the user has delegated permission (he is not allowed to add access to the mailbox since it requires approval by e.g. an administrator), he needs to get the appropriate scope permission in Azure and disable this option at the same time.

Solution:

• The user must either be the direct owner of the mailbox he is accessing (thus having the necessary permissions to do so).
• Alternatively, he can be another (licensed) user who has been granted access to that mailbox.

Another possible problem is that the account is created as POP3 instead of IMAP. POP3 does not support OAUTH in the system.

Solution:

• Make sure that the account is set as IMAP in both azure and in Easy Redmine.

2.2.1.2 Error: Microsoft Help Desk connects successfully but stops working after some time

You forgot to enable the right for offline access.

2.2.1.3 Use case: Many mailboxes, one super Help Desk user

If you have multiple Help Desk mailboxes set up within Microsoft Exchange and you want to delegate access rights to all of these mailboxes to a single user, you can do so through the Microsoft 365 admin center >> Admin centers >> Exchange.

You will be redirected to the Exchange admin center section. Here, click on the Recipients >> Mailboxes tab and select the mailbox whose access right you want to delegate. A right pop-up sidebar will open and click Delegation.

Below, notice the Read and manage (Full Access) sign with an Edit button to click on.

You can then search for and add users who become members of this mailbox with the same rights as the mailbox owner.

The user you select must have Help Desk administrator rights on the Easy Redmine side.

2.2.2 Enabling OAuth 2.0 Authentication with Azure Active Directory

When you use OAuth 2.0 authentication, you get access to a web service from a client application. The way you do this depends on the grant you use. In this tutorial, you will learn how to configure the client credentials grant type for applications in Azure Active Directory.

2.3 Configure frequency of mailbox scanning

Right click on the mailbox and choose Settings

Now you are back to the mailbox settings, but with an additional setting. By default, it is set to Every 5 minutes. But it is generally recommended to have this setting around every 10 minutes. If you have many mailboxes connected to Easy Redmine, this automatic scanning task may take a longer time and overload your server with too frequent scans, which will slow down the whole application.

Button notes:

• Execute – manually start the mailbox scanning
• History – view past mailbox scanninngs
• Delete – remove mailbox from Easy Redmine scanned mailboxes
• Deactivate – deactivate automatic mailbox scanning

2.3.1 Server interval vs application interval

In settings you will find the setting for mailbox interval. This interval can be set to any number. However, the lowest interval is determined by the cron settings on the server. The cron determines the lowest possible interval.

Example:

• The setting is set to 5 minutes, the cron is set to 10, it will run every 10 minutes.
• The setting is set to 15 minutes, the cron is set to 10, it will run every 15 minutes.

1. On the Cloud solution, the interval is set to 10 minutes and cannot be lowered. This is because there are multiple applications on one cloud server, and the settings are applied to all of them. A shorter interval could potentially cause performance issues.
2. On a private cloud solution, where one application is on one server, there is an option to adjust this. The private cloud is a paid service, more information can be found here. The advantage is that since you are on the server yourself, there is not as much load on the cron, and the settings also only affect your application.
3. The same applies to your own server solution as with a private cloud. Your app will be the only one on the server. You manage the server yourself, so you can customize the settings. The recommended interval is 10 minutes in all cases. However, it is possible to have an interval of even 1 minute.

We recommend caution; watch how the app behaves with the lower setting and adjust the interval accordingly.

2.4 Automatic disable

Processing mailbox in regular intervals takes server resources, especially if you have multiple mailboxes. For this reason, we have implemented a mechanism that automatically disables processing of mailbox after 7 times it failed to authenticate and download emails. Disable means that the field Active will be switched off. You will still be able to verify the settings, test and activate.

Why? To save your resources. Why should server keep pinging an unfunctional mailbox?

 

3 Project configuration

Mailbox is connected and scanned by Easy Redmine, but so far we haven't set where should the tickets be created. Before a project is connected to HelpDesk, tickets can not be created because, in general, every task requires a project.

This part is going to be split to different scenarios, according to the aim of each project.

3.1 Default project for mailbox

In the past chapter examples, this would be the projects Default HelpDesk, INFO – general, IT – general, SUPPORT – general, i.e not restricted to a particular domain of the sender.

1. Click the "Add to HelpDesk" option on the Project Dashboard of the selected project.
   
2. Select the mailbox for which the project will be default
   
3. Scroll down and Save

A complete explanation of all HelpDesk project settings will follow further in this chapter.

3.2 Special client project

From the examples in Chapter 1, these would be the projects: Bohemia Sun, Trains Francais, Client 123, Client ABC, Client XYZ, Client 1>>Project for HelpDesk, Client 2>>Project for HelpDesk

1. Select project
2. Fill in the fields highlighted below. Setting notes are under the screenshot
   
3. Scroll down and Save.

Setting notes:

• Default for mailbox - DO NOT select any mailbox if you want to set this project as a special client project
• Mails, domains, keywords processed into this project – all the settings in this section are with OR operator, which means that if at least one condition is met, ticket is created in this project
• Fill email to from - When this option is selected, the author's email will be automatically filled in new ticket.This option is useful when you have projects where tickets are created by real users, instead of via  processing incoming emails.
• Keyword – In this example, if an email received in ANY HelpDesk mailbox contains the whole string I am from company Client ABC, ticket will be sorted into this project. Do not use the same keyword string for more projects, only the first record in database with the string will use the designated keyword string
• Mail or domain – incoming emails are scanned for these values in FROM field of the email. In this example, the sender can be anyone with mailbox ending with clientABC.com or it can also be a specific person with a different email, but we want his tickets to be sorted in this project

Complete explanation of all HelpDesk project settings will follow further in the next chapter.

IMPORTANT: It is not the best practice to have one project set both as Default for mailbox AND specified for a certain mail or domain. Any sender will have their tickets created in this project, so you don't need to specify them. This kind of setting may cause confusion.

3.2.1 Closing and archiving special client project

When such a project is closed (in effect becoming read-only), tickets will not be possible to create within. Therefore, this project will cease to be a special client project and emails coming from domains set in the HelpDesk settings will be processed as unknown and fall in a general HelpDesk project.

The same goes to archived projects.

 

4 Project configuration – details

Now that we differentiated types of projects which can be used in HelpDesk, we can continue to explain the rest of the project settings. Once a project is connected to the HelpDesk, there are two ways to get into the project HelpDesk configuration page.

• Adminstration >> HelpDesk >> All HelpDesk projects >> Edit
  
• Project settings >> HelpDesk
  

4.1 Basic settings

Setting notes:

• Tracker – new tickets in this project will be created with this tracker
• Assignee – new tickets in this project will be assigned to this user
• Coworker – new tickets in this project will have these coworkers (multiple selection possible)
• Automatic ticket updating – depending on your workflow, there may exist some tickets which are factually resolved, being kept open. For such cases, you can set automatic closing according to the status and duration of non-update. In addition to closing the ticket, a follow-up e-mail from template can be sent automatically such as for the purpose of informing the sender that his ticket has been closed or asking him about his satisfaction with the ticket resolution.
• Contractual hours monthly – this is setting should be used only for special client projects, where clients have prepaid a certain number of hours of support per month
• Aggregated hours – the contract with the client may have the option of transfering unused hours from previous month to the next one. If client has 10 prepaid hours, but used only 7 of them during May, 3 hours will be transfered to June
• Remaining hours – how much is left. The pencil button allows to manually clear remaining hours – set to 0
• Aggregated start date – when the prepaid period begins; must be selected a day which is common for all calendar months, i.e. day 1-28
• Aggregated period – for what time period are the hours aggragated before they are reset to the original Contractual hours. If there are still 13 hours remaining by the end of the quarter (end of the quarter is determined by Aggregated start date), they will not be transfered to the new quarter. The hours will be reset to 10

The hours at hand are spent time entries in the project. Which exact entries will be explained further in this manual.

4.2 SLA

SLAs (Service Level Agreements) are key performance indicators in any HelpDesk project, especially for client contracts that impose penalties for SLA breaches. Tickets can originate from email or be created directly in the system by users with limited access. The method of creation slightly affects SLA settings.

4.2.1 SLA for Email-Generated Tickets

Setting notes:

• Name – Internal name of the SLA (for easier administration).
• Keyword – Still required for email-generated tickets. If an incoming email subject contains this keyword, the corresponding SLA (with specific hours, priority, tracker) is applied.
• Hours to response – Defines the deadline for the first ticket status change to take place.
• Hours to solve – Deadline to set the ticket to a closed status.
• Priority – Applied automatically to tickets generated by keyword-triggered emails.
• Tracker – Helps auto-classify incoming tickets (e.g., “Defect”).
• Count SLA based on working time – SLAs can be calculated either for business hours only or as 24/7.
• SLA working hours & working days – Defines the operational calendar (e.g., excluding weekends and holidays).

4.2.2 Ordering of SLAs

If multiple SLA rules exist, the system checks incoming emails for keywords in the order defined in HelpDesk settings. More specific keywords must be placed higher in the list.

Example:

• “Critical bug” SLA must be listed above “Critical” SLA to ensure accurate matching.
• Use * as a catch-all for general, unmatched subjects.

4.2.3 Reopening Tickets & SLA Reset

When tickets are reopened, SLA behavior now follows enhanced logic:

• If an SLA is already fulfilled or failed, reopening the ticket will not impact SLA status, deadline, remaining time, or fulfillment timestamp—unless settings explicitly allow exceptions.
• Suspended statuses like “Awaiting customer info” pause the SLA countdown. If the ticket is later closed directly from this status, the Resolution SLA is marked fulfilled using the timestamp of entering the suspended status.

You can still control SLA reset behavior using the setting in project HelpDesk >> SLA section:

• Enabled – SLA restarts from the time of reopening.
• Disabled – SLA continues from original creation time.

4.2.4 SLA for Internally Created Tickets

Internally created tickets (via UI) don’t use keywords. SLAs are matched by a combination of Priority and Tracker.

• Leave Keyword blank for such SLAs.
• If Tracker is omitted, only keyword-based rules apply.

By configuring workflows, you can restrict clients to use only specific trackers, e.g., “HelpDesk Ticket” or “Bug”.

4.2.5 SLA reporting

Major change since version 14.9.0

Up to version 14.8.x, SLA reporting was based on an entity called SLA events. Reports were built above SLA events, instead of the actual tickets, thus missing some important standardly used Help desk metrics. SLA events remain in the system, and the new SLA reporting is based on them. However, since version 14.9 and above, the critical attributes are mirrored onto the tickets, which allows for ticket based reports.

How it works

Each ticket has a dedicated SLA information section in the ticket header with information displayed separately for the First Response SLA and the Resolution SLA. For each of these you can see SLA status, Remaining time, Duration, Deadline and Fulfilment timestamp. SLA statuses within each ticket:

• In progress
• On hold
• Passed
• Failed

Each status has its own color for immediate recognition. Remaining time and duration are displayed in hh:mm format. Remaining time is green while still positive, and turns to red and prefixed by a minus once negative, at which point the SLA status changes to Failed. Responding or Resolving within the positive/green Remaining time will result in a successfully Passed SLA. Deadline and fulfilment timestamp are in date and time format. Remaining time, Duration and Deadline will respect your working days and hours if so chosen in the Help Desk project settings. They are stopped when the SLA is suspended such as when it is on status “Awaiting customer info”. Once the ticket resumes and in back in an active status, the Remaining time and Duration restart running and the deadline is moved forward by the amount of time it was on hold.

All of these SLA datapoints are also available in Dashboards and via API. This more granular and intuitive breakdown of data enables quick, easy, dynamic and precise SLA reporting. Previously the SLA events entity held such information but it is no longer needed to query it as everything is now on the Tasks entity. 

SLA events remain interesting for purely logging purposes, as they enable a quick and easy glance at who and when made what SLA-relevant change to the ticket. SLA events are located in the lower part of the ticket in a separate tab.

Summary of changes from 14.9.0:

• SLA events are no longer the primary tracking mechanism. They still function as historic logs, and a supportive entity.
• SLA events are created whenever ticket status changes or SLA recalculations occur.
• The global setting “Create SLA events from all statuses” has been removed.
• SLA event fields like Sla response, Sla resolve, etc., will be deprecated in version 15. During the transition, they still reflect updated SLA values.
• A new column SLA state has been added to the SLA events tab on ticket detail.

4.2.6 Working with SLAs

This chapter is more effectively explained in this video (6 mins, and possible to speed up).

Since version 14.9, updating a ticket's status will automatically affect the SLA and create an SLA event. Working with SLAs will now be exclusively tied to the ticket's status, eliminating the previous need of sending an email (up to version 14.8).

If you do have email templates associated with certain ticket statuses and the option to “Send immediately” is enabled in the email template settings, then updating the ticket status will also automatically send the right email. This effectively reduces all SLA management to a simple status change. Of course, the functionlaity remains, to manually send an email to the client, if your process is set up this way. See 5.1.2 for more info on manual emails.

If an SLA status is failed or successfully passed then further reopening and closing of the ticket will not change the SLA status, fulfilment timestamp, deadline, remaining time, nor duration; unless specified otherwise in the settings for reopening tickets, such as reset SLA at reopening which will reset it and run from the reopening time.

If a ticket's priority or tracker changes, the system auto-switches to the relevant SLA, recalculates it while keeping time elapsed data, keeping passed or failed status, and logs the change as an SLA event. When a support ticket is moved from one project to another, the SLA event does not recalculate. The SLA of the ticket remains from the original project, where such a ticket was created. SLA recalculation is triggered by a change of tracker and/or priority.

Since version 14.9, SLA events are newly logged at key actions like status changes or recalculations, capturing time and type of change. SLA event fields have been improved, including a new SLA state column for clearer tracking.

Each ticket now contains a dedicated SLA section showing:

• SLA Status – In progress, On hold, Passed, Failed.
• Remaining Time – Countdown timer until SLA is due (pauses when ticket is on hold, can become negative if overdue).
• Duration – Time elapsed since SLA started (counts up, never negative).
• Deadline – Deadline by which the SLA must be fulfilled; recalculates if ticket is unpaused.
• Fulfilment Timestamp – The exact moment the SLA condition was met (e.g., first status change for First Response).

This SLA section can be hidden from selected user types, roles or specific users or via:

• Administration >> User types >> Edit
• Administration >> Users >> Edit
• Administration >> Roles and permissions >> [Select role] - View SLA events

If either restriction is enabled, the user will not see SLA data on tickets.

4.2.7 SLA Recalculations

If a ticket’s priority or tracker changes, the system checks for a new SLA match:

• If matched, SLA is recalculated—retaining elapsed time and original status.
• If not, the current SLA remains.
• All recalculations generate a new SLA event.

4.2.8 Dashboards and Reporting

SLA data is now fully accessible via ticket-based dashboards using dynamic filters:

• SLA fields (status, remaining time, duration, deadline, fulfillment timestamp) are available for both First Response and Resolution SLA.
• Legacy fields like Hours to respond and Hours to solve are also included.

Note: Remaining time and Duration are shown only after SLA fulfillment, and only for closed tickets.

4.2.9 API and Automation

The updated Tasks API now includes all SLA fields available in dashboards, under the same conditions.

• SLA values become accessible only after fulfillment.
• Integration via n8n connector enables automated access to task SLA data. Look for Easy Redmine in the n8n marketplace.

4.3 Custom header and footer

This setting concerns HelpDesk email communication, i.e. communication in email generated tickets. You may customize emails from different HelpDesk projects, whether it is for corporate identity use, for terms specifications or even confidentiality disclamers.

Globally set header and footer of email notifications (Administration >> Settings >> Email notifications) will no longer be a part of emails sent from the HelpDesk.

4.4 Alerts

In order to prevent SLA from being violated, there is the possibility to use automated alerts, which notify concerned personnel about looming problems in the form of delayed tickets.

Another type of Alerts watches spent time in projects, where clients have prepaid a specific amount of hours of support (as explained in chapter 4.1).

Setting notes:

• Monitor support tickets due date – to be more precise Due Time according to SLA. If enabled, alerts will be generated when SLA deadline is nearing. Further settings explained below
• Monitor support tickets spent due time – watching of spent time on projects with specified prepaid monthly hours
• List of alerts which need to have a recipient set – these are preconfigured alerts, which only need to enter an email address, where the notifications should be sent
• List of configured alerts – alerts with no missing parameter
• By clicking on each alert, you will see the preconfigured parameters with possibility to edit them
• Warning/Alert: severity of the notice
• Support tickets due time – alert watches SLA resolve deadline (ticket closing)
• Support tickets hours to response – alert watches SLA response deadline (first change of status)
• Support tickets prepaid hours – alert watches spending of prepaid monthly hours on the project

Hours watched in the last alert are those which are logged on tickets, which are in trackers mentioned in the project HelpDesk settings.

Example: Default tracker for the project is HelpDesk Ticket. Some SLA is configured for the tracker Bug. The project contains other trackers (Task, Feature development), which are not used on tickets. In such case, the prepaid hours are only valid for HelpDesk Ticket and Bug. Spent time on other trackers is not taken into account for this alert.

4.5 Update/delete

Update – save changes made in the HelpDesk settings of the project
Delete – remove the project from HelpDesk. This doesn't mean deletion of the project as a whole, it will only remove connection of the project to HelpDesk.

 

5 Ticket processing

After the huge amount of settings explained until now, it is time to look at some practical implications, before we get back with another set of settings. We will start with a simple use case to demonstrate how the ticketing works and skip some features. They will be explained later on.

5.1 Email generated tickets

For correct handling of tickets created by email, you need to check that standard fields "email to" and "email cc" are active. You can check it in Global menu >> Administration >> Trackers >> HelpDesk ticket >> Standard fields. If these standard fields are missing, they must have been disabled by administrator.

5.1.1 Email is processed by Easy Redmine and ticket is created in the determined project

Notes:

• email to: The sender of the email from which the ticket was created
• Specification of the mailbox, from which the task was created
• SLA values – if violated, they are highlighted in red
• Parsed email - This is the text content of the email, including any images that were included in the original email. Images are now displayed inline on the ticket description or comments, making it easier for agents to view the full context of the customer's request.
• The full original email is also available as an attachment if needed.
  

5.1.2 Write a reply and update the ticket

To meet the SLA response, you just need to change the status. We do recommend to also send the client a confirmaton reply by using an email template. For the following examples, keep an open mind about the ticket communication, it is just to demonstrate how the communication works technically.

The manager wrote a reply to the customer about receiving the ticket, assigned it to an operator and changed the status. The reply will be sent to the client (email to) when you check the box.

Send quick email to customer from template

You have two options to send an email to the client. When updating a HelpDesk ticket, there is an option "Send quick email to customer from template" allowing you to choose an e-mail template of your answer for the ticket sender. When a template is selected, the e-mail is sent instantly and thus no more actions are required. When no template is selected, you still have the option to choose the template and confirm sending e-mail in the next step as usually (tick "Send email to customer (with preview) checkbox in the bottom and save). The purpose of this feature is mainly to save your time when sending emails to customers.

5.1.3 Send an update to external email (email to)

By hitting Save, you will save the updates made on the ticket and you will get to the dialogue of sending the reply to the client.

Notes:

• Mail template – if you have email templates configured, you can choose one. Or a template will be preset according to status. This feature will be explained in further chapters
• Mail sender – this will be shown to the client as FROM. The setting of the population of this field will be explained in further chapters
• Mail subject – custom or preset according to the mail template. By default, it is populated by the ticket Subject
• Mail recipient – sender of the original email. If there were other recipients of the original email in the CC or TO, they will also be added into this field.
• Mail reply to – this is always the HelpDesk mailbox to which the original email was sent
• Mail copy – you can add other recipients
• Mail body – if a template was not chosen, it will consist of the last comment on the ticket and the original email text. The content is editable.
• Attachments – you can choose attachments to send with the email. It may be some more recent emails or new files you uploaded when updating the ticket
• Send mail – email is sent to all recipients
• Don't send mail – you will return to the detail of the ticket

When we look back at the ticket detail, we see that SLA response has disappeared, because it was made.

5.1.4 The client replies back – how the emails are paired with a ticket

The client has received your reply and replies back. The reply will be added as a comment from an anonymous user ( a user who is not registered in the system).

Let's explain here how did the client's reply find its way to the correct ticket.

When, in the previous step, the manager sent external mail to the client, the email contained a hidden heading (as all emails do) with the ID of the ticket. By replying to the email, this header was contained also in the client's reply and, therefore, HelpDesk identified it and added the reply to the ticket with the same ID.

Here are all the ways received emails are paired to tickets in the system.

1. The hidden heading of e-mail, where the task ID is saved
2. The subject of the e-mail, where a combination of "#" and task ID is sought
3. If this isn't found, the subject is searched for a number alone

Accordingly, even if the client writes a new email to a HelpDesk mailbox and adds the ticket number (task ID) in the subject it will still be paired. Like in the following example.

New email to a HelpDesk mailbox:

Subsequent note in the ticket:

5.1.5 The last reply – ticket gets closed

One last reply from the operator, with which the ticket is closed. If the client replies again, the ticket will be reopened to a defined status (this setting will be explained further).

5.1.6 Ticket owner field

The ticket owner field is an optional standard field intended for use with HelpDesk tickets. With its drop-down list, it allows you to select one user out of all internal users already created, and this one user is considered the owner of the ticket. The field can be enabled or disabled for any tracker where you may need to have it (go to Administration >> Trackers >> HelpDesk ticket >> tick the field and save). By default, Ticket owner field is disabled so HelpDesk managers must go to Administration to enable it for a specific tracker. Based on this field on HelpDesk tickets, HelpDesk managers can easily see how many tickets were received, closed/solved or updated according to their ticket owner. So this may significantly improve/simplify HelpDesk insights (dashboards, statistics) and reports for a defined time period. Workflow settings, as well as Action buttons, may be applied to Ticket owner field just like any other standard or custom field.

5.1.7 Email to, cc select from various data sources

In fields Email to and Email cc added ability to search for emails from data sources:

• Personal contacts (CRM)
  
• Stakeholders
  
• Accounts (CRM)
  
• HelpDesk users (Help desk)
  

This feature is disabled by default. To enable it, go to Administration >> Plugins >> Email field autocomplete - Edit and activate feature Email field autocomplete and needed data resources.

Without enabling any of the data resources, the feature natively searches through users. The user emails displayed are determined by the current user's User Type and visibility settings.

How it works

If enabled the task fields Email to and cc act as autocomplete.

5.2 Internally created tickets

If the client submits tickets by directly within your system, the workflow can be defined as if you were working with any other tasks. You will allow the client to create HelpDesk Ticket or Bug. They will initially be in the default status (most time called simply New). Then communication goes back and forth between client and the operator by series of ticket updates and by changing the assignee, which is necessary to keep all users active in the communication. SLAs are monitored as in the email generated ticket Response: Change of status; Resolve: Closing the ticket.

5.3 Tickets created via the REST API

There is a possibility for tasks/tickets created via the REST API (for example from a web form) to look like HelpDesk tickets created from e-mail. Just send the "easy_helpdesk_mailbox_username" parameter via the API, for example: issue[easy_helpdesk_mailbox_username] = 'support@company.com". This will cause the newly created task to look like a HelpDesk ticket from the given e-mail address, the SLA settings will be applied accordingly and a thank-you message will be sent to the sender.

 

6 Mail templates

It was already foreshadowed during the last chapter, but without a proper explanation of the processing, it would not be as easy to understand as it will be now. The last HelpDesk menu item we haven't introduced.

Email templates bring a certain level of automatization and formalization of the communication with clients, by which they recognize your company as a professionally dealing one.

An important property of Mail templates is that they are configured per mailbox, you can't use a template from a mailbox IT@mycompany.com for emails sent to support@mycompany.com.

6.1 Creating a mail template

There are effectively two types of mail templates: autoreply and standard template. Because they are not configured differently, we will explain both cases at once.

6.1.1 Add new template

To make a new template click on the button on the right.

6.1.2 Basic attributes

Here you can see what the page for creating a new template looks like. You will be able to choose to what mailbox the template belongs to, and for which status it will appear. 

Setting notes:

• Send immediately - an email notification will be sent every time a task's status changes.
• To avoid unnecessary notifications, it is recommended that workflows be configured to prevent tasks from returning to the same status multiple times.
• This feature ensures email notifications are triggered immediately when a request is created or updated, bypassing the usual delay caused by waiting for the next cron job. While this is beneficial for instant status updates, it may lead to duplicate emails if request creation is enabled via email.
• Avoid using the "Send Immediately" option for all types of notifications if SLA rules are configured. This feature should be restricted to status changes only to ensure notifications are relevant and to prevent excessive or redundant messaging.
• Use for mailbox – which mailbox will have this template available
• Task status – according to this status, the template will be prefilled in the dialogue when sending the reply to an external mail (see chapter 5.1.3.)
  • To use the template as autoreply to newly created tickets from email, set the status to the default one (as configured in administration >> task statuses). In effect, when a ticket is created from an email, the autoreply according to this template will be sent immediately. It can be used to confirm to the client that the ticket was created and what the next steps will be.
  • You may leave the status empty, in which case it will never be prefilled automatically in the send mail dialogue, but users will be able to choose it manually
• Subject – what will the subject contain
• It is recommended to include the task ID in the autoreply – if you have many tickets with the same client, you will be better able to distinguish between them, when talking to the client
• You may also use the actual subject used the client's original email

6.1.3 Dynamic tokens and mail body

Dynamic tokens can be used to provide particular ticket information to the client. In a template, they are entered as one of the below, and in the email sent to the client, they will be replaced by the actual value from the ticket.

A simple example of an autoreply.

6.1.4 Important dynamic tokens

If you are going to use mail templates effectively, it is necessary to include the token %task_note% into the template. It will use the comment you last added to the ticket and surround it by the other text in the template.

To add a corporate signature into the outgoing emails, use the token %user_signature%. It will use the HTML signature of the current user (who is updating the ticket) that can be set on the user's profile.

Example: Let's devise a simple template containing comment of the support operator, total time spent on the ticket and company signature of the user.

This is how the template looks like.

This how the operator writes the comment ticket update.

And this will be the sent email according to the template.

Note: When using email templates together with special heading and footing of emails on a certain project (Chapter 4.3.), the project header and footer wrap the whole email send to the client, not just the email template, or just the part which added by the last comment.

6.2 Default email template

It is possible to select a HelpDesk email template as default. Meaning that when you are sending a comment to a customer, there is a higher chance that a template is preselected (leaving less manual work for the support operator).

The behavior is as follows:

Prerequisites

• one email template can be set as default
• every email template must have a linked mailbox
• you can have more mailboxes in your system
• email template may be (but it is not required) connected to a certain status

Situations

• a ticket is created manually (not from email) - template from a is preselected according to status; if not found, the default template is preselected
• a ticket is created from a different mailbox than the one with which the default email template is used – template with this mailbox is preselected based on the status (same as currently) => no template is automatically preselected if using status for which there is no template assigned
• a ticket is created from the mailbox with which the default template is used – the template is preselected based on the status – if no such template is found, the default template is preselected

 

7 Global settings

Now that we have gone through the whole usability, we can finish the rest of the settings remaining to be explained.

Setting notes:

• Sender – which email is listed as FROM on ticket replies to client (in relation to Chapter 5.1.3.)
  • Current logged user – user who is updating the ticket
  • Default from mail notification – email which is used to send standard notifications from the system to users. Set in Adminsitration >> settings >> email notifications
  • Mailbox address – email, which received the original mail from the client
  • This setting is loosely tied to the last checkbox Allow custom sender – if enabled, you can set a custom email as the sender on project HelpDesk settings. If a project has an email filled in the setting, it will override the Sender setting
• Enable updating task attributes – if enabled, it is possible to change certain attributes on the ticket by email. For example, by writing priority: High in the mail body, you would change the priority accordingly. This is a rather advanced function and it is not recommended to use with clients
• Accept autogenerated mails – for example newsletters
• Ignore CC of received emails – if enabled, emails in the CC are not processed and used in the field "email to" of the ticket (Chapter 5.1.3. note about mail recipient)
• Change status after client response to – everytime a client writes a reply which updates the ticket, status will be changed accordingly. This is particurarly useful when tickets are put to a closed status after a reply was sent by the operator. Unless the client replies back with some additional question, the ticket will stay closed and hidden from the active listings. When the client replies, ticket would be reopen and back to active queue of open tickets
• Suspend SLA for ticket when status is – these are statuses, when SLA deadline is not determined, because the ticket is waiting for input from the client, without which the operator has no chance of providing support
• Count SLA for ticket when status is – when the SLA is normally measured. With these functions, you can nicely set the ticket cycle. For example, operator asks the client for more information, puts the status to pasive and SLA is paused. After client replies, status is changed to consultation and SLA is recalculated according to the remaining time to SLA deadline, when the ticket was replied to

In version 12, Help desk received another interesting metric - Tickets resolved by support. You will be able to report total number or ratio of tickets that have never left the support team.

How it works

1. Firstly you have to define which users are members of support in Help desk >> Help desk settings - Resolved by support settings
   
   
   
2. Settings for subtasks/related tasks will determine whether tickets resolved by support can or cannot contain subtasks or related tasks
3. Now, we recommend to push the button in help desk menu - Recalculate
   
   This will evaluate tickets from the last 90 days
4. Finally, go to task list and find the filter Resolved by Support
   
   

This filter will show tickets that were only assigned to members of support (as per setting in point 1). Based on settings on point 2, tickets that contain subtasks or related tasks may or may not be counted as resolved by support.

 

8 Filter "Need reaction"

"Need reaction" is an attribute of HelpDesk tickets and CRM cases. By default, this attribute is set to "No". It will change to "Yes" when a ticket/case is assigned to a person who answers to it by sending an email message instead of assigning it back to the sender in the Client zone or Easy Redmine. In such a case, the assignee of the ticket/case remains unchanged and so the intended recipient may not notice that the update has been made. To prevent this, the recipient should regularly check all items with "Need reaction" attribute set to "Yes" so he easily gets to know that there is something new he should check or answer even it's not assigned to him. Or you can use it when you need to "mark" some customer ticket you already answered but there is still some work on it and you need to inform customer later again. Using "Tasks from filter" widget, you can simply create a box on your Dasboard, CRM Dashboard or HelpDesk Dashboard like the one below.

 

9 HelpDesk users 

Among the biggest additions to the HelpDesk in recent years are so-called HelpDesk users. Their purpose is to simplify the management of Client access to your Easy Redmine. Also, it makes it a lot easier for the Clients themselves to submit tickets and communicate with your operators directly in the application.

9.1 Preconditions

Management of HelpDesk users is under permissions View/Manage HelpDesk users under HelpDesk section in Administration >> Roles and permissions.

Another setting to check before you start creating HelpDesk users is Administration >> Dashboard Customisation >> HelpDesk users >> Templates overview. There should be an existing page template in a basic "starter" configuration. It is important that there is a template that is set as default – this template will be applied automatically to new HelpDesk users. Otherwise, your HelpDesk users would have an empty page after they log in.

The HelpDesk user page contains 3 types of widgets:

• New ticket form – It has no settings, just place it for the utmost convenience of your Clients.
• HelpDesk tickets – list of tickets created by the HelpDesk user. Each user can only see tickets that they themselves created. This widget is configurable, such as all other "list" widgets in the application. It contains fields visible for HelpDesk users in tickets. If you intend to show both open and closed tickets for the HelpDesk users, we recommend showing them in separate widgets.
• Noticeboard – just in case you want to share some custom information with the Clients.

9.2 HelpDesk user management

The list of HelpDesk users is available as a separate item in the control buttons on the HelpDesk dashboard.

All attributes are required:

• First name
• Last name
• Email = Login
• Language
• Project – this is the project where tickets from this user will be created. Only open projects that are connected to the HelpDesk can be selected here.
• Password – during user creation you must enter a password with an option to generate password token, so that the user may set their own password via link in an email. During user edit, a password change is obviously not required.

Additional permissions:

Each user can be granted additional permissions to view  and manage all tasks

View all tasks = Allows the help desk user to see all created tickets under the same project (created / assigned to other helpdesk users), but it won't allow you to access all non-helpdesk tasks

Manage all tasks = Allows the help desk user to Edit specific fields from already created tickets (Title, Description and also add a new attachment; but not edit the old one).

Use case

A client has a special project for their tickets in your Help desk. There are more users logging into the help desk portal and submitting tickets on behalf of this client. One of these users needs to see all the submitted tickets, because his role requires to evaluate the service that you deliver.

9.2.1 CSV import

From version 11plus.2.0, it is possible to import help desk users via CSV. Please contact your consultant about this option.

9.3 Logging in as HelpDesk user

HelpDesk users log in via a different entry point than regular users. On the login screen beneath the login button, you can find a switch. To direct your Clients to HelpDesk login, use URL /helpdesk/login. As mentioned above, email is used as the login name.

IMPORTANT: HelpDesk users are technically independent of regular users. You may use the same email for one regular user and one HelpDesk user.
Although, practice suggests this should not be the case. You either set up a HelpDesk user account, or you decide that the user needs a full account. Both types of accounts for one person should only be used for testing purposes.

If you set up the same email address for both a regular user and a HelpDesk user, the behavior depends on the HelpDesk general settings:

• If "Current logged user" is selected - the HelpDesk author will be set as the HelpDesk test user.
• If "Mailbox address" is selected - the HelpDesk author will remain empty.

After logging in, the portal itself consists of the homepage, which was configured by an admin, but is not configurable by the HelpDesk user themselves. In the top right corner, the profile can be accessed, including edit mode. Next to it, the log out button. By clicking on an existing ticket, or creating a new ticket, the user will be redirected to the ticket detail, where they can add comments or attachments. To return to the homepage, just click on the logo in the top left corner.

HelpDesk user has no roles and permission setting and you can't provide them additional access to certain areas. The listing above is all that they can access. You should not send them any links to items in your application. It would only lead to access denied message.

9.3.1 LDAP authentication for HelpDesk users

From version 11plus.2.0, help desk users can be authenticated via LDAP.

The configuration is in Admin >> Plugins >> Help desk users >> Edit - New authentication mode.

The form is identical to regular LDAP configuration, the only difference being that it applies to help desk users => on page /helpdesk/login

9.4 Working with Tickets

From the Client's Perspective

A HelpDesk user creates a ticket using the New Ticket form on their homepage. The only available attributes are Subject, Description, and Attachments. The philosophy is that clients should not worry about organizational matters when they need assistance from your customer service. They simply describe their issue and expect a solution. No project selection, no categories - all of this is managed by your support team.

The ticket is created in the project directly assigned to the HelpDesk user. The Email To field in the ticket is populated with the HelpDesk user's email. This user is also set as the HelpDesk ticket author, which is a hidden attribute (not related to the Author attribute, which is a general attribute of all tasks in Easy Project). This ensures the user can always see the ticket, even if it is moved to another project.

Ticket details visible to the HelpDesk user:

• Subject
• Description
• Attachments
• Status
• ID
• Last Update (time and date)
• Created (time and date)
• Non-private comments in the history

IMPORTANT: The limited ticket view for HelpDesk users is accessible under a different URL than the regular ticket view. For example, ticket no. 123 will be visible to the HelpDesk user under the URL /easy_helpdesk_issues/123. The regular link /issues/123 is not accessible to HelpDesk users.

Updating a ticket from the HelpDesk user's side is again very simple: they can add a comment and/or an attachment.

What happens when a client adds a comment?

• The status changes automatically based on the settings in HelpDesk >> HelpDesk Settings - Change status after client reply to (explained in Chapter 7).
• The Need reaction flag is set automatically (explained in Chapter 8).

This logic is based on the existing behavior of ticket <--> email communication, where the client simply sends an email and does not worry about how it is processed on the HelpDesk side. Now, the client has access to the ticket and can view it in a more readable structure instead of deciphering it in their email inbox.

From the Operator's Perspective

In simple terms, not much changes for the operator when working with tickets. However, some aspects should be noted.

The most important thing to keep in mind is that HelpDesk users have a limited view of each ticket. This limited view is located under the URL /easy_helpdesk_issues/123 => the regular URL (/issues) cannot be used to share the ticket link with HelpDesk users. The Copy HelpDesk Ticket Link button is available in the top-right corner of the ticket detail (highlighted in the image above).

Remember, HelpDesk users can only see non-private comments. If you are writing a comment for a HelpDesk user, make sure to uncheck the Private checkbox.

The client sees all attachments in the ticket. If you need to share sensitive files with your colleagues, do not upload them to the HelpDesk ticket.

How to notify the client about your message? There are no fixed email notifications for HelpDesk users. To send emails to HelpDesk users, continue working with tickets generated purely by email (Chapters 5.1.2 and 5.1.3).

How to track tickets responded to by HelpDesk users? Again, no change: tickets are automatically set to a status based on the existing settings. At the same time, the Need reaction function is enabled, so you will not miss the ticket.

What about the legal assignee? The assignee should be the person currently handling the ticket. A ticket cannot be assigned to a HelpDesk user because, as mentioned, they are not a regular user. Essentially, this does not differ from standard email tickets where the author is anonymous and is not reassigned back to the client. Use a clear status to inform HelpDesk users about tickets that have been resolved and may need some input from the client.

9.4.1 Assign Existing Tickets to HelpDesk Users

The story is very common: You have been using HelpDesk for some time. Now, you are upgrading to version 11+ and decide to give your clients access as HelpDesk users. The big question is: how do you give them access to their existing tickets?

The answer is a simple tool that connects HelpDesk users with already existing tickets. It works as follows:

1. Go to the list of HelpDesk users.
2. Click on "Fill HelpDesk Author"
   
3. Select a filter – which tasks should be made accessible.
4. Select the HelpDesk user.
5. Confirm.

If you made a mistake, it is always possible to revoke access to these tickets by selecting HelpDesk user <<none>>.

9.5 User Fields on the Ticket Form

Relevant types of user fields (amount, yes/no, date, key/value list, link, list, dependent list, text) can be displayed or used by HelpDesk users. First, ensure user fields are enabled for projects and task types used by HelpDesk users. In task user fields, there are two options:

• Visible to HelpDesk users – The field content is displayed in the ticket detail on the HelpDesk portal.
• Editable by HelpDesk users – The HelpDesk user can fill out the field when creating a ticket. Editing existing tickets is still not possible, as customers are not responsible for managing ticket attributes.

9.6 Our Recommendations

The HelpDesk user function can be highly customized, so we would like to share some best practices for inspiration.

Intuitive naming of ticket statuses

• especially the status in which the ticket is handed back to the client. It should be clear that the next move is on their side if you need a response or that the ticket has been resolved and will be automatically closed without further action.
• the HelpDesk user sees the status; it should be clear what is happening with the ticket without explicit operator comments.

Keep the homepage simple for HelpDesk users

• It goes without saying that only one New Ticket module should be added to the page.
• Separate ticket lists based on usage. For example, separate open and closed tickets into different modules. Another approach is to separate tickets that require action from the client and others (regardless of open/closed status). Just don’t overdo it with the number of different lists.
• Ticket lists have customizable headers – use them to benefit your clients.
• Organize ticket lists logically.

Adding a ticket link to email templates

• You will likely continue using email templates to notify clients of ticket updates. Adding a link to the ticket for clients to access it will be helpful. The link is in the format: https://[your_application_URL]/easy_helpdesk_issues/%task_id_without_hash%.
• If the client clicks the link while not logged in, they will be redirected to the /helpdesk/login page.

Reports on tickets created by HelpDesk users?

• You can add modules like lists, reports, charts, trends, general indicators, and time series to dashboards (e.g., the HelpDesk dashboard) and select HelpDesk ticket entities for various types of reports.

Set one email template as default

• as explained in Chapter 6.2.
• because tickets created by HelpDesk users are not automatically linked to a mailbox, operators may have a wide selection of email templates when sending an email. Simplify their work by setting one template as the default.

Corner situations

• The situation when a task assignee is not a member of the project can occur in the following cases:
  • the assignee was removed from the project but the tasks remain assigned to him,
  • an automatic ticket updating process is set within the HelpDesk module in such a way that some tickets are automatically assigned to a former project member.
• Information about SLA Response appears in the task detail only when the task is in the default status, which is defined on a respective tracker.
• We strongly recommend that you do not change the priority of a ticket when the ticket has suspended SLA, as such an action would adversely affect the correct calculation of the SLA on that ticket.