Polar Help Desk 5 in a Nutshell

Enter a topic name to show or a new topic name to create; then press Enter

.

Users and Contacts, Teams and Accounts

There are two types of people who use help desk: Users and Contacts.

1. User is anyone who deals with incidents, solves incidents, reports, manages them: he is supporter, manager, administrator, etc.
2. Contact is anyone who needs support or service and he opens incidents to ask for help.

There are two types of groups of people who use help desk:

1. Team is a group of Users.
2. Account is a group of Contacts.

Although they usually are not, each User can be in multiple Teams, and each Contact in multiple Accounts.

Number of Users and Contacts is unlimited.

Incidents, their Status and Work Orders

In order to solve incidents (assign an incident to himself, edit an incident, reply or save an incident) User has to be a named user which means that he has to have a License.

Over time, Incident Status changes from New, to Planning, In Progress, Waiting, Completed or Closed. Example: when User replies with some answer, he sets Incident Status to Waiting, and as soon as Contact replies him, Incident is automatically set to status New again. Work Orders can be attached to Incidents if needed and their progress can be monitored in the same way.

Typical half-life of Incident is:

1. Contact Tom logs in to help desk, clicks on Create New > Incident, and then explains his problem and clicks Create
1. or he just sends email to support email address, Email Automation that converts emails to incidents will take care of that.
2. User Brian sees this Incident in the list of all incidents, status of this Incident is New, so he clicks on it.
3. He is a named user so he can solve it:
1. he reads the Description to see what problem it is about
2. he clicks Assign To Me button to assign it to himself
3. he writes his answer in Resolution field, changes status to Waiting, and clicks Save
4. System sends email to Contact Tom with Resolution text, and notifies anybody who should be notified about that.

Who should be notified? This is set in Email Notification chosen for Team user Brian is in.

Email Notifications and Email Templates

Email Notification is a set of rules who should be notified on which events. There can be many Email Notifications, each Team chooses one. Those rules then apply to every incident assigned to that Team.

1. For each incident event possible (status changed, incident updated, priority changed, new incident created, etc.) you can choose whom to notify (user this incident is assigned to, contact who reported incident, every member of team this user is in) -- notifications can be fine tuned indeed.
2. You can also choose which Email Template will be used on which event. You can build different Email Templates to suit different teams and events, using simple scripting language.

You can see all options easily if you log in as administrator and go to Administration > Email Notifications at http://development.polarsoftware.com/ccnetphd

Email Integration and Automation

Each Team has Email Account. Emails are automatically downloaded to help desk (if that email account is enabled) and those emails get converted to incidents or not, depending on Email Automation Mode chosen:

1. Convert email to incident if email address is of a registered contact, else leave it in email list.
2. Convert email to incident, and if email address is new, create contact with that email address.
3. Do nothing, just leave email in email list. Supporters will sort them out and convert to incidents later.

Polar Help Desk 5 is completely integrated with multiple email accounts, it downloads emails, sends emails, converts them to incidents and sends notifications.

Priority Escalation and Service Levels

Depending on Service Level chosen for Incident (or agreed upon in Service Level Agreement) Incident Priority automatically escalates through time in defined time intervals.

Languages and Customization

Default language can be set in Settings. Administrator usually does that, to see it go to Administration > Settings. If some particular Team uses some other language, it can be set for that Team: this language is then displayed to members of that Team instead of default one. If some User in that Team wants to use some third language, he can set it on his profile, then he'll see interface in his preferred language. All of that applies to Accounts and Contacts too.

Each label on button, message, link in navigation can be changed. All you have to do is go to Administration > Languages, click on particular language, change some labels and click Save. You can create new languages and import language from file.

Reports

You can build your own reports through help desk interface using client side and server side Java Script.

API

API enables you to integrate any application with the Polar Help Desk 5, including web applications. It allows you to connect to the help desk using HTTP protocols and perform any task you could perform via user interface.

Design is completely RESTful , you are using four HTTP Methods (POST, GET, PUT and DELETE) on logically designed URI Resources. With those four methods you get simplicity, with URI Resources abundance. Programmable web is machine friendly as well as user friendly. You can use API to synchronize users with your other application, create incidents from other applications, extract specific data in an automated fashion, etc.

Help desk users can jump to different pages of Polar Help Desk 5 just by changing URI, or bookmark page which will be the same any time they open it. URI Resource + HTTP Method is used in Roles to give permissions to Users and Contacts, for example, you can give members of some team permission to GET /incident/3 but not to PUT /incident/3 -- they will be able to see it but not to edit it and save it.

Roles and Permissions

Role is a set of permissions. Users and Contacts get their permissions from Role their Team or Account is in. For them, links in navigation are shown or not shown, and buttons active or not active according to permissions they have. Permissions completely define what each User or Contact can see, edit, create and delete.

Each permission consists of Method and Resource. Method can be: POST, GET, PUT, DELETE. Resource can be any resource built in application such as: /incidents, /incident/4, /user/5, /incidents/team/4, etc.

Permission to:

1. POST is to Create a resource,
2. GET is to View a resource,
3. PUT is to edit and Save a resource,
4. DELETE is to Delete a resource.

For example:

1. In Administrator Role:
1. permission to GET /incidents and GET /incident/{ID} is set to yes,
2. permission to PUT /incident/{ID} is set to yes, but
3. permission to DELETE /incident/{ID} is set to no.
4. Also, Team A ("A" is for Administrator) is in Administrator Role.
2. This means that:
1. Each member of Team A can view list of incidents (/incidents) and view every incident (/incident/3, /incident/4, etc.)
2. Each member of Team A will see link Incidents in navigation bar.
3. When member of Team A clicks on some particular incident, he will see incident form (for example, at /incident/67)
1. button to Save incident will be active, because he has permission to PUT /incident/67, but
2. button to Delete incident will be shaded grey, because he doesn't have permission to DELETE /incident/67.

You can check it out by yourself, just login to help desk as administrator and then go to Administration > Roles at http://development.polarsoftware.com/ccnetphd