Recommendations to Exend the Help Desk to a Service Desk

KRP · 2024-11-09 01:46:01

We have been using GLPI exclusively as an IT tool, using it as a Help Desk and Asset tracker with Fusion and a few other moduels for ourselves. We now are considering centralizing all our companies request/incidents to one location and about to start testing how that would work.
Conceptually it seems simple but I am starting my research on that to get a better understanding of how that would *actually* work and wanted to ask around on any recommendations to have a successful outcome.

We currently only have one Entity but maybe adding more is a good idea/necessary or if one is better. We would be looking for a way to organize and/or route ticket to select groups/depts as needed, eg ticket comes in and its a training item and we route that to someone in the training group.
We want a way to create some separation between the different groups and their access, eg we don't want the training group messing with the IT Tickets.

We envision one place for staff to enter tickets, the IT Dept staff would then triage and route/assign/forward to the appropriate group with the option to be routed back. eg a question comes in that appears to be a training item, its routed but later its found to be an actual issue or change IT Dept needs to complete.

If someone has experience or can provide some recommendations for the best path or confirmation going down the multiple entities is needed using a plugin I found to move ticket between entities.

Thanks in advance.

cconard96 · 2024-11-10 17:30:43

You could use the Form Creator plugin to build forms with custom questions which would generate tickets in the desired entity.

KRP · 2024-11-15 19:26:55

Thanks cconard96, I'll do some testing and see how that works.

KRP · 2024-11-20 18:13:01

cconard96 in your experience, based on what we are trying to accomplish, will we need or be better off sticking with one entity or will we actually need to setup multiple entities? As I mentioned, we feel having some sort of separation between support groups would be important, eg IT Dept, Training, Company Admin, HR, etc.

I feel like separate entities may be needed to manage support group permissions to tickets as well as better organization, eg one long ticket list could be difficult to manage/work with for each group. Perhaps GLPI can already do that with one but brief my tests before posting I was not able to accomplish those two items.

Goals
1. Limit ticket permissions (Read, update, etc) to assigned group
a. IT Dept access to all tickets
b. Other groups Training, Admin, HR would only be able to mange their tickets (haven't decided yet if all other groups could see each others or if they need to be separated. This would be based on volume.

2. Visually organizing tickets, if all in one queue, this could be challenging to sort through. I guess would could create custom views but not sure how effective and easy to use for each group would be.

3. One place for all tickets to be entered, so its easy for users, they DON'T need to go to different entities based on who will provide the support.

4. A way to triage tickets and route/move/etc the the specific group providing that support. Again I am not sure if that can be done on one entity using groups based on Type & Category or if separate entities would be needed.

cconard96 · 2024-11-20 23:25:31

Separate entities sounds like the better solution.
Having forms from the Form Creator plugin in the root entity and visible to child entities, that handles creating tickets in the correct entity sounds like the right solution too.

doppy · 2024-11-21 11:20:31

Yes agree. I am in the same position but the problem is that GLPI drops notifications from the same system. So keep in mind that when one unit is mentioning or adding the other email of the other unit, the mail will not appear in the other system - it is dropped. This makes it currently impossible to use with multiple units in the same company.

KRP · 2024-11-22 18:23:43

I am reading the documentation on FormCreator and the Github site mentions,
"Forms will be implemented in GLPI soon, making Formcreator obsolete soon. Therefore, the very last release of the plugin is 2.13.8".

In your opinion, is it worth starting now with FormCreator if GLPI will soon have it as a native feature?
Does anyone know of the expected release date the integrated forms?

cconard96 · 2024-11-23 12:40:49

The form feature will be in GLPI 11. There is an alpha release currently, but no ETA on a stable release. The native form feature and native custom assets features are both still WIP.

doppy · 2024-11-25 11:39:16

Great news. But regarding that one entity is mentioning another entity there is no solution, right?

KRP · 2024-12-03 19:23:57

I have been testing and must be doing something wrong as I can't get the Business Rules working.

I started with the TransferTicket and after setting up the a sub entity and think I am making progress there but have a few questions.
1. when a ticket is transferred from the Root entity to a sub Entity A, I assume the ticket is always visible in the Root (root->EntityA) and not completely moved to the sub entity A?

2. if yes, then would the suggested Entity setup be to use the root only to receive tickets then with either Business Rules move it to the correct entity or a service desk person Transfer it. The issue I see with a service desk person manually moving the ticket, is they'd be able to see all tickets then no matter what sub entity the file was in. So if it went to a HR Entity there could be a privacy issue. I assume there is where Business rules come in to route new tickets to the correct entity based on Category and user interaction is needed in the Root Entity.

Maybe Entities like this would be the answer;
>Root (All tickets start here, business rules move to the appropriate but Entity)
-->HR

-->IT

-->Training

Staff within each entity would be able to transfer to the other Entities as needed but won't be able to view the data there unless provided "Authorization" by membership.

KRP · 2024-12-05 00:25:02

The more I test the more confused that I am not understanding the proper use of multiple entities.

I am looking at this from a "end users perspective" (submitting tickets) not a tech perspective supporting the tickets.
- Is it expected that a user will have to manually navigate to the correct entity if their ticket has been transferred?
- There is no global view or dashboard for them to see their ticket no matter where it is?

It is starting to seem like a end user should/must be set to be in a specific entity and stay there. If the expectation is an end user will know now to change their entity and furthermore know which entity their ticket was moved seems a bit of a stretch for most end users.

For a tech or supervisor on GLPI, to move between entities is not super difficult but to for a end user, it feels like I may be missing something.
Unless the solution to this is setting the" Default entity" = 'Full structure"? which appears to give them insight to all entities, is that the correct use of the option?

Last edited by KRP (2024-12-05 00:27:32)

Forum GLPI-Project

Announcement

#1 2024-11-09 01:46:01

Recommendations to Exend the Help Desk to a Service Desk

#2 2024-11-10 17:30:43

Re: Recommendations to Exend the Help Desk to a Service Desk

#3 2024-11-15 19:26:55

Re: Recommendations to Exend the Help Desk to a Service Desk

#4 2024-11-20 18:13:01

Re: Recommendations to Exend the Help Desk to a Service Desk

#5 2024-11-20 23:25:31

Re: Recommendations to Exend the Help Desk to a Service Desk

#6 2024-11-21 11:20:31

Re: Recommendations to Exend the Help Desk to a Service Desk

#7 2024-11-22 18:23:43

Re: Recommendations to Exend the Help Desk to a Service Desk

#8 2024-11-23 12:40:49

Re: Recommendations to Exend the Help Desk to a Service Desk

#9 2024-11-25 11:39:16

Re: Recommendations to Exend the Help Desk to a Service Desk

#10 2024-12-03 19:23:57

Re: Recommendations to Exend the Help Desk to a Service Desk

#11 2024-12-05 00:25:02

Re: Recommendations to Exend the Help Desk to a Service Desk

Board footer