So just for Chromebook OU and sub OU management
Organized by grades.
In order to target OU based device settings that we intend to use for Clever Badge login on Chromebooks.

​@Andy T Thank you for submitting your question to our community!

Thanks ​@jo.cpa for your response! Is this what you are looking for, Andy? 

​@Kathryn Carter - ​@jo.cpa - flushed out the details more. Thanks

​@Kathryn Carter We work together.  I’m not sure what your response means.  I was just adding more context to the post.

​@jo.cpa ​@Andy T I must have misunderstood, apologies. 

We did this a long time ago and when it was first released, it was a buggy mess. Thankfully, it has been cleaned up for the most part and works pretty well. The important thing to make sure of is that when you make the settings for each OU, that the settings are distinct enough where a device doesn’t potentially match two or more. We actually expanded this to where we use a custom field for our more special use case devices like kiosks and have IIQ write the OU based on that as well. The other snag we have hit is that sometimes the rules engine does not play nice and things don’t run immediately on things like checkout so that is something to be aware of. 

​@spsalexs Thank you for the input!! (I also work with ​@jo.cpa  / ​@Andy T) - that’s strange that the rules engine may not play nice... are you using rules that reference the Org unit path as a filter, or are rules just generically being affected?

I will preface this by saying that my district has probably been one of IIQ’s harshest critics when it comes to the rules engine and it’s quirks. Issues are generic as far as rules and filters go. Sometimes rules will not fire off when they are supposed to or will not do the things they ought to when they fire off. My favorite one is always the sending a blank in the custom post request where a user email should be. The reason that happens is because IIQ does not check to see whether a device is disabled before trying to disable it so it will return an invalid state error that throws off the next rule that sends the post request. Another favorite that I believe was fixed is sometimes when using a not flag on a filter, the whole thing breaking and never executing.