Room & facility bookings
What It Does
Facility bookings let mosque workspace users create bookable resources, such as classes, seminars, rooms, equipment, or other shared spaces. Bookings users can record booking requests in the workspace, publish booking request forms on tenant website pages, and process each request through approval, rejection, or cancellation.
Where to Find It
Open the dashboard, choose a mosque workspace, then use the Facilities and requests section.
Public booking forms appear on tenant website pages where a booking request section has been added in the CMS.
Public booking requests are only accepted once the mosque website is live. If the site has not been taken live yet, or has been paused, visitors cannot submit a booking request from the website. Staff can still record booking requests from the workspace regardless of the website go-live state. Take the site live from the Website go-live panel before sharing a booking page. See the Website CMS and Page Builder guide.
The Three-Dot Menu on Booking Requests
Each booking request shows its main action up front — Approve for new requests — while the rest live in the three-dot (⋮) menu at the top right of the request, grouped into sections:
- Booking — Reject request, Cancel booking. Both ask you to confirm first and explain what the requester will be told.
- Payment links — create a deposit or balance payment link, or cancel an existing link (cancelling asks you to confirm, because the link stops working immediately).
- Refunds — start a deposit or balance refund; you confirm the amount before anything is sent.
A small notification appears after each action so you know it worked.
Step by Step
Open the dashboard, choose a mosque workspace, then open its Bookings tab. Both forms below open in a panel on the right, so the list of rooms and bookings stays in view. Cancel closes the panel without saving; each time you open it, it starts empty.
Create a Resource
- Select Add a room.
- Enter a resource name, such as Main hall.
- Choose the resource type.
- Add capacity, location, and description if needed.
- Choose whether a deposit is required.
- Add an hourly rate if the mosque wants to track it.
- Select Add room. The panel closes and the room appears in the list.
Create a Booking Request
- Select New booking request (it is available once there is at least one room).
- Choose an active resource.
- Set the Starts and Ends date/time fields.
- Enter the requester name and email.
- Add requester phone, attendees, and notes if needed.
- Select Create booking request.
The system checks existing requested and approved bookings for the same resource before saving the request.
Process a Booking Request
- Find the request in the Booking requests list.
- Select Approve to confirm a requested booking.
- Open the three-dot (⋮) menu and choose Reject request to decline it, confirming when asked.
- Open the three-dot (⋮) menu and choose Cancel booking to cancel a requested or approved booking, confirming when asked.
Approving a request checks for overlapping requested or approved bookings again before the status changes. Rejected and cancelled bookings no longer block future booking requests for the same resource and time window.
Cancelling a booking also cancels any still-active deposit or balance payment links for that booking, so an unused pay-later link cannot be used after the booking is cancelled. If the booking has already collected a deposit or balance, the booking row keeps showing whether a refundable deposit or balance remains.
The requester receives an email after an approval, rejection, or cancellation. If the mosque has a verified sender domain, the email uses that branded sender; otherwise it uses the MAS sender with the mosque contact email as the reply-to address where available.
Bookings-capable staff receive an email when a public website booking request is submitted. The staff email goes to the workspace owner plus active admin and bookings users, and the requester email is used as the reply-to address.
Paid Booking Deposits
Booking resources can require a deposit amount. The payment foundation can create a Stripe PaymentIntent for a payable requested or approved booking, then apply a succeeded matching payment back to the booking record.
On public website booking forms, resources with a deposit show the deposit amount before the requester submits. After the booking request is sent, the requester can complete the deposit by card in the same booking section.
Bookings-capable staff can also create reusable payment links from a payable booking row in the workspace. Deposit links collect the immediate booking deposit or stored booking payment amount. Balance links collect the remaining balance stored for hourly-rate bookings after the deposit has been accounted for. Each link opens /bookings/pay/[token], shows whether it is collecting a deposit or balance, and lets the requester pay by card without signing in to MAS. If a link should no longer be used, choose the matching Cancel link action from the booking's three-dot (⋮) menu and confirm.
Reusable booking payment links expire after 14 days, can be cancelled by bookings-capable staff, and are marked used after a successful payment. The public booking request, same-session booking payment, and reusable payment-link endpoints also apply abuse controls. If a requester submits too many repeated requests in a short period, MAS asks them to wait and try again instead of creating more requests or payment attempts.
For resources with an hourly rate, MAS calculates the total hire amount from the requested start and end time. If the resource also requires a deposit, MAS stores the remaining balance due after that deposit. The public booking form shows an estimated total, deposit, and balance before submission where enough details are available, and the workspace booking row shows the stored total hire, balance due, and balance payment status.
For paid bookings, bookings-capable staff can choose Refund deposit or Refund balance from the booking's three-dot (⋮) menu, check or edit the refund amount, then select Confirm refund. The amount defaults to the remaining refundable deposit/payment or balance amount, so leaving it unchanged creates a full remaining refund; entering a smaller amount creates a partial refund. MAS records the latest Stripe refund id/status, cumulative refunded amount, reason, staff user, and refund timestamp on the booking, keeping deposit and balance refund records separate. Stripe refund webhooks reconcile dashboard-created refunds, duplicate refund events, and failed or cancelled updates for the latest tracked refund back onto the booking.
Publish a Public Booking Form
- Open the tenant website CMS.
- Add a Booking request section to the page layout.
- Enter a headline and optional introduction.
- Optionally enter a resource id or slug in Resource key to show one specific resource.
- Publish the page.
The public form only shows active booking resources. Requests submitted from the website are saved as requested bookings and use the same date, capacity, active-resource, overlap, and public rate-limit checks as workspace-created requests. If the selected resource has a deposit, the form starts the card payment step after the request is accepted.
What Each Screen Shows
The resource list shows name, slug, type, status, location, capacity, hourly rate, deposit setting, and description.
The booking request list shows requester details, resource name, date/time, attendee count, contact details, notes, booking status, deposit payment status, balance payment status, payment amount where stored, total hire amount where calculated, balance due where calculated, cumulative deposit and balance refund amounts where stored, cancellation settlement notices where relevant, the Approve action for new requests, and a three-dot (⋮) menu grouping the remaining actions — Reject/Cancel under Booking, create/cancel deposit and balance links under Payment links, and Refund deposit / Refund balance under Refunds (refunds open an amount field to confirm).
The public booking form shows resource selection, start and end time, name, email, optional phone, attendees, notes, and a Send booking request button.
Tips
Use clear resource names that staff will recognise, such as Main hall, Sisters classroom, or Seminar room 2.
Keep capacity accurate. Requests that exceed a resource capacity are rejected.
Booking requests are worked one row at a time. Approving a booking, creating or cancelling a payment link, or confirming a refund shows the spinner on that row's own button and leaves every other booking usable, so you can start on the next request without waiting for the first. Nothing on this panel changes before the server has agreed: a booking's status moves only once the change has been saved and the requester has been emailed, and if it cannot be saved the status stays as it was and a message says why.
This foundation records workspace and public website requests, prevents double-booking windows, lets staff approve, reject, or cancel requests, sends requester and staff emails, calculates hourly totals/balances, supports deposit payment capture through same-session public payment or staff-generated reusable deposit links, supports staff-generated balance payment links for stored balances, cancels unused payment links when a booking is cancelled, and supports full or partial staff-triggered refunds plus webhook reconciliation for paid booking payments.
Troubleshooting
If a booking request is rejected for a time clash, check the existing requested or approved bookings for that resource.
If approval fails for a request that was previously valid, another requested or approved booking may now overlap the same resource and time window.
If a requester does not receive a status email, check that their email address is correct. For branded sending, also check the workspace sender-domain status.
If a booking request is rejected for capacity, lower the attendee count or use a larger resource.
If resource creation fails, check that a deposit amount is entered when Deposit required is selected.
If no public booking form appears, check that the page has a Booking request section and at least one active booking resource.
If a requester is asked to wait before trying again, they have submitted too many booking or payment requests in a short period. Ask them to pause briefly and retry once the wait period has passed.
