What you will learn
- How park events are listed, categorised, and promoted to residents
- What event permits need, and how they connect to facility bookings
- How facility holds prevent an event colliding with a booking
- What organisers need: applications, approvals, and requirements
- How attendance and feedback are tracked after events
What the project is
Park events range from a neighbourhood picnic to a multi-day festival, and they share a workflow: an organiser proposes an event, the department reviews it, a permit is issued with conditions, facilities are held, and the event is listed publicly. The calendar system holds that workflow and the public listing together, so a listed event is one that has actually been approved, and an approved event automatically holds its facilities and appears on the calendar residents browse.
The separation of listing and permitting is the classic failure. A calendar that lists events without checking permits will list events that never happen or happen without approval. A permitting system without a public calendar leaves residents unaware of events they would attend. The working systems tie the two: publication follows approval, and a permit change or cancellation updates the listing automatically.
Core features
Permit-linked publication is the feature. A calendar event that has not been approved should not be public, and an approved event should not need manual listing.
- Public event calendar with categories, parks, dates, and search, designed for residents browsing on phones.
- Event applications from organisers, with event details, expected attendance, and facility needs.
- Permit workflow: review, conditions, approval, and issuance, with the permit record attached to the event.
- Facility holds: approved events block their facilities on the booking calendar, preventing double-booking.
- Organiser communications: approval notices, condition reminders, and change or cancellation handling.
- Promotion tools: featured events, newsletters, and social sharing, so good events reach residents.
- Attendance and feedback: estimated and actual attendance, organiser feedback, and incident notes, for future planning.
How it is built
Build the permit workflow with parks staff before designing the public calendar. A calendar built on unapproved listings will publish events that should never have been public.
- Event and permit study: list event types, permit requirements, and conditions, and review how events are currently approved and listed.
- Permit model: application, review, conditions, and approval, tested on real past events.
- Calendar build: public listing driven by approved permits, with facility holds on the booking calendar.
- Organiser tools: applications, communications, and change handling, tested with real organisers.
- Review loop: attendance and feedback feeding future permit decisions, so recurring events improve year to year.
Tech considerations
The technical core is workflow state: an event's public visibility must always match its permit state. The calendar display follows from that integrity.
- Workflow engine with states for application, review, approved, published, and cancelled, and rules for transitions between them.
- Facility hold integration with the booking calendar, so an approved event blocks its facilities automatically.
- Public calendar with search, categories, and mobile-friendly event pages, fed only by approved events.
- Organiser portal with application tracking and document upload for insurance or site plans where required.
- Notification integration for approvals, conditions, changes, and cancellations, to organisers and to staff.
Challenges to plan for
Event calendars fail on unpermitted listings, facility collisions, and stale events. All three erode trust in the calendar as a source of truth.
- Unpermitted listings: events published before approval create public expectations for events that may never happen.
- Facility collisions: an event that does not hold its facilities will collide with a pavilion booking on the day.
- Stale events: a cancelled event left on the calendar sends residents to an empty park.
- Organiser burden: an application process that is harder than an email will be bypassed, and events will happen without permits.
Who it is for, and honest limits
This fits parks departments, municipalities, and park systems with regular public events. It fits less well for a park with one annual event, where a poster and a permit form may honestly be enough.
It does not create events or judge their merit. It makes events permitted, listed, and coordinated. If the permit policy is unclear, the system will surface the ambiguity, but the policy decision still sits with the department.
Frequently asked questions
Can anyone list an event?
Anyone can apply, but only approved events are published. The application, review, and approval workflow is what keeps the calendar trustworthy, and organisers should be able to track their application's status.
What if an event needs a pavilion that is already booked?
The facility hold check runs at application and approval time. A conflict blocks approval until the organiser chooses another facility or date, or the booking is resolved by staff with both parties informed.
How are recurring events handled?
As a series with one application and per-date permits where required, so a weekly market or summer concert series does not need a separate application for every date, but each date's facility hold is still enforced.
What happens when an approved event is cancelled?
The listing is removed or marked cancelled, facility holds are released, and staff and any ticket holders are notified. Cancellation should be a workflow step, not a manual deletion, so nothing is left stale.
Can residents submit events they want to attend?
Residents can suggest events, but suggestions are not listings. A suggestion becomes a listing only when an organiser applies and the department approves it, which keeps the calendar reliable.