Skip to main content

Hi,

I’ve been trying to create a ticketing rule based on certain keywords. Essentially, if an email comes in containing the “Parent Square” keyword, I wanted the ticket issue to be set to “ParentSquare > Other / Issue Not listed > Report an issue”. The screenshot below shows this category exists in our environment. 

 

However, when I go to the rule and search for Parent Square issues, nothing shows up.

 

Also, just to test, I tried searching for specific Parent Square issues, such as “Email not received”. This time it did find the issue:

But for some reason the rule does not categorize this issue under “ParentSquare”, instead it puts it under “Classroom Management > Messaging issues”  

Anyways, am I doing this wrong? what am i missing?

Also, as a side note, the search function for issues is very, very slow!

Thank you in advance. 

 

 

 

If you search for “Report an issue,” Do you see the Parent Square option? I think “Parent Square” might be seen by iiQ as Model, which is why the info isn’t coming up?


@Daniel P Thank you for submitting your question to our community! 😄

I think ​@AMeyer Greendale Schools is on the right track with this one! 


@AMeyer Greendale Schools ​@Kathryn Carter Thanks for chiming in. I think that is the problem for sure, Models vs Issues is what makes this confusing. 

When categorizing a ticket manually, issues are inherently tied to models. Therefore you follow a logical path: Model > Issue > Sub-issue, etc. We built our entire “Issues” infrastructure around Models. 

But under Rules, for some reason, Models are no longer part of the equation? Why? What’s the value of an issue if it can't be associated with a Model? It feels like it leaves out a crucial piece of information that should be in the ticket.


Let me know if i’m thinking the wrong way about this, and thank you again!


@Daniel P As I understand it, you use the filters for the model while the actions will set the issue type. So we are on the right track, just need to adjust the set up. The filter would be “Parent Square” and then when you search to set the issue, start with the category name, not the model.

I hope this helps! 


@Kathryn Carter here is a screenshot of the rule in question. When you say “use the filters for the model”, do you mean add the “ParentSquare” model under “When these conditions are met”?

 


Hi ​@Daniel P just chiming in to hopefully help with this one. I think both ​@Kathryn Carter and ​@AMeyer Greendale Schools are both on the right track here!

From my understanding, your filters should be correct. It is basically saying if an email comes into iiQ with the subject OR body of ‘parent square’ then we are going to set the issue to ‘report an issue’. (as you have displayed above). 

I understand your comments above about tying your issues to models, which is how the setup works but if we are driving an action through rules, you would not be able to set ‘parent square’ as your ‘set issue’ action as it is a model and not an issue. 

I hope this provides more clarity. A couple of things you could potentially do are:

  1. create another issue category under the model of parent square →  name the category parent square then you can set the action to the issue category. 
  2. rename the ‘other/issue not listed’ to parent square under custom names and attribute the action to that
  3. create another issue under other/issue not listed and create a custom issue type of ‘report a parent square issue’

Reminder, you can adjust the visibility of the model to potentially stop anyone from utilizing those selections during internal ticket submission. Just a couple of thoughts/workarounds. Let me know if you have any questions.


@Melissa_iiQ 

Hi, thanks for your suggestions! I’d like to point out a couple of things:

  1. We built our entire ‘Issues’ catalog with the understanding that issues are structured as subcategories (or extensions) of Models. Essentially, each issue is directly tied to a specific model, and that hierarchy is what drives how we categorize and address them. This is why most Issues don’t work well for us as model-independent entities. With this in mind, if we were to follow your approach, the main problem is that our issues catalogue is huge! Having to re engineer the entire thing just to work around the shortcomings of these rules would be a massive undertaking. If we were new to the platform, then your approach could work, but i feel that ship has already sailed for us at this stage. (I cited Parentsquare as an example, but I was hoping to expand automation to a bunch of other keywords)
  2. My question is: I still don’t understand why models cannot be set in rules, is there a technical limitation i’m not seeing? Why is this possible manually but not with rules? 

Thank you again for you help and ideas!


@Daniel P thank you for your reply. I can see what you are referencing however, if you are wishing to set a model via a rules action once a ticket is submitted, this would be an enhancement request. I would drop it in our Idea Exchange!

 

Thank you!


@Melissa_iiQ  thanks for all your help. My experience with submitting enhancement requests has not been very rewarding, to be honest. I’ll just move on, I was just hoping someone knew a work around. Thanks again!


There is an idea already in idea exchange around having an action to set model via rules engine: 

 

 


Reply