I believe this would work for your scenario. Let me know if you need help with the filters being set. Just use 3 days instead of 1.
You can also filter this to just apply to Faculty / Staff/ Students.
Has anyone created a rule for a reminder email on a ticket that has been marked ‘Waiting on Requestor’? I would like to have rule that sends a reminder email to them after the ticket status has been changed for 3 days.
Any help would be greatly appreciated.
Use the Stale Ticket trigger in the rules engine. We have a 7 day kick off with a warning email asking for more information. Then if it sits another 7 days, we automatically close the ticket.
We use the Stale to Automatically close tickets as well. VERY helpful.
@MMorris 407ff1d belprecity can you share a screen shot of the rule that helps move devices to a different Google OU? Does it do a sub OU or just a root location OU? I am having a hard time figuring how to get this to work.
@mrodriguez we actually do it in two different places. Part of it is done via the Google Device app and the other part is done via rules.
When we were onboarding, our onboarding person wasn’t sure we could do what we were wanting to do. I used my “spare time” to play with the settings and figured out how to get it work.
So when we assign a Chromebook, we try to place the Chromebook in an OU that is consistant with the student’s grade level. We have a few things that we push to some Chromebooks that is device related and grade dependent. So here is how we have it together.
In the Google devices app, under the General settings, we have two custom fields added. AnnotatedUser is the user email and the AnnotatedLocation matches the students building.
Under Google Options, we update the owner in iiQ based on the annotated user in Google and remove the existing owner in iiQ when there is no valid user.
Additional write-back options we check both boxes and then clear at the bottom is OrgUnitPath Translation map.
In our case we place a filter on it that if, for example, they are in fourth grade, we put two filters on it that they are in grade 04 and their role is a student. The Chromebook is then placed in the /Students/Chromebooks/BES/4th grade OU.
The second part is in the rules, When a Chromebook is updated, we push asset changes to Google.
When it’s checked in, we unassign the owner and disable it. Checked out, we push asset changes to Google and enable the device. I’ve put some screen shots for all of this below.
Custom mappings to push user and location to Google
These are also what we use to remove the device from a user and also to write the status and org unit to Google
This is our OrgUnitPath Translation map
This is how we push data on our 1:1 devices. We don’t update other devices unless they are this model
When we check devices in, we disable the device so that if it should end up with someone it shouldn’t, they can’t use it.
When we check the device back out, we push the asset changes such as user and location to Google and then enable the device.
I am LOVING seeing all the details of screenshots and seeing everyone collaborate! This thread really shows the spirit of our community. I am so proud to work here and support all of y’all.
@MMorris 407ff1d belprecity @DE SysAdmin @cris.ward @SMillsTVSD @bbeaudette
We were wanting sub-tickets to automatically resolve after the sub-tickets were completed. Otherwise our agents would need to go back and update those tickets once their subtickets were completed. Currently it is set up to set the status of the parent ticket to “Resolved - Waiting on Subticket(s)” after the issue is confirmed & resolution actions have been updated. Then after all subtickets are resolved, the parent ticket’s status is set to Resolved.
Setup for “Resolved Waiting on Subtickets”
Setup for resolving parent ticket once subtasks have been completed.
@Dakota SDOW This is very useful! Thank you for sharing 😄
Here are a few of the rules we’ve implemented for tickets since the last time I replied here:
For New Student Enrollment Tickets:
Filter:
Issue Type: New Student Enrollment (change this to whichever issue type you use.)
Perform these actions:
Assign to agent: (Agent that adds new students to AD/etc, here.)
Create Subtickets/Subtasks:
- Set up a ticket template for what you would like to add the subticket for, we use ours for New Student Device setup. So whenever a ticket is submitted for a new student enrollment, it automatically creates a subticket to notify the technology team to get a device ready for the new student.
- Map Requestor from parent agent.
- Assign agent (specify agent/team).
- map custom fields from parent ticket. (We ask users to submit student name, sis #, grade level, school location and homeroom when submitting new student enrollment tickets. This information is then flowed over to the subticket via mapping which makes getting a device ready much easier.
- Add tag (optional): New Student Enrollment (so we can reference back to make sure we assigned devices to a student.)
- Set Priority Level (optional): We set ours to medium to be sure we get a device to new students ASAP.
This rule helps with the automation process so that you aren’t constantly having the submit tickets after getting a new student enrollment ticket. You can just let the system do its thing. We also have another variant of this rule that would be for new staff enrollment and would trigger subtickets to be created to prompt our security person to create badges for the new staff member.
We also have set another rule for “when Updated” which will automatically update a ticket that has subtickets to have the status, Resolved - Waiting on Subticket(s) once all issues are confirmed nad resolution actions have been added.
Auto Set Resolved waiting on subticket (When Updated):
Filters:
Has Open Subtickets: Yes
Is a Parent Ticket: Yes
Status: In Progress
Ticket State: Open
When field is updated: IssueConfrimed, ResolutionActions
Perform these actions:
Set Status: Resolved - Waiting on Subticket(s). This is a custom status, which needs to be set in admin → ticket statuses.
Since a parent ticket cannot be resolved until the subtickets are completed this rule sets the automation process of showing the parent ticket is waiting on subtickets prior to closing. The next rule we’ve added is to automatically set it to Resolved once the subtickets have been completed. These rules help to allievate the forgotten parent tickets that have to wait for subtickets that may take a little bit to complete. So you aren’t constantly having to check back and see whether or not hte subtickets have been completed from the previous team if you are finished with your part.
The rule to resolve a parent ticket once subtask is complete (When Updated):
Filters:
Has All Resolved Subtickets: Yes
Has Subtickets: Yes
Is a Parent Ticket: Yes
Status: Resolved - Waiting on Subticket(s)
Ticket State: Open
Perform these Actions:
Set Status: Resolved.
Now once all subtickets are completed, your parent ticket will automatically resolve as long as all of your tasks have been completed. So the parent ticket goes through the steps of Submitted → In Progress → Resolved - Waiting on Subticket(s) → Resolved (once subticket(s) are completed.
Anothe rule that we have under “when Stale” is a 3 day warning that triggers when a ticket has been in the status of waiting on requestor for 3 days.
Filters:
Days Stale: Equal to: 3
Status: Waiting on Requestor
Perform these actions:
Send email alert to user:
To: Submitted By/On Behalf Of
Subject: Your Help Desk Ticket Requires a Response.
Body: Hello {{User.FirstName}},
Your submitted ticket is currently waiting on your response. Please respond via the message box within your submitted ticket. If no response is posted your ticket will be closed in 2 days.
Ticket Information:
{Ticket.TicketNumber}} - {{Ticket.TicketSubject}}
You can play around with the email variables to include more information in the email responses for these type of tickets.
Another helpful ticket that we hope we don’t have to utilize as much since it is a weekly schedule, that triggers “when On a Schedule”. This could be a helpful rule to have to prevent tickets from sitting too long. Similar to utilizing the SLAs and rules for stale tickets. This one will increase the priority a certain amount each week it remains open.
Weekly Priority Increase ticket:
Filters:
Schedule: Weekly on Monday at 5am
Status: In Progress
Ticket State: Open
Perform these actions:
Increase Priority: 50 (change this to whatever amount you would like. 50 is our sweet spot to be able to go from low, to medium, to high, to critical each week.
By the 4th week of being open it will be in the critical priority state. Hopefully we never have to reach that level, but sometimes tickets are forgotten or take a while to complete if you’re waiting for parts. One issue with the way this ticket rule is set up is that if the ticket is submitted Friday and has been started it will go into the in progress status, which means when you come to work on Monday the priority of this new ticket will be increased even though it has only been there for 1 work day.
We also utilize the rules for when “From email” which allows us to customize the user experience for submitting tickets via email however we would like. For instance, we typically are sent an email by HR to change substitute roles in our SIS instead of having them submit a ticket. So we’ve set up an email similar to substitutes@ourdomain.incidentiq.com to route these emails to iiQ tickets. We just asked HR to include that email as a CC when they send them out. The only issue we’ve found is if people put more information into the subject than the body, the subject does not transfer over.
You could use this rule feature to create tickets from different programs your district uses as well. For instance, if you get prompted by other programs or platforms you use via email. You could have those alerts set to email {Anything}@domain.incidentiq.com and a ticket will be created that includes the body. However, make sure in Admin → Site Settings that you’ve got it enabled or confirm whether you want to strip signatures/other text from forwarded emails as sometimes it doesn’t copy everything the greatest. I believe we’ve turned our stripping of emails off.
Email to Tickets @Substitutes Rule:
Filters:
To Email: substitutes@ourdomain.incidentiq.com (You can name this whatever you would like.)
Perform these actions:
Approve ticket creation from email.
Add tag (optional): Substitute (or whatever you’re using this email rule for.
Add follower: An agent who would work on this type of ticket. We actually added 3 followers for substitute tickets so they can keep track of them.
Assign to team: For us, this ticket falls to the instructional technology team since it deals with our SIS.
Set Issue: SIS ticket issue → Requests
Assign to Agent: Primary agent working on adding these, with followers as potential fallbacks.
Set Priority Level: Medium (getting the subs access ASAP is helpful so they’re able to start properly using their accounts once they’re subbing.
It is worth noting that if you have rules set up for certain ticket types such as SIS Ticket Issue → Requests to automatically assign to a team, agent or add followers you don’t have to repeat the process under another rule that applies to the same issue type. So you could ignore those instead of repeating those steps. Another instance of this ticket we have is for repairs. So when a claim is paid for a device, we have it set to send an alert to repairs@ourdomain.incidentiq.com. That alert for a paid claim then creates a ticket for our techs to see that a damaged device has been paid for.
A few things to mention, be careful when creating rules for “when updated” as sometimes these actions can constantly update while the ticket is being worked on. For instance, we had a rule for when updated the ticket would assign the ticket round robin to a team member. This was used for when we’d have to change the issue types of tickets, and we’d want to automate the updating of the assigned agent to match that particular issue type. However, each time the ticket was updated, commented on or changed it would change that assigned team member. Even when you assigned a specific team member to it, it would revert and change to a round robin agent instead.
There are a lot of different things you are able to do with tickets that help the automation process. However, there are a few issues we ran into like the efficiency of selecting certain ticket types to auto assign to agent by location. We might be overlooking something simple, but it seems we have to select each Issue Category individually. Which if you have hundreds of issue categories to choose from, you can only select the first 100 or search for specific issue categories. See screen shot below of this:
If you know of a better way for us to select all of these issue categories as a group instead of individual, please let me know.
Put this together for a recent Lunch and Learn session. If anyone wants to inquire more about any specific feature, feel free to reach out!
Rules Engine
Assets
- Rules that emails users (with variables) their asset information and reminding them they are responsible for returning it EOY
- Staff new hires assigned a device also get an email asking them to sign the AUP upon assignment
- Assets set to Donates / Sold / Reccycled status send email to me to review to fill information on Recipient, functional status, etc.
- When a user is removed from an asset (not check in) is will set asset status to “In Storage”
- When a device is assigned to a user (not checked out) will set device status to “In Service”
- Verify Device on Checkin
Custom Ticket Statuses / Rules Engine
Closed Due to Lack of Response / Resolved
- Tickets Gone Stale 5 Days are set to this status
In Repair (In House) / In Repair Vendor
- Tracking in-house repairs vs troubleshooting
In Repair (Vendor) / In Repair Vendor
- Tracking out of house repairs vs troubleshooting
Monitoring / On Hold
- Monitoring Resolution of an issue
Need to Order Parts / On Hold
- Emails me to check the ticket for the part that needs to be ordered
- staff mention the part needed or link it
Ready for Pickup /
- Emails requestor (using variables) that the device they submitted for repair is ready for pickup
- emailed daily until the device is picked up
Researching / On Hold
- used to track researching an issue / pauses SLA
Waiting on Device
- emails requestor daily (with variables letting them know we need their device to continue the ticket)
- does not resolve / time out
- used for loaner devices to request a user return a device on loan to them
Waiting on Other Department
- used to track issues related to a request that have gone outside the scope of support of the department
Waiting on Parts / On Hold
- used to track repairs that are on-hold due to lack of parts in house
Tickets
- Tickets for certain issues / Requesters
- send an email to the agent / team they are assigned to
- network outages, registering devices on the network, termination requests, etc
- Waiting on Requestor
- Tickets set to this status email the requestor every few days (2 & 4) reminding them to reply to the ticket since we need information to continue
- Tickets set to waiting on requestor that are not replied to after 5 days will then auto-close with an email reminding the requestor to reply back if the ticket was closed by mistake
- ticket status set to “closed due to lack of response”
- Tickets that are resolved that receive a reply re-open and then email the agent / team that the ticket has been re-opened
- Priority / Team Assignment
- We used a planning document to break out issue categories and the teams they should be assigned to
- Ranked / weighted certain issues based on their affect to learning
- Used a formula in the document to give us new priorities
- Set rule engine to set the priority on those tickets when those issues were submitted
- Location Email Submission
- Rules to set ticket location based on users OU / Location
- SLA Accuracy
- Rules that re-open tickets that are not properly meeting criteria like having assigned an SLA.
- Rules that re-opened tickets with “Other” used / emailed me to review so I could also create a new action
- Copier Issues
- QR code on Copiers that opens a pre-filled Google Form with asset tag information and a request what issue is wrong
- Sends email to help desk email with asset tag and issue pre-filled in ticket information (like what a user would send in the body of an email)
Custom Asset Statuses / Rules Engine
Awaiting Parts / In Repair (In house) / In Repair (vendor) / ready for pickup / Need to Order Parts
- Rule engine changes asset status to this to show views with assets that are in the repair system
- easy to build a custom dashboard item to show these at a glance
Donated / Recycled / Sold
- used to track devices that have left for reports
- devices set to this status move to a new location called “sold / donated / recycled”
Trash / Scrap
- Devices set to this status are moved to a room on campus automatically where they are stored until we can dispose
Missing / Stolen
- Chromebooks set to this status are set to disabled in Google Admin
- Devices removed from this status and set to “in service / in storage” are re-enabled
- good for shutting down missing devices from audits or student loaners that have been out too long without remembering to re-enable them once collected.
Thank you @Dakota SDOW and @bushwhack for submitting your rules here! These are so detailed. 😄
Here is a rule for automating powerwashing for Chromebooks that we got working thanks to Emily & Rob.
Note: You must have Google Devices app installed and activated for this to work.
Create the rule under Assets. The trigger we use is “when ‘Checked In’”.
We will use this rule during the end of the year device check in. Since we collect student devices over the summer for inspection.
When these conditions are met:
Models: Selected Chromebook Models
Role: Student
You can also select date ranges or only enable the rule when you’re ready to begin End of Year powerwashing.
Perform these Actions:
Push Asset Changes to Google
Set Device Status in Google: Wipe Device
Now each time a device is checked in through the check in/bulk check in section, it will initiate a powerwash for the chromebook the next time it is powered on. This rule can help to do bulk powerwashing if you are a district like ours that checks in a few thousand Chromebooks at the end of the school year.
This is a great thread! I am wondering if anyone has setup a rule that when a teacher is marked as leaving our district (which I import in a custom field) and have the rule read the date is within a range and then create a ticket for that user if they have a certain model of laptop checked out.
@ami.minor consider using stale ticket rules! You can choose a filter for the status “Waiting on Requestor” and pick the number of days stale. Then you can trigger an action to send an email to them to remind them that a ticket is waiting their response. Then you can also create another rule for a longer period of days and then send the email again but this time letting them know that their ticket has been resolved due to no response and if they are still having issues to submit a new ticket, and add an additional action to resolve the ticket.
Analytical rule that my bosses love that gives us true analytics for agents letting tickets fall into stale status. The built in analytics for stale tickets only show active tickets, so I set up a rule using the email variables to populate an email box and sort them by agent in folders/labels (we use Gmail so Labels).
If an agent lets a ticket sit for 7 days, it will automatically fire an email to a managed email box, sort it to the folder of that agent by name, and leave them unread so that the bosses can get a quick peek on the side bar for true stale analytics. You can set whatever filters you want and then include the variables to grab the assigned agent info and whatever details you want.
I have the same rule set up for if a ticket hits 1 year also and it goes to a different box and CC’s the bosses into it.
@bbeaudette nice work! help me understand the difference with notifications. Currently, agents requestors get notified every time a ticket is updated (any update) by email. How is that different than what you are doing?
@vince I’m trying to minimize the use of IIQ email alerts. To your point about IIQ emailing updates, I’ve 50-100 daily emails from IIQ, many of which are duplicative (i.e 4 comments from the same ticket are 4 emails). It’s pretty spammy. It takes a lot of time to work through that many emails. The ‘new comment’ status provides a way to see these updated tickets in IIQ. New tickets are easy to spot with the ‘submitted’ status. Once you act on it, it will go to ‘in progress’. However, if a user replies, the default behavior is the ticket status remains ‘in progress’. There is no way to see there has been a comment on the ticket. It’s common in other help desk software to change the status on a user reply. The ‘new comment’ rule does that, identifying tickets that have been touched recently by someone. That way, when you look at the view of all those tickets, you can easily see which ones have new info with the ‘new comment’ status. No need to read the through 100 IIQ emails.
Part of the problem is IIQ uses the same subject line for the email alerts across all tickets. This creates the need to read every single email from IIQ. Many other help desk solutions will apply a unique value in the subject line which would allow multiple emails from the same ticket to ‘thread’. I’m pretty sure there is a feature request for that somewhere. That would help the issue, as those 100 email I get would distil down to maybe 30 threaded emails, which is far more managable.
