Hey iiQ Community!

We are looking for guidance—and potentially putting forward a feature request—regarding the most reliable way to trigger a device recall ticket when a student leaves the district mid-year.

The Challenge: Delayed User Account Deactivation

Our primary challenge is timing. Our Student Information System (SIS) marks a student as inactive (e.g., isactiveinsource=false) immediately upon exit. However, our district policy keeps the student's Google account active for a 30-day grace period.

This means we cannot key an iiQ User Rule off of the user account being deactivated, as that's 30 days too late for a timely device recall.

Furthermore, we've noticed from previous community discussions (like the one about using "When field is updated: Location" which often fails to execute reliably, that relying on other standard User fields can be tricky.

Our Proposed Solution: Keying off the Inactive Google Group

We have implemented a solid workaround that seems reliable, and we wanted to share it and see if anyone has a better method or if iiQ developers could officially support this pattern.

Current Setup:

1. We have a dynamic Google Group (Inactive-Students-iiQ) that is automatically populated by our SIS sync when isactiveinsource = false.

2. This group (which maps to an iiQ Team) is mapped and synced into incidentIQ via our Google SSO integration.

The User Rule (Type: Ticketing Users / Trigger: Updated):

Our User Rule is set to the type Ticketing Users with the Updated trigger.We are hoping we can get a trigger to fire successfully due to a users membership change of a new Team (the inactive group) to the user's profile constitutes a complete record "Update."

The rule's conditions are designed to fire only once upon the change:

1. Condition 1 (The Gate): We use a filter that checks that the user's Team/Group membership list has just been modified. This is crucial for only generating one ticket, as relying only on Condition 2 will cause the rule to run successfully every time the user's profile is updated while they remain in the group.

2. Condition 2 (The Target): The rule then confirms that the user is currently a newly added member of the Inactive-Students-iiQ Team. 

If both conditions are met, the Action is to Create a ticket using our pre-configured Device Recall Template.

The Goal: This dual-condition rule successfully creates a Device Recall ticket immediately when the student's SIS status changes, long before their Google account is officially deactivated 30 days later.

Community/Developer Question

1. Confirmation: Is using the Team/Group membership change detection combined with the Team membership filter confirmed by other users or iiQ support to be the most robust method for handling immediate action based on SIS status changes that are synchronized via Google Groups?

2. Are there plans for a dedicated User Status field (Active/Inactive) that can be reliably mapped from the SIS and used as a rule trigger?

Thanks for any feedback! This has been a huge help in closing the recall gap.