Passes & Permits — selling and issuing access

Marinas, campgrounds, and parks run on more than reservations. Day-use passes, boat launch permits, seasonal stickers, dog permits, vendor permits — all the little things people pay for and carry proof of. The Passes & Permits feature is one flexible system for all of them: define a type once, then issue it at the counter or let customers buy it online, cap how many exist, collect whatever information you need, and hand out a scannable QR proof.

It's deliberately generic. "Pass" and "permit" are the same thing here — you name each type whatever your guests call it.

Per-vessel (or per-trailer, per-rig) permits. Tick For a specific asset on a permit type and each permit is issued against one item rather than the account. A company with two boats applies twice and holds two permits that approve and expire independently, and any quota you set counts per asset — so a "one at a time" limit doesn't accidentally block their second boat. Applicants pick which item on the form, and can add a new one without leaving it.

Use Allowed asset types to say what kinds of thing qualify. A landing permit limited to Vessel won't let someone attach a trailer, and won't offer trailer as something they can add. Leave it empty and any of their items qualifies.

When you'd use this

Day passes / launch permits — one date, maybe a per-day quota so you don't oversell the ramp.
Seasonal or annual permits — a "2026 sticker" (the whole calendar year) or a rolling year from purchase.
Vendor / contractor permits — with custom fields and a repeatable "add staff member" section so a vendor lists everyone who'll be on site.
Anything you approve case-by-case — permits that go to a staff queue before they're valid.

How it fits together

A permit type is the template. You set its dates, limits, fee, whether it needs approval, and what information to collect.
An issued permit belongs to a customer's account. It has its dates, a status, and a QR proof they can show on their phone or print (there's a Print button right on the proof). Their active passes also appear on the portal home screen for quick access.
Staff scan that QR (or paste the reference) to validate it at the gate — and, for single-use permits, mark it used.

Setting up a type — the decisions that matter

Permit Types lives under Administration → Passes & Permits (it's setup, so it's kept with your other configuration; day-to-day Approvals and Scan / Validate stay on the main staff sidebar). Open it, create a type, and work through:

Dates. Three modes: Day (customer picks one date), Duration (picks a start; it runs for a set interval like 365 days), or Fixed (no date choice — either a rolling year from purchase or the current calendar year, for a "2026 permit"). Pick Fixed → Calendar year for annual stickers; pick Day for launch passes.
Start window (day/duration only). Limit when a permit can start — an absolute season (e.g. May 1–Sep 30) and/or a rolling lead time (e.g. no more than 30 days out). Leave blank for no limit.
Blackouts (day/duration only). Independently block days of the week (e.g. no Sunday launches) and specific dates (holidays, closures) from being chosen as the start date. The date picker warns and clears an invalid pick, and the system enforces it again on submit — so a blacked-out day can't slip through on either the counter or the portal.
Limits. Four independent caps, each optional: per day (protect a ramp's capacity), total (a hard cap on how many exist), per account ever (lifetime), and at a time (simultaneous). Use -1 for unlimited.
Fee. Link the fee to a real price-list item — this is required for paid permits so every dollar is tracked to a product, not a random line. No linked item = free.
Approval. Shall-issue means it's active immediately (after payment, if paid). Requires approval sends it to the approval queue first.
Single use. Turn on for a one-shot pass — scanning it marks it used so it can't be reused.
Offer on the customer portal. Turn on to let customers register/buy it online themselves. Give it a portal category (e.g. "Parking & Launch", "Vendor", "Tours") and it becomes a tab on the portal's Apply screen — customers click the category tabs across the top instead of scrolling one long list. Uncategorized passes get an "Other" tab.
Prerequisites & conflicts. Gate one pass on another. Requires — the account must already hold an active, non-expired permit of the listed type(s) before this one can be issued (e.g. a yearly vendor pass requires the approved vendor registration). Blocked by — holding an active, non-expired permit of the listed type(s) prevents issuing this one (e.g. an annual parking decal blocks buying daily parking). Both are checked at issue time, on the counter and the portal alike; a blocked customer gets a plain-language reason.
Custom fields. Add any fields you need — text, dates, dropdowns, file uploads, and repeatable groups. A repeatable group is how vendors "add staff member" as many times as needed, each with their own fields (and their own file upload, like an ID).

Buying and issuing

At the counter: open the customer's account → Passes & Permits tab → Issue. Pick the type, the date, fill the fields. Free shall-issue permits are active instantly; paid ones drop an invoice on the account.
Online: if the type is offered on the portal, the customer applies for it themselves under the Passes & Permits section. That page shows My Passes & Permits (what they hold, as cards with a View button for the proof) plus an Apply Here button that lets them pick which pass or permit to apply for. It's "Apply", not "Buy", on purpose — plenty of registrations (vendor permits, commercial-vessel registration) are free. When there's a fee, applying takes them straight to the payment screen; free or approval-required ones just appear in their list.
Paying: a paid permit always creates a normal invoice, paid the normal way (card or bank, whichever processor you use). Payment comes first, then approval — so a permit that's both paid and approval-required is paid up front, then reviewed; if you decline it, you refund.

Approving and scanning

Approvals (its own sidebar page, separate permission) lists everything waiting. Review the submitted details and files, then Approve or Decline with a reason — the customer is emailed either way.
Scan / Validate (separate permission again) is your gate tool. Point your device camera at the permit QR, upload a photo of it, use a hardware barcode scanner, or paste the reference — any of them shows VALID or why not, with the holder and an Open account link. For single-use permits, a Mark used button invalidates it on the spot. And you don't have to open this page first: when a staff member who's signed in (with the Scan permission) scans a permit QR from their phone, it drops them right onto this validate screen. Anyone else who scans the same QR just sees the customer's proof.

Common mistakes

Forgetting the price-list item on a paid type. The fee must link to a real price-list item — that's how it lands on an invoice and in your reports. If you can't save a paid type, that's why. Create the price-list item first.
Using a per-day cap when you meant a total cap (or vice-versa). Per-day protects a daily resource (30 launches a day). Total is a hard ceiling on how many exist (100 season stickers, ever). They're independent — set the one you actually mean, and leave the other at -1.
Expecting approval-required permits to be paid after approval. They're paid first. If you routinely refund declines, consider making high-decline types free-to-apply and charging on approval a different way, or set them shall-issue.
Turning on "offer on the portal" but no customers see it. The portal section only appears when a type is both active and portal-exposed (or the customer already holds a permit), and the portal's Passes & Permits section is enabled in portal settings. Check both.
Treating single-use as automatic. A single-use permit isn't consumed by the customer viewing their proof — it's consumed when staff scan and mark it used. Viewing the QR never invalidates it.

Passes & Permits — Selling and Issuing Access