Setting Up Appointment Status Policies

A reading room's policies are the rules that govern how far in advance patrons can book appointments and attach requests to them, whether those appointments need staff confirmation, and which notification emails go out. You set them on the Policies tab when you configure a reading room in the Customization Manager.

Most rooms run on a single set of rules that apply to everyone — the Default Policy. The reason this tab is a list rather than a single form is that some institutions need different rules for different kinds of patron: faculty might book a year out while undergraduates are capped at thirty days, or visiting researchers might have their appointments auto-confirmed while everyone else waits for staff review. You handle that by adding extra policies, each tied to a specific user status. A status-specific policy overrides the Default for patrons of that status only; everyone else falls back to the Default.

When you'll use this

• You're setting up a new reading room and need at least its Default Policy before patrons can book — every room must have one.
• A particular group of patrons (faculty, staff, undergraduates, visiting researchers) needs different booking windows or confirmation rules than the rest. Add a policy for that status.
• You want a room's appointments to be auto-confirmed (or to stop being auto-confirmed) for some or all patrons.
• You're turning reminder or appointment-received emails on or off for a room.

Default Policy vs. status-specific policies

The Default Policy is the catch-all: it applies to every patron except those whose status has its own policy row. You only need to add a status-specific policy for a status that should behave differently from the Default — you do not need one row per status. Proxies inherit the policy that matches the researcher they're acting for, not their own status.

Where these settings live

Reading-room policies are part of the reading room record, not a separate screen. Everything below happens on the Policies tab of the reading room editor.

1. Open the Customization Manager.
2. Go to Reading Rooms.
3. In the list on the left, click the room you want to configure — for example, Main Reading Room (an appointment room). (Or click New at the top of the list to create a new room.)
4. In the editor, select the Policies tab.

These are appointment-room settings

Policies apply to Appointment reading rooms — rooms that run Aeon's appointment-scheduling feature. Visit (walk-in) rooms have no policies; their editor only carries a name and seat locations. If a room is a Visit room and you need scheduling rules, promote it to an Appointment room first.

The Default Policy

Every appointment reading room must have a Default Policy, so Aeon creates one for you. When you open the Policies tab on a new room, you'll see a single card titled Default Policy — its User Status is left blank, which is what makes it the default. You can't delete the last remaining policy (the trash icon is disabled when only one policy is left), and if you ever save a room whose policies somehow lack a default, Aeon re-adds a Default Policy automatically.

To configure it, fill in the fields described under Policy fields below, then Save.

Adding a status-specific policy

Say faculty at your institution should be able to book up to a year ahead, while the Default caps everyone at 90 days. You'd add a policy for the Faculty status:

1. On the Policies tab, click Add Policy. A new card appears, titled Policy 2 (the next card would be Policy 3, and so on).
2. Open the User Status dropdown and choose the status this policy is for — for example, Faculty. The card keeps its Policy 2 heading; only the row with no status (blank) is titled Default Policy.
3. Set the fields for this status — for example, under Appointment lead time, set Maximum (days) to 365.
4. Click Save.

From then on, Faculty patrons booking this room use the values from their policy, and everyone else uses the Default.

The User Status list comes from your configuration

The statuses in the User Status dropdown are your institution's own patron statuses — they're drawn from the Status group in the Custom Dropdowns table (for example, Faculty, Graduate, Undergraduate, Staff). The first option, Default, is the blank/no-status choice that makes a row the Default Policy. If a status you expect is missing, add it to the Status custom dropdown group first.

Policy fields

Each policy card carries the same set of fields. They fall into three groups: how far ahead things can happen (lead days), the on/off switches, and the reminder timing.

Lead-time windows

The lead-time fields sit in two labeled groups — Appointment lead time and Request lead time — each with a Minimum (days) and a Maximum (days).

Appointment lead time — how far ahead an appointment can be booked:

Field	What it controls
Minimum (days)	The fewest days in advance an appointment may be booked. 0 lets patrons book for today.
Maximum (days)	The furthest out an appointment may be booked. 90 means appointments can be made up to 90 days ahead. Must be greater than the minimum.

Request lead time — when requests can be attached to an appointment:

