Skip to main content

Viewing Activity Requests

An activity gathers item requests in one place — the items a class, exhibit, or event needs pulled. Researchers (and staff on their behalf) attach requests to the activity, and from then on those requests live on the activity's Requests tab. Opening that tab is how you check what has been requested, see where each item sits in the workflow, and start processing.

Most of the day-to-day flow is simple: a request comes in attached to the activity, it lands in Awaiting Activity Processing, you open the Requests tab to review it, and then you process it like any other request — print the call slip, route it onward, and it follows the standard request workflow from there. This page covers reading and acting on that list. Creating the requests is covered in Creating Requests from a File for an Activity, and adjusting an activity's fields is in Creating and Editing Activity Details.

When you'll use this
  • You want to see every item requested for an activity and what state each one is in.
  • A new request has come in attached to the activity and you're ready to process it.
  • You need to act on several of the activity's requests at once — route, flag, print, or detach them from the activity.

Opening the Requests tab​

  1. Open the activity — from the activities list, search, or any link that carries its activity ID.
  2. In the activity detail, select the Requests tab.
  3. The tab shows Linked Requests with a count in the header, for example Linked Requests (12). Each row is one request, rendered as a card with its key fields (title, author, status, and so on).

Every request that belongs to the activity appears here regardless of where it is in the workflow — newly placed items sitting in Awaiting Activity Processing alongside ones already retrieved, checked out, or finished.

If the activity has no requests yet, the tab reads No requests linked to this activity.

Finding a request in the list​

The list is built for activities that can run to dozens of items, so it scrolls and filters rather than paging:

  • Scroll the list to load more — additional requests load automatically as you reach the bottom.
  • Filter and sort using the controls above the list. You can narrow by fields such as status and sort the results; the count in the header reflects what matches.
  • Active toggle — flip the Active switch (top right of the list) to hide finished and cancelled requests and show only the ones still in play. It's off by default, so you see the activity's full history until you turn it on.

Open one request for processing​

Click a request's row to open it. Double-clicking opens it the same way. The request opens in its own detail view, where you process it exactly as you would any request — edit fields, print, route, and so on. See Opening & Locking a Request and Routing a Request for that workflow.

Printing a call slip starts the standard workflow

A new activity request starts in Awaiting Activity Processing. Printing its call slip moves it to retrieval, and from that point it follows the normal request workflow — the activity link stays attached, but the request is processed just like any other. You can print call slips for the whole activity at once from the activity toolbar (Print Callslips → Requests Awaiting Processing or All Requests).

To work with these requests outside the tab — with the full search grid, column layout, and export tools — click View All in Search next to the Linked Requests header. This opens the search view pre-filtered to the activity's requests.

Acting on several requests at once​

You don't have to open requests one at a time. Select the checkboxes on the rows you want (or use the select-all checkbox above the list to grab everything currently loaded), and a bulk-action bar slides up from the bottom of the screen showing how many are selected.

From that bar you can, among other actions:

  • Route the selected requests to another queue.
  • Flag / unflag them.
  • Print request slips, call slips, invoices, or digitization requests.
  • Clone them, including Clone to User.
  • Request For — Assign to Activity, Assign to Researcher, or Clear Association.

Clear Association is how you remove a request from the activity: the request stays active for the researcher, it just stops being tied to this activity. (Conversely, Assign to Activity is one way to attach requests.) This is the web-client equivalent of clearing the Request For association in the desktop client.

This replaces the desktop-only workflow

In Aeon 6 the documentation said activity requests could only be processed in the desktop client and merely viewed in the web client. That is no longer true in Aeon 7 — viewing and processing activity requests happens here in the web staff client.

Permissions
  • Viewing the list requires the View level of the Requests permission. Without it, the tab shows a Restricted message ("You don't have permission to view requests.") instead of the list.
  • Bulk Route, Merge, and Cancel Requests require the Full level of the Requests permission.
  • Flag, Clone, Bundle, and Request For actions require the Edit level of the Requests permission.
  • Appointment actions require Edit on Appointments, and Export requires View on Reports/Export.
  • Merge is additionally available only when every selected request belongs to the same user (and at least two are selected).