Committee Roles and Permissions

Role-based access for sailing clubs

Committee Roles and Permissions

Two system roles plus your own custom roles, with granular permissions per domain - so the membership secretary can manage members without touching duties or settings.

Last updated 19 May 2026 · Built around real UK sailing club committee structures.

System roles

Two roles every SailHQ club starts with

Every club ships with the same two system roles. They cannot be deleted, renamed away, or have their core behaviour changed. They sit underneath any custom roles you build on top.

Admin

Full access to the platform. The admin role carries an admin flag that bypasses every permission check in the system. Anyone in this role can edit any member, run any duty, change any setting, and reach every part of the club's data.

Most clubs keep this role tight - the commodore, secretary and one or two technical leads. Day-to-day work flows through custom roles with narrower scope.

Sailor

The default member role. A sailor can sign in to the member portal, view their dashboard, sign up for vacant duty slots, request swaps, manage their own boats, see events and update their personal details.

Sailors do not see admin screens, the duty roster calendar, the membership approval queue or any settings panel. Everything they need lives in the member portal.

System roles are immutable. They cannot be deleted and the admin bypass cannot be turned off. Custom roles sit on top of this base layer, never replace it.

Custom roles

Roles shaped around your committee

Every UK sailing club's committee looks slightly different. One club has a membership secretary handling renewals and a separate treasurer chasing fees. Another rolls both jobs into one. The race officer co-ordinator at one club is the sailing secretary at the next. SailHQ does not pretend there is one right structure.

Build the custom roles your club actually has. Each role gets only the permissions they need to do their job. A new committee member added to the membership secretary role can immediately start renewing memberships without anyone wondering whether they can also see the duty rota or change the club logo.

SailHQ committees admin screen listing committee groups, public positions, and current role holders
Committee positions and current holders stay clear without being confused with access profiles.

Membership Secretary

Manages the member list, processes renewals, approves public sign-ups - no access to duties or settings.

Race Officer Co-ordinator

Builds series, manages duty types and the rota, approves swap requests - no access to membership fees.

Treasurer

Reads member subscriptions, payment status and reports - no edit rights on duties or boats.

Boat Park Manager

Edits boat records, storage locations and insurance dates - no access to membership data.

Bar Steward

Reads the member list to verify status at the bar - no edit rights anywhere.

Permissions per domain

Granular flags for every part of the platform

Permissions are grouped by domain. Within each domain, granular flags cover what a role can actually do - view, create, edit, delete, approve and so on. Every action in the platform runs a permission check at the point it is taken, not just at login.

Members

View member records, edit details, manage household groupings, change membership types, approve public sign-ups, archive resignations.

Duties

View the rota, create duty slots, edit assignments, approve swap requests, manage duty types and qualification gates.

Events

Create open meetings, training days and socials, edit details, manage signups, cancel events, view attendee lists.

Series

Build series templates, generate seasons in one click, edit individual races, manage default duty types per series.

Boats

View the boat registry, create and edit boat records, update storage and insurance, manage paid-until dates.

Settings

Edit club identity, branding, colours, logo, login background, location coordinates, weather thresholds, module toggles.

Newsletters

Compose newsletters, send to all members or specific groups, view send history, manage templates.

Reports

Read membership reports, duty fulfilment, renewal status, financial summaries, export to CSV.

Checked at every action

Permissions are enforced at the action layer, not just hidden in the UI. A member without permission to delete a duty cannot delete one even if they reach the endpoint directly. The framework refuses the action and logs it.

User-level overrides

Sometimes one specific person needs an exception. Direct permission overrides on a user account grant or restrict individual permissions on top of the role they hold. Useful for temporary cover, edge cases and one-off committee decisions.

Audit trail

Member status logs

Every change to a member's status is recorded - the previous status, the new status, the timestamp, and the admin who made the change. The record is permanent and visible to anyone with permission to read it.

The use case is straightforward. At AGM someone asks why Mary has been listed as lapsed since March. The status log shows the change, the date, and which committee member set it. The conversation moves on instead of stalling on a he-said-she-said.

The same trail covers suspensions, restorations, category changes from full to social, and resignations. It is the kind of defensible record a committee needs when a status decision is queried weeks or months later.

For the chair's seat - the visibility, governance and committee oversight side - the view for commodores sets out how SailHQ supports the role.

Not yet: the wider cross-platform audit log is on the roadmap. Member status history is live now and remains the permanent record for those changes.

How it fits

Where roles touch the rest of the platform

Permissions are not a standalone feature - they shape how every other module behaves. A few of the places this lands hardest:

Roles and permissions are on every plan

The full role and permission engine is included on Starter, Club, Performance and Elite. There are no upsells gating committee structure behind a higher tier - small clubs need clean access controls just as much as large ones.

See full pricing
Common questions

Roles and permissions, answered

How access control works for real committee structures.

There is no fixed cap. Most clubs settle on five to ten custom roles - membership secretary, race officer co-ordinator, treasurer, boat park manager, bar steward, training principal, junior section lead - on top of the two system roles. Each custom role gets its own granular permission set per domain. Roles can be added, edited and renamed at any time without touching the underlying user accounts.

Yes. Roles are attached to users via a pivot, so a single member can hold any combination. The committee chair who also runs the membership team picks up both role sets. Permissions stack additively, with user-level direct overrides available for the cases where one person genuinely needs an exception. The permission check runs at every action regardless of how many roles a member holds.

Assign the relevant role to the stand-in for as long as they need it, then unassign it when they hand the duty back. There is no fixed expiry date on role assignments, so the committee owns when access ends. For one-off cases such as covering a holiday, user-level permission overrides give a single member specific extra permissions without granting a full role.

Member status changes are recorded with the admin who made the change and the timestamp, which covers the bulk of AGM and dispute questions about who set someone's status to lapsed or suspended. Wider role and permission audit logs are on the roadmap. For now, the combination of role definitions, user-role assignments and member status logs gives committees a defensible record of who can do what and who changed what.

See how roles map to your committee

Book a demo and we will configure SailHQ around your committee structure - the actual roles your club uses, with the permissions each one needs and nothing more.