Field	What it controls
Minimum (days)	The cutoff for adding new requests to an appointment, counted back from the appointment date. After this point no new requests can be attached, though requests already on the appointment can still be edited. 0 lets patrons keep adding requests up to the appointment's start time.
Maximum (days)	The earliest a request may be attached to an appointment, relative to the appointment date. Must be greater than the minimum.

Switches

Field	What it does
Appointment Required	When checked, patrons of this status must attach every request to an appointment for this room. This enforces the appointment requirement only for the rooms and statuses where it's checked.
Auto-confirm Appointments	When checked, appointments booked by this status are confirmed automatically — staff don't have to review them. When unchecked, they stay unconfirmed until a staff member confirms them.
Notify on Appointment Request	When checked, the patron gets the Appointment Received email as soon as they book.

Appointment Required needs a matching validation rule

Checking Appointment Required enforces the rule on the staff and patron side, but to make web request forms actually require an appointment you must also add a rule validating the Reading Room ID field in the WebValidation table for every request form that exposes the appointment-scheduling fields. Without it, the requirement isn't enforced at the web form.

Reminder timing

Reminder Days (-1 to disable) sets how many days before a confirmed appointment the Appointment Reminder email is sent.

• 1 sends the reminder 24 hours before the appointment's start.
• 0 sends it at the appointment's scheduled start time.
• -1 disables the reminder email entirely for this status.

Default values to start from

A new Default Policy starts with sensible values you can adjust: Appt and Request lead windows of 0–90 days, Auto-confirm Appointments and Notify on Appointment Request both on, Appointment Required off, and Reminder Days set to -1 (reminders off). Tune these to your room before going live.

Removing a policy

To drop a status-specific policy, click the trash icon in the top-right corner of its card, then Save. You can remove any status-specific policy, but not the Default — the trash icon is disabled whenever only one policy remains, so the room always keeps its catch-all rule.

Saving

The Policies tab shares the reading room editor's toolbar. Click Save (or press Cmd/Ctrl+S) to write your changes. If a required field is empty or invalid, Aeon jumps you to the tab holding the problem so you can fix it. Cancel discards unsaved edits and reverts the room to its last saved state.

Permission to save

Configuring reading-room policies — like all reading-room configuration — requires the Operations configuration capability. Without it, Reading Rooms doesn't appear in the Customization Manager, and opening the page directly shows "You don't have permission to access this customization section." — there's no view-only mode. Saves are also enforced on the server against the same capability. See User Permissions and Role-Based Access for how roles and configuration capabilities work.

Editor review — remove this callout (and the HTML comment below it) before publishing

ON HOLD — three Policy switches are not wired (ISSUE #270). On this tab, Auto-confirm Appointments, Appointment Required, and Notify on Appointment Request are configurable and saved but not consumed anywhere in the source — verified by an exhaustive grep (only property-definition, CRUD/mapping, test-setup, and a save-summary log line; no behavioral read). So the Switches section and the Appointment Required / WebValidation warning currently describe behavior that doesn't happen. Do not finalize until a dev confirms whether the three get wired or hidden, then rework those two spots.

The rest of the page is source-verified and can stand:

• Lead-time windows ARE enforced — AppointmentService.cs:64–70 (appointment lead) and UserTransactionValidator.cs (request lead). Fields regrouped to match the UI: Appointment lead time / Request lead time, each with Minimum (days) / Maximum (days).

• Default-policy-required + last-policy-undeletable, DEFAULT_POLICY values, User Status source (Status custom-dropdown + Default), and the Operations save-gate all re-confirmed.

• Fixed this pass: example room → Main Reading Room (was Special Collections, a visit room with no Policies tab); Permissions → Operations-gated to even open (no view-only); removed a wrong routing caveat (staff request routing uses a separate global RequestMinLeadDays customization, not the per-policy field).

• Screenshots needed (when unblocked): (1) the Policies tab showing the Default Policy card; (2) a status-specific policy card with the User Status dropdown open.

The full generation metadata — sources, files read, and verifications, i.e. the detail a tool like Claude would need to regenerate this page — is in the HTML comment directly below this callout. When this page has been reviewed and approved, delete both this callout and that comment; a page with no Editor-review callout is one that's done.