search

Reservations and Calendar

hashtag
1. Overview

Reservations allow users to schedule, check out, and check in assets over defined time periods within a collection. The feature is controlled by organization-level entitlements, feature flags, and collection-level configuration, and is fully permission-aware.

Core lifecycle statuses:

  • Reserved

  • Checked Out

  • Checked In

  • Overdue based on dates and statuses

hashtag
2. Key Concepts & Relationships

2.1 Entities

  • Collection

    • Reservations are enabled per collection via Account Management.

    • Each collection can have its own:

      • Reserve form

      • Check Out form

      • Check In form

  • Reservation

    • Tied to a collection and one or more assets in that collection.

    • Has:

      • Time window (start/end dates)

      • One or more reserved assets

      • Person/party reserved for

      • Status (Reserved, Checked Out, Checked In, Overdue)

      • Audit log entries for all actions (create, edit, cancel, check out, check in, delete).

  • User Roles & Permissions

    • Admins, Collaborators, Custom Roles can be granted granular permissions per collection:

      • View reservations

      • Create reservations

      • Edit reservations

      • Cancel reservations

      • Delete reservations

      • Perform Check Out and Check In

    • Permissions are enforced for every action and entry point (Calendar, side navigation, record, list view).

hashtag
3. Pre-requisites

3.1 Permissions

  • Permissions are configured per collection and control:

    • View reservations

    • Create reservations

    • Edit reservations

    • Cancel reservations

    • Delete reservations

    • Check Out / Check In

  • All actions must check:

    1. User role (Admin, Collaborator, Custom Role).

    2. Collection-specific permission set.

  • If a user lacks permission:

    • Action is blocked.

    • A clear, user-friendly error message is displayed indicating the reason (e.g., insufficient permissions).

3.2 Collection Setup

  • For each collection where Reservations are used:

    • Reservations must be toggled ON in Settings > Account Management.

    • Admin configures the following forms:

      • Reserve form

      • Check Out form

      • Check In form

    • Each form may include:

      • Required system fields (e.g., Reservation, Reserve for, Start date, End date, Check Out date, Check In date).

      • Additional custom fields as defined by the Admin.

hashtag
4. Step-by-Step Workflow

hashtag
4.1 Enabling Reservations for a Collection

  1. Admin navigation

    • Admin goes to Settings > Account Management.

  2. Toggle Reservations

    • Admin enables Reservations for one or more collections via a toggle.

  3. Configure Forms

    • For each enabled collection, Admin selects Manage to configure:

      • Reserve form

      • Check Out form

      • Check In form

Dependencies:

  • Organization entitlement and feature flag must allow Reservations.

  • User must be an Admin (or role with equivalent account-management permissions).

hashtag
4.2 Reservation Lifecycle

4.2.1 Creating a Reservation

Entry points:

  • From Calendar (Month/Week/Day/List views)

  • From Side Navigation

  • From Record view

Flow:

  1. Initiate Reserve

    • User clicks Reserve from any supported entry point.

  2. Reserve Form

    • System opens the configured Reserve form.

    • Required fields (non-exhaustive):

      • Reservation field (e.g., reservation name/identifier)

      • Reserve for (e.g., user, department, external party)

      • Start date

      • End date

    • Additional custom fields as configured for the collection.

  3. Availability Check

    • On submission:

      • System checks asset availability for the requested time frame.

      • Assets that are unavailable for any part of the requested period are:

        • Disabled in the selection UI

        • Accompanied by explanatory tooltips (e.g., conflicting reservations or check-outs).

  4. Asset Selection

    • User selects one or more available assets.

  5. Review & Submit

    • User reviews all details and submits the reservation.

    • System creates a new reservation record and sets status to Reserved.

    • Reservation appears in:

      • Calendar views (color-coded as Reserved)

      • List view

      • Activity stream (log entry: reservation created).

Constraints:

  • User must have create permission on the collection.

  • Reservation time window and asset selection must pass availability validation.

4.2.2 Check Out

Status condition:

  • Check Out is performed against a Reserved reservation.

Entry points:

  • From reservation details

  • From side navigation

Flow:

  1. Initiate Check Out

    • User selects Check Out for a reservation.

  2. Check Out Form

    • System opens the configured Check Out form.

    • Required fields:

      • Check Out date

    • Additional custom fields as configured.

  3. Asset Selection

    • User selects which reserved assets to check out:

      • Partial Check Out is allowed.

        • Example: Reservation has 5 assets; user checks out only 3.

    • System may allow:

      • Swapping unavailable assets for alternative ones:

        • If an asset is not available or cannot be checked out, user can select a different asset.

  4. Submit

    • On submission:

      • System updates the reservation:

        • Checked-out assets reflect Checked Out status.

        • Overall reservation status changes to Checked Out.

      • Relevant logs are recorded in the activity stream.

