We have gone through a few iterations of methods for handling just these situations, because cloning to all individual users for what was essentially course reserves (or other similar Activities) was quite cumbersome. Here's what we've devised, and it's working pretty well for us these days: 1. When materials are being used in the class session, all requests are routed to "Item Checked Out to Activity." 2. When the class session is over but we suspect (or know in advance) that students will return to the reading room for further consultation, we route all the requests to a custom queue, "Item on Hold (reading room group)." -- If we know that students are assigned to return, we proactively add them as users to the Activity. We have an easy time with this because all campus affiliates are automatically included in our Users table as inactive users (they still have to register to be cleared and to sign in to reading room). Not sure how feasible this would be for other scenarios... 3. When students come back - often with nebulous information about why they are there / what class they are part of - we then have myriad ways of searching Aeon to find the right set of materials that they need to use: by instructor name, by student username, by course number, by librarian... 4. As the students use materials, we route the request to "Item Checked Out (reading room group)," and then back to on hold for the same as individuals have finished with the item. What we lost in granularity of data regarding which student specifically used which items, we gained in efficiency and consistent application of workflow. We use these custom queues to count these in uses in our reports as reading room uses, as opposed to lumping them with class uses, but the direct connection with the Activity is retained. We apply this same workflow to any group of 3 or more individuals working together in the reading room for whatever reason on the same set of materials (thus the designation "reading room group"). As a sidebar, we experimented with using Activity Status to manage these different phases of a class==>reading room scenario when that became available in Aeon 3.7 (along with some crafty routing rules based on Activity Status that our in-house tech had devised). We have since determined that managing Activity requests as batches instead of always routing requests individually resulted in more errors than the time saved was worth. (More in email called "Activities and Requests in Aeon"