Skip to main content

In my soon-to-be previous ticketing system, I could create ticket ‘types’ and apply SLAs to those types. For example, most support requests are ‘issues’  (broken screen, can’t connect, etc) that get a standard SLA (reply in 1 day, resolve in 1 week). However, some are ‘projects’, such as building a new computer lab, refreshing network infrastructure, etc that would get a much different SLA (reply in 1 day, resolve in 30 days).

In IIQ, I only see ticket ‘status’ as a way to create this functionality or building a new issue chain. Using status is not preferred, as project tasks also need a status field. Building an issue chain requires building duplicate issue types under a project issue category.

How are other IIQ users leveraging the system to manage quick/standard issues versus long-term/complex project issues?

Hello @bbeaudette and welcome to the community! Have you looked into our SLAs? This help guide goes into setting them up, using them with rules, etc. It might be good starting point for what you are looking for:

 


@bbeaudette I just wanted to check-in to see if the help guide I previously suggested was helpful or if there was something else you needed help with. 


@Jessica Adkins Thanks for the follow-up. The SLA guide didn’t help get me any closer to a resolution. I understand how SLAs work and am working them into my workflows. I’m still trying to differentiate tickets based on an issue (quick resolution) versus a project (long-term resolution). I started to look at tags, but they don’t trigger rules by themselves and can’t be incorporated into views, so that didn’t work. Maybe I missed the obvious in your suggestion and I should use the SLA, themselves, as the distinction between the two types of tickets. 


My best way to tackle this would be to have a separate Ticket Category for “Projects”, then create ticket types under it for various projects. Then you can apply SLA’s you create based on the Ticket Type. That way they can be worked like regular tickets still but have separate SLA’s from the main ticket types.

 

You can go even further and make that type of ticket only visible to Agents if that is something that only an Agent would put a ticket in for. Then only your agents/admins will see those type of tickets and site administrators can be added as a follower after the fact for visibility. We have a similar functionality set up already for “On Call” issues, it has a separate SLA and only agents that would be On Call can put in a ticket for it.


@TAnders Thank you for jumping in! Your suggestion is the best workflow to accomplish this. 

 

@bbeaudette Thank you for submitting the idea for allowing Tags to trigger rules. I think this would be a great enhancement 😁

 

 


My best way to tackle this would be to have a separate Ticket Category for “Projects”, then create ticket types under it for various projects. Then you can apply SLA’s you create based on the Ticket Type. That way they can be worked like regular tickets still but have separate SLA’s from the main ticket types.

 

You can go even further and make that type of ticket only visible to Agents if that is something that only an Agent would put a ticket in for. Then only your agents/admins will see those type of tickets and site administrators can be added as a follower after the fact for visibility. We have a similar functionality set up already for “On Call” issues, it has a separate SLA and only agents that would be On Call can put in a ticket for it.

When you Say separate ticket category for “Projects” Do you mean an issue type? or do you mean a different group of tickets as a whole? 

 

We essentially want to two different work flows, one for incidents/tickets (more of a help desk style ticket) and then one for our District office team (that would be more project based), that wouldn’t follow the same rules as our normal. incident tickets.  


@brett.eckler 
Create your custom issue categories and individual issue types under one specific Ticket Type (Devices, User Account Access, Network/wifi, Software/online system, and other requests).

Then you can create different rules/workflow based on the whole issue category. Like applying one SLA to a whole issue category “Project Based”.

 

Currently are unable to create your own ticket type. Here is a post that @TAnders 😁 submitted in our idea exchange for that:

 


@Hannah Bailey is the following suggestion by TAnders still the most relevant practice and recommendation for managing projects through iiQ?

My best way to tackle this would be to have a separate Ticket Category for “Projects”, then create ticket types under it for various projects. Then you can apply SLA’s you create based on the Ticket Type. That way they can be worked like regular tickets still but have separate SLA’s from the main ticket types.


It would be nice to have a completely separate workflow for projects not an Issue type, cause it’s not a different issue, its a different Ticket Category 


@MBethel 833e54 pasoroblesjusd @TAnders has a great workflow here. This workflow using tickets would allow you to use the functionality of tickets like SLAs, due dates and tags. 

@brett.eckler There is no idea in Idea Exchange for this yet. Please submit that using this link: https://community.incidentiq.com/ideas


Any plans on bringing in proper project management tools, and GANTT charting? 


@SArora 410d732 monroviaschools I have not heard about those specifically, but here are some additional Project Management  ideas to check out: 

 


Standing up JIRA separately is a beast and a fully fledged product. I would leave IIQ if we’re going to do a JIRA integration. 

Being able to run projects on timelines is super important and IIQ already has enough built in to expand into it. 


@SArora 410d732 monroviaschools Thank you for your feedback. 😄


Reply