Constraints:

  • User must have Check Out permission.

  • Check Out cannot proceed if:

    • Required fields are missing.

    • Permission is insufficient (user-friendly error message shown).

4.2.3 Check In

Status condition:

  • Check In is performed against a Checked Out reservation.

Entry points:

  • From reservation details

  • From side navigation

Flow:

  1. Initiate Check In

    • User selects Check In for a reservation.

  2. Check In Form

    • System opens the configured Check In form.

    • Required fields:

      • Check In date

    • Additional custom fields as configured.

  3. Asset Selection

    • User specifies which checked-out assets are being returned:

      • Partial Check In is allowed.

        • Some assets can remain checked out while others are returned.

  4. Submit

    • On submission:

      • System updates the reservation:

        • Returned assets become Checked In.

        • Remaining assets stay Checked Out.

        • Overall reservation status:

          • Typically Checked In when all assets are returned.

          • May remain Checked Out (or similar) when assets are partially returned.

      • Activity stream logs the check-in action and asset-level changes.

Constraints:

  • User must have Check In permission.

  • Validation errors and permission issues produce clear error messages.

4.2.4 Deleting a Reservation

Permissions:

  • Only Admins or users with explicit delete permission on the collection may delete reservations.

Behavior:

  1. User selects Delete from reservation actions (e.g., in side panel, details view).

  2. System:

    • Permanently deletes the reservation record.

    • Removes it from:

      • Calendar (no longer displayed).

      • List view.

      • Activity stream (reservation-level log removed—implementation may keep internal audit as needed).

    • Frees up all associated reserved time slots for affected assets.

Constraints:

  • Cannot delete if user lacks delete permission (error message shown).

  • Impacts reporting and search results because the reservation record no longer exists.

hashtag
5. Calendar & Views

5.1 Calendar Views

  • Supported views:

    • Month

    • Week

    • Day

    • List

  • Reservations appear as events over their reserved time window.

5.2 Status Color-Coding

  • Reservations are visually differentiated by status:

    • Reserved

    • Checked Out

    • Checked In

    • Overdue (based on end date and business logic)

  • Color-coding helps users quickly identify reservation state.

5.3 Side Panel

  • When a reservation is selected in the Calendar/List view, a side panel shows:

    • Reservation summary details (key fields, dates, assets, status).

    • Available actions (subject to permissions and status), e.g.:

      • Edit

      • Delete

      • Check Out / Check In where applicable

hashtag
6. Search, Filter, and Reporting

6.1 Search & Filter

  • Users can search and filter reservations based on:

    • All core fields (e.g., dates, status, Reserve for).

    • All custom fields configured on the forms.

  • Filters can be combined to find specific reservations or sets of reservations.

6.2 Reservation Logs & Reporting

  • Reservation logs:

    • Store details of each lifecycle event:

      • Create

      • Edit

      • Cancel

      • Check Out

      • Check In

      • Delete

    • Are accessible for:

      • Reporting

      • Auditing

  • Even if the entitlement is turned off:

    • Historical logs remain viewable (no new Reservations can be created/executed, but history is preserved).

6.3 Automation

  • Automation triggers exist for reservation lifecycle events, enabling workflows such as:

    • Notifications on create/edit/cancel/check out/check in.

    • Reminders for upcoming reservations or overdue returns.

    • Integration with other systems based on status changes.

hashtag
7. Rules, Constraints, and Edge Cases

7.1 Partial Check In / Check Out

  • Supported:

    • Users can:

      • Check out subset of reserved assets.

      • Check in only some checked-out assets.

  • System maintains asset-level state:

    • Some assets may be Checked Out, others Checked In within the same reservation.

    • Overall reservation status reflects predominant or final state:

      • Regardless if all assets are returned, reservation is Checked In.

7.2 Permissions Enforcement

  • Every action (view, create, edit, cancel, check out, check in, delete) is:

    • Checked against:

      • User role

      • Collection-specific permissions

    • Blocked if insufficient, with:

      • Clear, user-friendly error message describing the reason (e.g., “You do not have permission to delete reservations in this collection.”).

7.3 Error Handling

  • On any failed action (e.g., availability check failure, missing required fields, permission issue), system must:

    • Show a concise, descriptive error message specifying:

      • What went wrong.

      • If applicable, what the user can do to resolve it (e.g., change dates, contact admin).

7.4 Activity Logging

  • The following are always logged in the activity stream:

    • Creation of a reservation

    • Edits to an existing reservation

    • Cancellations

    • Check Out events

    • Check In events

    • Deletion events

  • Logs should capture:

    • Who performed the action

    • When it was performed

    • Key changes (e.g., changed dates, assets).

PreviousInviting Users to a ModuleNextRoles & Permissions

Last updated