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 

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