We're now pushing data from several campus business systems into Grouper; from there we're replicating group memberships (in real time) into several target systems (ldap, LMS (Canvas), Google, Active Directory).
We have several different categories of groups whose base membership is managed in this way (community/demographic groups, departmental people groups (English-Faculty-All, English-Staff-All, etc), Course Groups, undergraduate concentration groups, etc).
As more and more people use these groups, we're finding that we have to set Properties on these groups in some target systems. And, not surprisingly, the values we set are a function of the "category" that a group belongs to.
With Course groups, not surprisingly, we have to worry about FERPA constraints. With google the defaults work OK; with AD, we have to do a bizarre dance to get the correct outcome. With departmental people groups, we have to change the properties in google so that admin staff can schedule faculty meetings and see the responses.
We suspect we're not the only campus starting to deal with this issue. The way I've described this ("categories of groups") implies how we're thinking to approach the problem. Grouper sends messages to connectors (to the target systems); those messages would now include a "category value".
Questions or comments? Contact us.