An Airtable office booking request workflow can collect a preferred desk or room, the required time window and practical requirements, then show the coordinator’s confirmed reservation separately. miniExtensions supplies the employee-facing request experience; a responsible person resolves conflicts before anything is treated as booked.

This is a good starting point for a small office that does not need a full workplace-management system. Fictional Cedar Studio has two meeting rooms and several shared desks. The aim is clear requests and confirmed allocations, not instant booking, automatic conflict prevention or calendar synchronization.

Separate a preferred resource from a confirmed allocation

Alex asks for Meeting Room North on Tuesday from 10:00 to 11:30. Morgan requests the same room from 11:00 to noon. Both requests should remain visible to the coordinator; the first form submission should not silently make the second impossible or establish a reservation.

Ask about the underlying need as well as the preference. Alex needs a screen for six people; Morgan needs a quiet space for two. That lets the coordinator suggest Room South to Morgan without changing the original request or assuming every room is interchangeable.

Create resources, requests and reservations

  • Employees: Name as primary text, Work email as email and Team as single select.
  • Resources: Resource name as primary text, Type as single select with Desk or Room, Location as text, Capacity as number, Features as multiple select and Requestable as checkbox.
  • Requests: Request reference as primary text; Employee and Preferred resource as links; Requested start and Requested end as date/time fields; People as number; Requirements as long text; Request state as single select; Coordinator response as long text.
  • Reservations: Reservation reference as primary text; Employee, Source request and Assigned resource as links; Confirmed start and Confirmed end as date/time fields; Reservation state as single select; Confirmed by as text; Instructions as long text.
  • Change requests: Change reference as primary text; Employee and Reservation as links; Proposed start and Proposed end as date/time fields; Change reason as long text; Review state as single select.

One reservation covers one resource and one continuous time window. For two rooms, create two records. A recurring series needs individual occurrences if the coordinator must handle different conflicts on different dates; this example does not generate a recurring series automatically.

Give employees a request history they can understand

Use Requests as the Portal’s data table and Employee as the user link. Each additional displayed table needs its own direct Employee relationship, as explained in the Users Table documentation. Keep staff-managed Resources out of employee editing.

Use suitable login verification and personal-record views for requests, reservations and changes. In this simple setup, Resources appears only as a scoped linked-record picker; do not add it as a Portal data table because it has no Employee link. The picker can show approved office resources without revealing other employees’ meeting purposes. Do not use a public no-login view for private request records.

Offer only Requestable resources in the picker and inspect its actual choices, including searches and expanded records. Prevent creation or editing of room records through expanded linked forms. Label the submission button and confirmation language so employees understand they have requested a resource rather than reserved it.

A normal record-list view can support browsing history with configured creation. The view guide distinguishes this from the creation-only Form view. A calendar is useful for displaying dates, but a visual block on it does not enforce a time-range conflict rule.

Review the entire time window

The coordinator checks confirmed reservations for the requested resource, including any setup or cleanup allowance. A date match alone is insufficient: Alex’s 10:00–11:30 request overlaps Morgan’s 11:00–12:00 request even though their start times differ. Review the interval, not just identical timestamps.

For this first version, make that check manual. Staff also verifies capacity, equipment and any maintenance restrictions. If Room South fits Morgan’s need, the coordinator proposes it and records the response. Only after confirmation does staff create a Reservation with the agreed resource and time.

Keep the original request unchanged. The assigned resource may differ from the preference, and the confirmed time may differ from the requested time. Recording both makes it clear what was asked and what was agreed.

Prevent an edit from silently moving a booking

Show confirmed reservations as read-only records and direct amendments through Change requests. The record-editing guide documents disabling expansion and editing for a view. That is a view-specific control; audit other views and creation or unlinking controls as well.

Suppose Alex extends the meeting to noon. The change remains Pending while the coordinator checks the effect on the next reservation. An employee editing an original request should not automatically alter the confirmed booking. Once agreed, staff updates the reservation and records the outcome of the change request.

A cancellation also needs an explicit disposition. Staff can mark the reservation Cancelled, preserving its reference and previous time window. If a separate calendar entry exists, someone must update it through the normal calendar process. This workflow does not imply that the change is synchronized.

Make the office handoff and limits clear

Put practical instructions on the confirmed reservation, such as where to collect a display adapter. Keep access codes and sensitive physical-security details out of this example. A room allocation is not permission to enter a restricted facility or proof that a space meets every accessibility requirement.

For a broader client appointment workflow, see the appointment form guide. This office scenario instead focuses on shared physical resources, competing intervals and coordinator-confirmed alternatives.

Test two fictional employees requesting overlapping times, a resource marked unavailable, a changed time and a cancellation. Check personal access, saved links, status language and whether a confirmed reservation remains unchanged until staff approves a change. Use the published end-user configuration, not only the builder preview.

These are proposed acceptance checks, not observed results. If the office needs guaranteed instant allocation, automatic recurrence or live calendar conflict handling, evaluate a dedicated booking system. This model’s value is a straightforward queue where preferences, decisions and later changes remain distinct.