Gymkhana Tools helps riding-club volunteers manage club setup, memberships, riders, gymkhana registration, run order, scribe result entry, live public results, records, and season standings.

The features you see depend on your assigned role. Ordinary club users work in one club at a time. The club name shown beneath the Gymkhana Tools logo is the current club context. If that club name is wrong, stop before entering or changing event data and contact an administrator.

Platform administration is separate from ordinary club operation. Platform administrators manage club onboarding and lifecycle at a high level; they do not run registration, scribe, rider, member, or event-day workflows for a club.

Getting Started

Signing In

Role required: any active Gymkhana Tools account.

  1. Open Gymkhana Tools.
  2. Enter your email/login and password on the sign-in page.
  3. Select the sign-in button.
  4. Confirm that the page that opens matches your expected role:
  • Club administrators land on the Control Center.
  • Registration volunteers land on Registration.
  • Announcer/scribe users land on Announcer / Scribe.
  • Platform administrators land on Platform Administration.

If sign-in fails, recheck the email/login and password. If the account or club has been deactivated, contact the appropriate administrator.

Signing Out

Role required: any signed-in user.

  1. Select Sign out in the sidebar or workspace navigation.
  2. Confirm the next person using the device is not still signed in as you.

Gymkhana Tools sessions are time limited. If the app asks you to sign in again during a long day, sign back in and confirm the club name before continuing.

Identifying the Current Club

Role required: any ordinary club user.

The current club name appears beneath the Gymkhana Tools logo on signed-in club pages. That name comes from your account. Ordinary users do not switch clubs inside the application. A volunteer who works with multiple clubs needs a separate login for each club.

Role-Based Menus

Only functions allowed for your account appear in normal navigation. Club, Platform, and Registration workspaces use a persistent left sidebar on laptop/desktop widths and an offcanvas menu button on narrower screens. Registration keeps every link visible: Overview contains Registration Home; Registration contains Gymkhana Registration and Online Submissions; and Management contains Riders & Horses and Reconciliation. In the club Administrator sidebar, the section containing the current page opens automatically and stays visible. Select another section heading to browse its destinations; opening a different browsing section closes the previous one. Announcer/Scribe retains a full-width event-day workspace with collapsible top navigation.

Club Administrator navigation is organized as Overview, Club, People, Operations, and System. Overview → Control Center returns to the Administrator landing page. Use Operations → Registration or Operations → Announcer/Scribe to open their event-day workspaces. These links expose workflows Administrators are already authorized to use; navigation visibility does not change route authorization.

The Control Center provides a compact active Member/Rider/Registration summary and focuses on the current or next Gymkhana. Registered Riders counts distinct Riders for that Gymkhana, while Registrations counts class-specific entries, so a Rider entered in two classes contributes once to Registered Riders and twice to Registrations. Its actions open Registration, Announcer/Scribe, or Review Gymkhana for that event. Use the small Records quick action for record review; use the sidebar, rather than dashboard destination cards, for all other administration.

Club and People administration pages use one compact workspace layout: the header identifies the current section and page, related information is separated by clear headings, forms are left-aligned at a readable width, and list pages place actions and compact tables together. On narrow screens, header actions wrap and related field columns stack into one column. Each page retains its existing Save, Add, review, and account-management workflow.

If a menu or action is not visible:

  1. Confirm you are signed in with the correct account.
  2. Confirm the club name beneath the logo is correct.
  3. Ask a club administrator to verify your role.
  4. Do not ask another volunteer to share their account.

Password Requirements

When an administrator creates, resets, or bootstraps an account password, use at least 16 characters. Long passphrases are encouraged, spaces are allowed, and Gymkhana Tools does not require a special character, uppercase letter, number, or other composition formula. Common or easily guessed complete passwords are rejected. Password-manager-generated passwords, paste, and browser autofill remain supported.

The same requirements apply to club users, platform administrators, the first administrator created during Onboard Club, and the cmd/platformadmin bootstrap/recovery command. Existing passwords do not need to be changed solely because of this policy.

Roles and Responsibilities

Club Administrator

Club administrators set up and maintain the club's operating data. They manage Club Profile, Rider Classes, Event Types, Seasons, Gymkhanas, Membership Configuration, Club Users, Members, Riders and Horses, Records, and administrative audit/build information. They can read formal Release Notes and can also use registration and scribe workflows when needed.

Registration Volunteer

Registration volunteers use Registration, Riders & Horses, Gymkhana Registration, Add Competitor, Edit Competitor, entry filters, Record Payment, Reconciliation/history, Checked In tracking, scratches, additional horse runs, and Run Order Adjustment. They do not manage club-wide setup such as seasons, event types, membership configuration, or club users.

Announcer/Scribe

Announcer/scribe users use Announcer / Scribe, result-entry filters, run queues, Current Run Entry, Correct Existing Result, Restore Scratched Run, the Results panel, Fastest Times - All Classes, Records, and Season Standings when a public live token exists.

Platform Administrator

Platform administrators manage clubs at the platform level. They can onboard clubs, activate or deactivate clubs, regenerate a club public live token, manage ordinary club Administrator accounts, manage platform administrator accounts, and read formal Release Notes. They do not manage routine Registration or Announcer/Scribe accounts and do not replace club administrators for routine club operation.

Release Notes and Build Information

Role required: ordinary club Administrator or Platform Administrator.

Club and Platform Administrators open System → Release Notes in their respective sidebars. The page selects the newest available formal release by default; select another version from Available releases to read its notes. On a narrow screen, the release list appears above the selected content.

Release Notes summarize user-visible and Administrator-relevant changes in formal releases. They are read-only. Registration and Announcer/Scribe users do not have access, and the notes are not published through Public Live.

Release Notes do not identify the application build currently running. Club Administrators use System → Build Information for the running Version, Git commit, and Build timestamp. Platform Administrators can view the running build metadata on the Platform Administration overview. A development build may therefore display older formal Release Notes while Build Information identifies the current development version.

Administrator Audit Log

Role required: ordinary club Administrator. Registration and Announcer/Scribe users do not have access.

Open System → Audit. Use any combination of Activity, Gymkhana, Event, Class, User, Action, From Date (UTC), and Through Date (UTC), then select Apply Filters. Clear Filters returns to full club history. The page shows 100 newest entries at a time; use Older and Newer to move between pages while preserving active filters.

Scribe entries use readable actions: Result Recorded, Result Corrected, Result Scratched, Result Restored, Result Reset to Pending, Re-Ride Required, and Re-Ride Returned to Queue. Their summary identifies Class, Event, rider, horse, and result/time, with the gymkhana and Primary or Additional-horse run context beneath it. Re-Ride Required, Returned to Queue, and the later Result Recorded resolution remain separate reconstructable actions. Reset rows summarize the prior result and preserve the removed status/time/penalty values in View details. Administration and Registration rows retain their entity-oriented presentation.

All Audit Log timestamps and date boundaries use UTC and are labeled. From Date starts at 00:00:00 UTC on the selected date. Through Date includes the whole selected UTC date. The timestamp means Gymkhana Tools persisted the action at that time; it is not an official arena or timer-beam timestamp.

To approximate when a class such as Lead Line finished, select its Gymkhana, choose Scribe Activity, select the Class and optionally Event, then inspect the newest relevant successful result. Older historical entries that did not store Gymkhana/Event/Class snapshot IDs may not appear under those filters.

Platform Administrator Account Management

Role required: active platform administrator.

Open Platform Administrators from the Platform Administration sidebar.

View Platform Administrators

The Platform Administrators page lists platform administrator Display Name, Email/Login, Active or Inactive status, Created date, and available actions. The current account is marked You. Club users do not appear on this page.

Add a Platform Administrator

  1. Select Add Platform Administrator.
  2. Enter Display Name.
  3. Enter Email/Login.
  4. Enter Password and Confirm Password.
  5. Leave Active checked unless the account should be created inactive.
  6. Select Save Platform Administrator.

Password and Confirm Password must match and follow Password Requirements.

Gymkhana Tools creates a clubless platform administrator account. It does not create a club membership, ordinary role assignment, or club user record. Duplicate Email/Login values are rejected with That email/login is already in use.

Edit a Platform Administrator

  1. On Platform Administrators, select Edit.
  2. Update Display Name or Email/Login as needed.
  3. Change Active only when intentionally activating or deactivating the account.
  4. Select Save Platform Administrator.

The form does not expose club ID, ordinary role, or platform role fields. Platform administrators cannot be converted into ordinary club users from this page.

Activate or Deactivate

Use Activate or Deactivate on the Platform Administrators list. Deactivate asks for browser confirmation with Deactivate this platform administrator? Deactivation preserves the account record and prevents future sign-in while inactive.

Gymkhana Tools rejects self-deactivation. It also rejects any deactivation that would leave the platform with no active platform administrator and shows The platform must keep at least one active platform administrator.

Reset a Platform Administrator Password

  1. On Platform Administrators, select Reset Password.
  2. Enter New Password and Confirm New Password.
  3. Select Reset Password.
  4. Confirm the browser prompt Reset this platform administrator password?

New Password and Confirm New Password must match and follow Password Requirements.

The existing password and password hash are never shown. Reset Password assigns the new password directly; Gymkhana Tools does not send reset email, invitation email, MFA challenge, or password-reset token in this workflow.

Bootstrap and Recovery

Normal ongoing platform administrator account management should use Platform Administrators in the application. The cmd/platformadmin command remains for bootstrap or recovery when no valid platform administrator can sign in or the web UI is unavailable. That command prompts for password and confirmation, enforces Password Requirements, and should be run only by an authorized operator against the intended database. A rejected password is not displayed, hashed, or saved.

Onboarding a Club

Role required: active platform administrator.

  1. Open Clubs from Platform Administration.
  2. Select Onboard Club.
  3. Enter Club Name and choose Active as intended.
  4. Under First Administrator, enter Display Name and a globally unique Email/Login.
  5. Enter Initial Password and Confirm Password. They must match and follow Password Requirements.
  6. Select Save Club.

Gymkhana Tools creates the club, first active ordinary club administrator, initial public live token, and platform audit record together. It does not seed seasons, rider classes, event types, gymkhanas, riders, members, registrations, results, or extra users.

If the club is created inactive, the first administrator account still exists but cannot use club workflows until the club is activated. Share the initial credential only through an approved private method.

Managing a Club's Administrators from Platform Administration

Role required: active platform administrator.

Open Platform Administration, select Clubs, then select View for the intended club. The Administrators area on Club Detail shows only ordinary Administrator accounts belonging to that club. Registration and Announcer/Scribe users do not appear and cannot be managed from this area.

Add an Administrator

  1. On Club Detail, select Add Administrator.
  2. Enter Display Name.
  3. Enter a globally unique Email/Login.
  4. Enter Initial Password and Confirm Password. They must match and follow Password Requirements.
  5. Leave Active checked unless the account should be created inactive.
  6. Select Save Administrator.

Gymkhana Tools assigns the current club and ordinary Administrator role. There is no club selector or role selector on the form, and the account is not a Platform Administrator. A duplicate Email/Login shows the generic message That email/login is already in use without identifying the other account or club.

Edit Administrator Identity

  1. In the Club Detail Administrators area, select Edit for the intended Administrator.
  2. Update Display Name or Email/Login.
  3. Select Save Administrator.

Edit does not change the account's club, Administrator role, active state, or platform identity. Use the separate Activate or Deactivate action for active state. This platform support workflow intentionally permits Email/Login correction even though the ordinary club Users workflow keeps Email/Login read-only after creation.

Reset an Administrator Password

  1. In the Club Detail Administrators area, select Reset Password.
  2. Enter New Password and Confirm New Password. They must match and follow Password Requirements.
  3. Select Reset Password.
  4. Confirm Reset this club administrator password?

The existing password and hash are never shown. The new password applies to future sign-ins, but an already authenticated session is not invalidated automatically. This workflow does not send email, create a reset token, or require a password change at next sign-in.

Activate or Deactivate an Administrator

Use Activate or Deactivate in the Club Detail Administrators area. Deactivate asks Deactivate this club administrator? Deactivation preserves the account and its history.

Gymkhana Tools rejects a deactivation that would leave the club with no active ordinary Administrator and shows The club must keep at least one active administrator. This protection also applies while the club itself is inactive, so an Administrator remains available for future club reactivation.

Replace a Departing Administrator Safely

  1. Add the replacement with Add Administrator.
  2. Verify the replacement account exists and, in the appropriate test or deployed environment, can sign in.
  3. Return to the club's Club Detail page.
  4. Deactivate the departing Administrator.

There is no Replace Administrator transfer action. Do not deactivate the departing Administrator before another active Administrator has been created and verified.

Every successful add, identity edit, password reset, activation, and deactivation creates a durable audit entry associated with the affected club. Platform Administrators never gain a club session, ordinary club role, or impersonation access through these controls.

Initial Club Setup

Role required: club administrator.

Use this order for a new or freshly onboarded club:

  1. Open Club Profile and confirm Club Name, contact information, Run Position Terminology, Points Configuration, Active, Public Live Scoreboard settings, and Club Time Zone. Then open Club → Registration Settings and confirm the Online Registration policies.
  2. Open Rider Classes and create the divisions/classes riders will use.
  3. Open Event Types and create the reusable gymkhana events.
  4. Open Seasons and create the season date range before creating gymkhanas.
  5. Open Membership Configuration and confirm Membership Types, Membership Classifications, Membership Statuses, Payment Statuses, and Committees.
  6. Open Club Users and create volunteer accounts for administrators, registration volunteers, and announcer/scribe users.
  7. Open Members and enter member records that should be available for registration lookup and season standings eligibility.
  8. Open Riders and Horses for off-event rider cleanup or pre-entry rider maintenance.
  9. Open Gymkhanas and create the gymkhana for the correct season.
  10. From the Gymkhanas list, open Configure Gymkhana Events for the gymkhana, select included Event Types, set Run Order, and configure Event Groups if needed.
  11. Before registration begins, confirm the gymkhana is Active and has the intended Status, selected events, rider classes, event-day registration times, and—if enabled—online-registration window.

Do not begin event-day registration until the gymkhana has selected events. Add Competitor is disabled when no events are configured for the gymkhana.

Accountless online registration uses the club registration URL /register/{registration-token}. It does not require or create a competitor, member, family, or Rider login.

In Club Profile, enter the club's IANA time zone, such as America/Denver. The time zone may remain blank until online registration is enabled for a gymkhana. In Club → Registration Settings, choose an Online Registration Eligibility policy and a Submission Processing policy. New clubs and upgraded clubs default to Members only and Staff review required.

The Online Registration area in Club → Registration Settings shows the Registration Token and complete generic Online Registration URL. Use that generic link for general publication; registrants enter a Membership Code manually when applicable. It is deliberately different from the Public Live token. Use Regenerate Registration Token only when every generic and member-specific registration link should stop working; regeneration does not change Public Live links. Treat the URL as a capability and share it only through the club's intended channels.

The public portal lists only active Draft/Open gymkhanas whose configured windows are open. A Membership Code is required for Members only and optional under the other eligibility policies. A member-specific link copied from View Member opens this same portal and prefills that field when JavaScript is available; manual entry remains available through the generic link and when JavaScript is unavailable. The link does not log in or authenticate the member, and the code is never echoed after submission.

For a member registration, enter a complete Membership Code or open a member-specific link that prefills it. The form validates a complete code automatically—prefilled codes immediately and manually entered codes when entry is complete and the field changes—without a normal Validate button. A current same-club Individual or Family membership displays Who are you registering? with first names only. Choose the participant, then complete Rider Class, optional Preferred Name, Primary Horse and Events, and optional Additional Horse and Events. Stored First Name, Last Name, birthdate, contact, guardian, and emergency fields are not displayed or editable; final submission reloads them from the selected member. A person who has never competed still appears. One exact linked Rider is reused; no Rider follows the ordinary safe creation path; multiple or broken Rider links go to Pending Review. If JavaScript is unavailable, the fallback Validate Membership Code control returns the same server-rendered state and, because codes are not echoed, asks you to re-enter the code for final submission.

If two people in one membership have the same normalized first name, the site does not show indistinguishable choices or reveal surnames. It displays the existing full form with a generic explanation, preserves the verified membership association on submission, and sends the intake to staff review. Invalid, expired, inactive, wrong-club, or otherwise unusable codes show one generic message and no names.

When no Membership Code is supplied and club policy permits nonmembers, the existing full form remains: enter First Name, Last Name, optional birthdate, contact/guardian/emergency information, Rider Class, Primary Horse and exact Events, and optional Additional Horse and its exact Events.

Submission Processing is separate from eligibility. Staff review always holds submissions. Automatic processing accepts only a safe identity/eligibility result; ambiguous identity, uncertain eligibility in hybrid processing, a concurrent same-name Rider, or an existing same-Rider/class entry is held for review. A pending-review confirmation means no Rider, entry, run order, or event rows were created. An accepted confirmation means the ordinary Registration records were created atomically and will appear in the existing event-day workflow. When Online Payments is enabled and usable, a positive public-registration quote requires Square-hosted checkout; verified payment confirmation creates either a paid Pending Review submission or an accepted Registration with one Card / Online / Square collection. Zero-dollar quotes and disabled or unconfigured Online Payments retain direct submission. This release has no registrant editing/withdrawal or household session; authorized staff process pending intake through Registration → Online Submissions.

Maintaining Event Rules

Role required: club administrator.

Open Club → Event Types. Use Add Event Type or Edit for an existing Event Type. Description, Pattern Rules, and Penalty Rules are the authoritative rule fields.

Description is a normal plain-text field. Pattern Rules and Penalty Rules support basic Markdown formatting through Bold, Italic, Heading, Bulleted List, Numbered List, and Link buttons. Select existing text before using a button when you want to format that text; with no selection, the button inserts example text that you can replace. Existing plain text remains valid and editable.

Select Preview Rules to render the current unsaved Pattern Rules and Penalty Rules below the form. Description is not included in Preview Rules. Preview does not save Name, rule text, Sort Order, or Active state. Continue editing and preview again as needed, then select Save Event Type when the source is correct. Empty rule sections are omitted, and when both previewed fields are empty the preview says No rules have been entered. Images, embedded media, arbitrary HTML, scripts, styling, and unsafe links are not supported.

Managing Club Users

Role required: club administrator.

Open People → Users.

Creating Accounts

  1. Select Add User.
  2. Enter Display Name.
  3. Enter Email/Login.
  4. Choose Role.
  5. Enter Initial Password and Confirm Password.
  6. Leave Active checked unless the account should not be usable yet.
  7. Select Save User.

Initial Password and Confirm Password must match and follow Password Requirements.

Allowed roles are Administrator, Registration, and Announcer/Scribe. The application does not send invitation email, deliver credentials, require password change on next sign-in, or provide self-service password reset.

Editing Accounts

  1. On Club Users, select Edit for the account.
  2. Update Display Name or Role.
  3. Select Save User.

Email/Login is set when the account is created and is read-only on Edit User.

Resetting Passwords

  1. On Club Users, select Reset Password for the account.
  2. Enter New Password and Confirm Password.
  3. Select Reset Password.
  4. Give the new password to the volunteer through an approved private method.

New Password and Confirm Password must match and follow Password Requirements.

A password reset changes future sign-ins. It does not necessarily end an already active session immediately.

Activating and Deactivating Users

Use Activate or Deactivate on the Club Users list. Deactivation preserves the account record. Deactivate asks for browser confirmation with Deactivate this user?

Administrator protections are enforced: you cannot deactivate yourself, deactivate the last active administrator, or demote the last active administrator. Club administrators manage only ordinary users in their own club. Platform administrators and users from other clubs do not appear in Club Users.

Membership Management

Role required: club administrator.

Membership setup is split between Membership Configuration and Members.

Membership Configuration

Open Club → Membership Configuration. Configure:

  • Membership Types
  • Membership Classifications
  • Membership Statuses
  • Payment Statuses
  • Committees

Each list supports Add, Edit, Show Inactive or Hide Inactive, and Archive where available. Archived configuration items become inactive but remain visible where existing member records already use them.

Member Records

Open People, then Members.

The Members list shows a concise summary: Member Name, Type, Voting, Expiration, Membership Status, Payment Status, Buckle Eligible, and Actions. Use View for the full read-only member record, Edit to change it, Deactivate to archive it without deleting it, and Show Inactive when archived records need review.

Member forms include Membership Name, Membership Type, Classification, Date Received / Start Date, Expiration Date, Membership Status, Payment Status, Hardship Fund Donation, Buckle Eligible, First Name, Last Name, Contact Name, Birthdate, Voting Member, Phone, Email, Address, Primary Family Member, Emergency Contact, Committee Interests, and Notes.

Membership Status and Payment Status describe real-world standing and payment state. Archiving a member is separate from those fields. Season standings include active linked club members only; changing a descriptive status does not by itself prove standings eligibility if the member record is archived or the rider is not linked to a member.

Every top-level member has a Membership Code shown on View Member in grouped form for readability. The code is not shown on the Members list. The same page provides a read-only, copyable Online Registration Link for direct email, newsletter, message, or printed communication. Forwarding that personalized link shares the Membership Code; it does not authenticate the recipient. Use the generic Online Registration URL from Club → Registration Settings for broad publication and the member-specific link for direct communication.

A secondary family member shares the top-level primary member's code. Its View page identifies the primary, displays that shared code, and provides the same Family Online Registration Link, but does not offer regeneration. Assigning a top-level member to a primary family member removes the old separate code; promoting a secondary member to top-level creates a new code. A Membership Code identifies the membership only—it is not a login, rider identity, or proof of current eligibility.

Use Regenerate Membership Code if a code or personalized link is compromised. Regeneration immediately makes previously distributed member-specific links unusable because they contain the old code; it does not change the generic club Online Registration URL. No email is sent by Gymkhana Tools—staff copy the link into their chosen communication channel.

For online registration, current eligibility requires an unarchived member record with Membership Status Active and an expiration date that has not passed. Payment Status and Membership Classification remain administrative descriptors and are not eligibility switches. An Individual or Family code does not rewrite or independently authenticate a Rider. Paired with the valid club registration link, it may show only the exact membership's active people's first names for Who are you registering?. Choosing one reuses a Rider only through that person's exact link; ambiguity goes to review. It does not reveal surnames, contact details, membership administration, or a general family roster.

Riders and Horses

Role required: club administrator or registration volunteer.

Open Registration → Riders & Horses, or open People → Riders & Horses as an Administrator.

Manage Riders is off-event rider maintenance. It is different from Gymkhana Registration, which registers a competitor for one selected gymkhana.

Rider forms include First Name, optional Preferred Name, Last Name, a Legacy / Default Rider Class, Linked Member, Birthdate, Phone, Email, Parent / Guardian Name, Emergency Contact Name, Emergency Contact Phone, Notes, and Active. Linked Member selects the individual Member record represented by the Rider, including a specific secondary person within a Family membership; it does not mean the Family primary member should be selected for every Rider in that membership. First Name and Last Name remain the authoritative identity. The legacy/default class is retained for compatibility and does not define identity or a gymkhana participation; Registration entry class is authoritative. When Preferred Name exists, rider administration shows First Last (Preferred) while event-day and public presentation uses Preferred Last. Clear Preferred Name to restore the ordinary First Last display; this updates the same rider rather than creating another identity.

Use Manage Riders when you need to search active/inactive riders, update contact or emergency information, link a rider to a member, change a rider class outside a specific event, add notes, reactivate a rider, or deactivate a rider. Deactivation archives the rider without deleting it and preserves historical event data.

Reconciling Historical Duplicate Riders

Role required: club Administrator. Registration volunteers cannot use this data-integrity workflow.

From Riders and Horses, select Possible Duplicates. The list groups at least two distinct unreconciled Rider records with the same normalized First Name and Last Name and labels additional same-membership, Birthdate, Phone, or Email evidence when present. Multiple entries, classes, horses, or evidence rows for one Rider do not create a duplicate group. A group is only a suggestion: same-name people can be different, and viewing or leaving a group never changes data.

Select Review Records on a candidate card to open the exact Riders shown in that group; there is no separate Rider-selection step. Compare status, Preferred Name, Birthdate, Phone, Email, membership, historical classes, entry dates/counts, and horse records. If the records are not certainly the same person, select Cancel Without Changes. If they are the same person:

  1. Explicitly select the canonical Rider that should remain authoritative. No Rider is preselected.
  2. For every conflicting nonblank profile field, explicitly select the value to retain. A single nonblank value is preserved automatically.

Legacy / Default Rider Class choices display the configured class name and change only the canonical Rider's compatibility profile value; historical Gymkhana Entry classes remain unchanged.

  1. Review blockers. Different linked memberships must first be corrected through normal Rider editing. Entries for both Riders in the same Gymkhana and Rider Class require separate deliberate data review and cannot be reconciled here.
  2. Check the confirmation only after verifying the identity and choices, then select Reconcile Riders.

Success moves both horse records and all nonconflicting Gymkhana entries to the canonical Rider. It does not merge same-name horses or rewrite Events, scratches, Primary/Additional Horse runs, run order, results, or Re-Ride state. The obsolete Rider remains an inactive historical tombstone pointing to the canonical Rider, appears as such only when inactive Riders are shown, and is no longer available as an independent Registration candidate. The Audit Log records the canonical and duplicate Rider IDs and safe moved-record counts.

Horse handling is event-specific in the current application. The Add Competitor page has Horse Name. The Edit Competitor page calls this Primary Horse Name and also supports Additional Horse Runs. There is no standalone horse-management dashboard.

Preparing a Season

Role required: club administrator.

Open Club → Seasons.

  1. Select Add Season.
  2. Enter Season Name.
  3. Enter Start Date and End Date.
  4. Choose Status: Draft, Active, Completed, or Archived.
  5. Add Notes if useful.
  6. Check Default Season if this should be the normal selection.
  7. Select Save Season.

Season names must be unique within the club. Season date ranges cannot overlap another season for the same club. If a season already has linked gymkhanas, date changes must keep those gymkhanas inside the season range.

Archived seasons remain available for history and standings but are not offered for new gymkhana creation.

Preparing a Gymkhana

Role required: club administrator.

Open Club → Gymkhanas.

  1. Select Add Gymkhana.
  2. Enter Name.
  3. Select Season.
  4. Enter Event Date. The date must fall within the selected season.
  5. Enter Start Time if useful.
  6. Choose Status: Draft, Open, Closed, Completed, or Cancelled.
  7. If this gymkhana should accept online registration, check Enable Online Registration and enter Online Registration Opens and Online Registration Closes in the displayed club time zone. The opening must be before the closing.
  8. Enter Registration Opens and Registration Closes if the club tracks those event-day time-only values. They are separate from the online window.
  9. Enter Location and Arena Name.
  10. Enter Event Director Name, Phone, and Email if useful.
  11. Add Notes.
  12. Leave Active checked unless this gymkhana should be hidden from normal active lists.
  13. Select Save Gymkhana.

The club must have a valid IANA time zone before online registration can be enabled. Daylight-saving wall times that are ambiguous or do not exist are rejected. Clearing Enable Online Registration and saving clears that gymkhana's stored online window and immediately removes it from the public portal.

After the gymkhana exists, select Events or Configure Gymkhana Events from the Gymkhanas area.

  1. Check Include for each Event Type that belongs in the gymkhana.
  2. Set Run Order values.
  3. Select Save Gymkhana Events.
  4. If events should be grouped for event-day flow, enter New Group Name, select included Selected Event rows, set Group Order, and select Create Event Group.
  5. For an existing group, edit Group Name, Include, or Group Order, then select Save Group.
  6. Use Delete only when you intend to remove the event group. The page asks Delete this event group?

Event Groups affect scribe/live execution order only. They do not combine results, records, daily placings, or season points. The order of events inside a group controls the default row display order; officials may still complete those constituent events in any order for a rider.

Registration Workflow

Registration Home has three status zones. At a Glance shows Registered Riders, Checked In Riders, and pending intake. Current / Next Gymkhana shows the Gymkhana name, status, date, optional location, configured Events, and Registrations; select Open Registration to open it directly. Needs Attention appears only when pending submissions or positive balances require action. Use the Registration sidebar rather than looking for destination cards on the Home page.

Reviewing Online Submissions

Open Registration, then Open Online Submissions. The compact list is scoped to your signed-in club, defaults to Pending Review, and keeps Accepted and Declined history available. Submitted timestamps on both the list and review page use the club's configured IANA time zone and include the applicable abbreviation, such as MDT or MST. Use the Gymkhana and Status controls under Filters, then select Review. Back to Online Submissions preserves those filters; Accept and Decline also retain the same list context, so a completed item naturally leaves a Pending Review queue rather than switching the list to All statuses.

The review page keeps Submitted Registration and Horses and Exact Events together as the main review content, with Membership Evidence, Registration Fees, and Same-Club Rider Candidates as supporting evidence. The Decision section contains the acceptance identity-resolution workflow and the durable decline action. The page shows the submitted authoritative name, optional Preferred Name, birthdate, contact/guardian/emergency context, Rider Class, Primary Horse and exact Events, Additional Horse and exact Events, submitted time, and a plain-language review reason. It also shows whether intake validated an Individual or Family membership, its safe identity/current eligibility, and same-club Rider candidates. The raw Membership Code is never displayed. A Family membership anchors the family membership only; it never chooses a Rider automatically.

To accept:

  1. Review same-name candidates using authoritative name plus safe supporting context. Preferred Name, class history, horse, row age, and ID order are not identity proof.
  2. Select the correct existing Rider, or choose Create New Rider. With multiple same-name candidates, each Use First Last choice repeats the matching safe context from Same-Club Rider Candidates, such as Preferred Name, available birthdate/contact details, class history, membership-link state, and inactive state. Use that context to map the radio choice to the intended Rider; it is presentation evidence, not matching proof. When same-name candidates exist, confirm explicitly that the new Rider is a separate person.
  3. For an eligible code-verified membership, the selected Rider shows the applicable membership state. Already linked to this membership. requires no action. For an eligible unlinked existing Rider, select Link this Rider to the verified membership only when that Rider is the person covered by the membership. For Create New Rider, select Link the new Rider to this membership. A Rider already linked to another membership is blocked; resolve that conflict through the authorized Rider/member workflow rather than relinking or creating a duplicate to avoid it.
  4. Select Accept Submission. The application reloads and locks the submission and revalidates current club, Gymkhana, Class, Events, membership eligibility, Rider/linkage, tombstone, and duplicate-registration state. A closed public intake window alone does not block staff processing of a legitimately received pending submission.
  5. Confirm the resulting ordinary Registration entry appears once with only the exact submitted Events, correct Primary/Additional Horse runs, and normal run-order/Scribe/Public Live behavior.

To reject intake, optionally add a concise private note and select Decline Submission, then confirm. Decline is durable, creates no operational rows, and cannot be reopened from this workflow. Accepted submissions cannot be casually changed to Declined. If another reviewer finishes first or underlying evidence changes, the stale page is rejected and must be reloaded.

Role required: club administrator or registration volunteer.

Gymkhana Registration is event-specific.

Select Gymkhana and Entries use compact tables, a Registered Riders summary, and Filters for Rider Search, Class, Financial Status, and Checked In. Add Competitor and Edit Competitor show the full Registration state in visible task sections rather than tabs or accordions. On Edit, each Primary and Additional Horse Event row keeps Entered, Scratch, and Scratch Reason together; on a phone these controls stack within their Event row.

Selecting a Gymkhana

  1. Open Registration.
  2. Select Open Registration.
  3. On Select Gymkhana, choose Open for the correct gymkhana.
  4. Confirm the Entries page shows the correct gymkhana name and date.

The Select Gymkhana list shows active gymkhanas. The application displays the gymkhana Status, but current registration pages do not provide a separate closed-registration dashboard.

Adding a Competitor

  1. On Entries, select Add Competitor.
  2. Under Competitor Identity, enter authoritative First Name and Last Name. These exact names drive both searches. Optionally enter Preferred Name for a new Rider's event-day/public display; it is not matching evidence.
  3. Under Membership Match, select a matching Active or Pending membership when appropriate, or leave No membership selected. Selection populates First Name, Last Name, Phone, Email, Parent/Guardian Name, Emergency Contact Name, and Emergency Contact Phone from that member, matching the established Registration workflow. It does not populate Birthdate or select a Rider. Changing First Name or Last Name afterward clears both decisions so stale hidden IDs cannot be reused.
  4. Rider matching appears only when both names are available. With no exact same-club Rider, a concise note explains that Save Competitor will create one; no second create action is required. One candidate appears with Use Existing Rider and Create New Rider Instead. Multiple candidates appear as a compact radio list followed by Use Selected Rider and Create New Rider Instead. Candidate context can include authoritative name, optional Preferred Name, recorded Birthdate, Phone/Email when present, prior Rider Classes, active state, and coarse membership-link status. Address, guardian/emergency details, horses, and internal IDs are not shown.
  5. Deliberately use an existing Rider only when that candidate represents the person. The candidate controls collapse into Existing Rider selected, and the stored First Name, Last Name, Preferred Name, Birthdate, Phone, Email, Parent/Guardian Name, Emergency Contact Name, and Emergency Contact Phone appear in the form. This selection does not change the stored Rider. If the Rider is currently unlinked and a membership is selected, the summary explains that the membership will be associated on Save. Use Change Rider to restore the choices without losing Class, Event, horse, payment/check-in, or notes work. If the Rider is linked to a different membership or inactive, use Manage Riders to resolve or reactivate the profile before selecting it.
  6. Choose Create New Rider Instead when none of the displayed candidates is correct. If no strong duplicate evidence exists, the controls collapse into New Rider will be created; use Change Rider Decision to reconsider. This decision does not create a Rider until Save Competitor.
  7. If an existing same-name Rider also has the same nonblank Birthdate, normalized Phone, case-insensitive Email, or selected Membership, Gymkhana Tools shows Possible duplicate Rider. Choose Use Existing Rider when it is the same person. Choose Create Separate Rider Anyway only after confirming it is legitimately a different person, such as relatives sharing household contact information. Different Preferred Name, Rider Class, horse, or class history does not make the identity distinct. Changing name, Birthdate, Phone, Email, or membership after the acknowledgement requires a fresh duplicate decision.
  8. Select Rider Class.
  9. Enter Birthdate if known and entering a new Rider.
  10. Enter Horse Name for the primary horse.
  11. Enter Phone, Email, Parent / Guardian Name, and Emergency Contact fields as needed for a new Rider. Reusing an existing Rider preserves its stored profile instead of overwriting it from this form.
  12. Under Events Entered, select at least one event.
  13. Check Checked In if the rider is physically checked in for the event day.
  14. Add Notes if needed.
  15. Select Save Competitor to save and return to Entries, or select Save & Record Payment to save the same registration and open Record Payment for that new entry immediately.

A competitor cannot be saved without at least one entered event. If no events have been configured, the page warns that no events are configured and disables both save actions.

When candidates exist, the Rider choice is always explicit, including when only one appears. Class, Event, horse, payment/check-in, and notes edits retain the resolved decision. Changing First Name, Last Name, or Membership Match clears it and unchanged Rider-populated profile values so stale identity state is not reused. A changed Birthdate, Phone, or Email invalidates a prior create-separate acknowledgement. With zero candidates, Save Competitor is the deliberate new-Rider confirmation and repeats the same-club name check before creation. On Save Competitor, Gymkhana Tools revalidates the selected Rider and Membership and reruns likely-duplicate detection inside the transaction. A stale override, inactive/cross-club/name-mismatched Rider, or conflicting membership is rejected without changing a Rider or entry. An existing Rider keeps authoritative profile and membership data. An explicitly associated membership changes only the previously empty membership link and creates Administrator Audit Log history. Duplicate warnings never merge records or permanently prohibit a legitimate separate Rider; confirmed historical duplicates use the separate Administrator reconciliation workflow.

The same Rider may be selected again in a different Rider Class for the same gymkhana, and both entries share the Rider profile, membership, and Preferred Name. Each class entry keeps independent selected Events, Primary Horse, Additional Horse runs, scratches, and run order. A same-Rider/same-class duplicate is rejected; edit that class entry instead. Repeated submission of the same Add Competitor form does not create another Rider, entry, run-order row, or initial fee assessment. A repeated Save & Record Payment submission reopens Record Payment for the already-saved entry when it can be identified safely.

Save & Record Payment does not make registration and payment one transaction. The registration and its initial fee assessment are committed first, then Gymkhana Tools opens the existing Record Payment page for that exact entry. Canceling or closing Record Payment, or encountering a payment validation error, leaves the registration saved with its current Unpaid or Partial status. It remains available from Entries for payment later.

Editing a Competitor

  1. On Entries, find the rider.
  2. Select Edit.
  3. Update rider details, including Preferred Name when needed, Primary Horse Name, event selections, scratches, Additional Horse Runs, Checked In, or Notes. Clearing Preferred Name here deliberately restores First Name-based display.
  4. Select Save Competitor.

Primary Horse Events are the rider's normal entered events and count toward points unless scratched. Additional Horse Runs are separate runs for an extra horse and do not count toward class results or points.

To add additional horse runs, enter Additional Horse Name, then select the additional-horse events. Leave Additional Horse Name blank if there is no additional horse.

Scratches

On Edit Competitor, use Scratch from this event for a primary-horse event, Scratch extra horse for an additional-horse run, or Scratch All Events when the rider is scratching from all entered events. Scratch Reason is optional.

An unselected event is not a scratch. It simply was not entered.

The Entries list shows:

  • Registered when no entered primary-horse events are scratched.
  • Partially Scratched when some entered primary-horse events are scratched.
  • Fully Scratched when all entered primary-horse events are scratched.

Payment Status and Checked In

Payment status is derived from the registration fee assessment, adjustments, payments, and refunds; it is not a manually maintained checkbox on the competitor form. Checked In means the rider has been checked in for event-day participation and remains available on Add Competitor and Edit Competitor. There is no separate Check-In dashboard.

To collect money at the Registration desk:

  1. After Add Competitor, either select Save & Record Payment to open this workflow for the newly saved entry, or open the correct Gymkhana's Entries page and find an existing rider.
  2. Review Due, Collected, Balance, and financial status under Fees.
  3. For an assessed Unpaid or Partial registration with a positive balance, select Record Payment beside Edit.
  4. Confirm the Rider, Gymkhana, Amount Due, Collected, Remaining Balance, and current Financial Status.
  5. Enter or confirm Payment Amount. The positive remaining balance is supplied by default; a legitimate excess payment is allowed and produces Overpaid status.
  6. Choose Payment Method: Cash, Check, Card, or Other.
  7. Select Record Payment, then verify the updated status, Collected amount, and Balance on Entries.

Paid, No Charge, Overpaid, and Legacy / Unassessed registrations do not offer Record Payment. If an old Record Payment link is revisited after the balance reaches zero or below, Gymkhana Tools explains that no additional payment was recorded and provides Back to Entries for the same Gymkhana. Gymkhana Tools does not invent an assessment for a legacy entry. Each successful submission appends one immutable Staff-source payment; refreshing or repeating the same form submission does not create a second payment. Use the Entries page's Reconciliation action to inspect that Gymkhana's totals, method/source summaries, and immutable transaction history, including human-readable transaction/category labels, amount, method, source, reason when recorded, staff actor, and club-local timestamp with time-zone abbreviation. Refund, Adjustment, and Correct Pricing Basis controls have visible field labels and stack at narrow widths; a successful action returns to Reconciliation with a visible confirmation. An Administrator may use Correct pricing basis with a required reason. The correction appends a revision, preserves existing collections, and recalculates Due, Balance, and status from the corrected basis. Transaction history identifies the correction and shows the prior and new basis and assessed amount, reason, staff actor, and timestamp. Retrying the same submitted correction does not append another revision or audit event and reports that no duplicate was created; a stale form is rejected so the Administrator can review the current assessment first. Opening Reconciliation from the Registration navigation without an event context selects the current club's most recent Gymkhana. Use the Gymkhana name/date selector to switch events; Status, Pricing basis, Method, and Source remain available and retain the selected Gymkhana when applied.

Run-Order Effects

Saving registration creates or updates the run-order rows used by registration, scribe, and public live pages. Scratches appear in the scribe/live status as Scratch and are skipped by the pending queue.

Use Adjust Run Order in the Entries page header only when the event director or registration lead decides a manual order change is needed. It opens the run-order tools in a right-side panel without replacing the Entries list.

Check-In

Role required: club administrator or registration volunteer.

Check-in occurs inside Add Competitor and Edit Competitor.

  1. Open the correct gymkhana through Gymkhana Registration.
  2. Add or edit the competitor.
  3. Set Checked In based on physical event-day check-in.
  4. Select Save Competitor.

Payment reconciliation and physical check-in are separate workflows. A rider's balance comes from the immutable fee assessment, adjustments, payments, and refunds, while Checked In records event-day presence. Confirm both the financial status and check-in status before the first event.

Run Order and Event Groups

Role required for manual run-order changes: club administrator or registration volunteer. Role required for event-group configuration: club administrator.

Adjust Run Order appears with the page actions at the top of Entries, so it remains reachable without scrolling through the roster. It opens a right-side panel and preserves the Entries Rider Search, Class, Financial Status, Checked In filters, and practical scroll position. Closing the panel with its Close button, Esc, or the backdrop makes no change and returns focus to the page action.

  1. Select Adjust Run Order.
  2. Select Event or Event Group. Each configured group appears once by group name.
  3. Select Class.
  4. Select Run Type: Primary Horse or Extra Horse.
  5. Select Load.
  6. Choose This Event (the safe default), This and Remaining Events, or All Uncompleted Events in Class.
  7. Use Up or Down to move a row one position. For an Event Group, the action moves all of that rider's applicable constituent runs together for the selected class and run type.

This Event changes only the selected Event/Class. This and Remaining Events also applies the intended relative order to later uncompleted Events in the configured gymkhana Event sequence. All Uncompleted Events in Class applies it to every uncompleted Event in the Class, including earlier Events. Both multi-event scopes exclude completed Events; a completed selected Event or constituent Event Group context must use the deliberate This Event correction path. There is no unrestricted All Events choice, and Re-Ride status never selects scope automatically.

If a targeted Event has a different relevant order, review Different run orders found and the named Events. Cancel performs no mutation. Confirm and Replace Orders applies the reviewed replacement atomically; if order or completion state changed after review, Gymkhana Tools rejects the stale confirmation. Missing source participants are not invented or merged into another Event.

Manual moves preserve the selected Event, Class, and Run Type filters after the move. Registration and Scribe share the same scope calculation, warning, confirmation, completed-Event protection, and authoritative mutation.

Event Groups are configured from Configure Gymkhana Events. They let grouped events display and queue as rider-through-group blocks in Scribe and Public Live. The group name is the section heading; each run row retains its individual event name and result action. One queue card represents the rider's applicable group/class/run-type block and stays active until every constituent run for that rider is resolved for the current pass. Grouped events remain separate events for result entry, placings, records, and points. A selected gymkhana event can belong to only one event group.

Registration edits, scratches, and additional horse changes feed the same run-order data used by scribe and public live views. If scribe does not show a recent registration change, refresh the scribe page or confirm the correct gymkhana and filters are selected.

Announcer/Scribe Workflow

Role required: club administrator or announcer/scribe.

Opening the Scribe Page

  1. Open Announcer / Scribe.
  2. Choose Open for the correct gymkhana.
  3. Confirm the gymkhana name, season, date, and location.
  4. Use Filters to choose Event, Event Group, Class, and Run Type. Each configured group appears once in the Event selector and loads all of its constituent runs. Each dropdown applies immediately when selected, including All Events, All Classes, and All; changing one preserves the other current Filters values.
  5. Enter Rider Search only when needed. It does not request while you type; select Go to apply Rider Search. Go remains available as a manual or fallback submission for all Filters.

Run Type defaults to All when the page is opened without an explicit Run Type selection. Run Type choices are Primary, Extra Horse, and All. Primary shows primary runs only, Extra Horse shows additional-horse runs only, and All shows both. Queue cards remain global and are not narrowed by these display filters.

When a deliberate Filters request is running, Loading runs... appears while the existing Runs content remains visible. Routine automatic polling does not show this status. Automatic filtering never replaces an active result editor. While an editor is open, Event, Class, and Run Type are visibly unavailable and continue showing the values applied to Runs; the message below Filters tells you to save or close the result editor before changing them. Close or a successful result action makes all three available immediately, and the next selection applies normally. Rider Search and Go remain manual. Partially entered result values remain in the open editor until you save or close it.

Viewing Event Rules

Event Rules is in the actions at the top of the compact Filters toolbar and opens a read-only panel from the right. If the main Event filter contains a specific standalone Event, select Event Rules to open that Event Type's Description, Pattern Rules, and Penalty Rules directly. If the filter contains an Event Group, the panel asks you to choose one of that group's constituent Event Types. Description is displayed as escaped plain text with line breaks; Pattern Rules and Penalty Rules are safely formatted from Markdown. Empty sections are omitted.

If the main Event filter is All Events, open Event Rules and use Choose Event inside the panel. The selector contains only Event Types configured for the current gymkhana. It is independent of the Scribe filters: choosing rules does not change Event, Class, Run Type, Rider Search, or the run list.

Close Event Rules with its Close button or normal Bootstrap offcanvas keyboard behavior. Focus returns to the Event Rules trigger. The panel is isolated from result entry, so opening, switching, or closing rules does not save, clear, close, or replace an active Scribe Result Entry editor and does not stop the existing polling safeguard.

Viewing Results in Context

Select Results in the Filters toolbar actions to open the authoritative compact current-placings panel without leaving Scribe or scrolling away from active entry. Its independent Event and Class selectors apply the established class-placing rules: Primary runs participate, Additional Horse runs do not, and Rider Search and the working Run Type filter do not narrow the competitive result set. Current placings are not duplicated at the bottom of the main run list.

When both main Event and Class are specific, Results opens to those values. If either main filter is All, or the main Event is an Event Group, it prefers the current Up rider's constituent Event/Class. With no current Up rider it uses a scheduled Primary Event/Class when available; an empty gymkhana shows a neutral message. Changing either panel selector does not change the main Scribe filters. Queue advancement also leaves the inspected panel selection alone. Select Show Current only when you want to deliberately move the panel to the active Up rider's Event/Class.

The placing list shows Place, Rider, Horse, and Time/status using the established Preferred Name, placing order, and Completed, DQ, No Time, Scratch, Pending, and Re-Ride interpretation. While the panel is open, changed results refresh inside its scrollable list; unchanged checks return no replacement. Opening, using, refreshing, or closing Results does not target the run list, queue cards, other toolbar actions, or an active result editor, so partially entered values remain in place.

Managing Run Order from Scribe

Role required in Scribe: club Administrator or Announcer/Scribe. Registration users retain run-order adjustment authority through Registration, but do not gain Scribe access. Announcer/Scribe users receive only the narrow run-order adjustment authority and do not gain unrelated Registration capabilities.

Select Adjust Run Order in the Filters toolbar actions to open the right-side panel without leaving the active gymkhana. The toolbar actions are outside the automatically refreshed run-list area, so polling does not replace or refocus their controls after a panel closes. If the main Scribe Event and Class filters are both specific, the panel starts with that Event/Class. When either main filter is broad, it prefers the current Up rider's Event/Class; if no rider is currently Up, it uses the first valid scheduled Event/Class. The panel has its own Event, Class, and Run Type selectors. Changing them does not change Event, Class, Run Type, Rider Search, the open result editor, or partially entered result values on the main Scribe page.

Use Up or Down only after officials approve a position change. A standalone Event moves its authoritative run-order row. An Event Group moves all of the selected rider's applicable constituent rows together as one block for the chosen class and run type. Registration, Scribe queues, and Public Live read the same committed order. Primary and Additional Horse blocks remain distinct. Moving Re-Ride Pending or Re-Ride Ready preserves that exact state: movement never performs Return to Queue, never changes readiness, and never creates another run or result. After a committed move, Scribe refreshes from authoritative queue state; if an unsaved result editor is open, its polling guard preserves the editor and the normal refresh resumes after it closes.

Before selecting Up or Down, choose exactly one scope:

  • This Event is the safe default and changes only the selected Event/Class. For an Event Group it preserves the existing whole-group block behavior.
  • This and Remaining Events changes the selected Event and every later uncompleted Event in this Class, using the configured gymkhana Event sequence. Earlier Events and all completed Events remain unchanged.
  • All Uncompleted Events in Class changes every uncompleted Event in this Class within the current gymkhana, before and after the selected Event. Completed Events remain unchanged.

There is no unrestricted All Events choice. Re-Ride never chooses a scope automatically. If the selected Event, or a constituent of the selected Event Group, is already completed, Gymkhana Tools rejects the two multi-event scopes and directs you to This Event for an approved deliberate correction.

When a targeted uncompleted Event already has a different relevant order, Different run orders found identifies the differing Events and explains that the selected orders will be replaced. Select Cancel to make no change, or Confirm and Replace Orders after verifying the intended scope. Gymkhana Tools rechecks the configured Events, completion states, and current orders during confirmation. If anything changed after review, no order is changed; review the current state and try again. The operation does not merge orders or create missing runs: a rider not entered in the source Event retains their position in another Event.

Understanding the Queue

The page shows a current context banner, queue cards using the club's Run Position Terminology, the Runs table, Additional Horse Runs, a compact event-progress summary with Registered Riders, Runs, and Estimated Finish, Fastest Times - All Classes, and the toolbar Results reference for current placings.

Registered Riders is the number of distinct riders registered for the selected gymkhana. Scratch status does not remove a rider from that registration count. Runs is displayed as Completed / Expected for the entire gymkhana. Expected includes primary and additional-horse runs that have occurred or still need to occur. Completed includes normal completed results, DQ, and No Time because those arena runs no longer need to be performed.

A pending Scratch is removed from Expected and does not increase Completed. Re-Ride Pending and Re-Ride Ready remain in Expected but do not increase Completed until a final time, DQ, or No Time is recorded. Restoring the run adds it back to Expected and reveals the exact preserved Re-Ride or finalized state. Correcting an existing result does not add another completed run. Reset to Pending removes the current finalized outcome from Completed and returns the run to unresolved Expected work. Event, Class, Run Type, and Rider Search filters affect the displayed run list, not the whole-gymkhana progress summary or Re-Rides reminder.

Estimated Finish answers approximately when the whole gymkhana may finish, but it is operational guidance rather than a promised closing time. Runs Completed / Expected reflects authoritative current result state. For today's Open gymkhana, pace uses only Completed, DQ, and No Time finalizations recorded on the selected gymkhana's event date in the Club Time Zone. It may therefore display Calculating… even when Completed is nonzero—for example, when preserved results were recorded on an earlier date—until six trustworthy same-day finalizations provide enough observed pace. It then uses recent eligible cadence and the current unresolved run count. Configured Start Time is a schedule, not a pace observation or a required lower bound: too few same-day finalizations remain Calculating… before or after that time, while sufficient actual early activity may support a finish before it. Other gymkhanas, historical/test data, and display filters do not influence the estimate. The ~ means the time is approximate, and a legitimate next-day estimate includes tomorrow. Long breaks move the earliest possible finish forward without permanently becoming normal run pace, so the estimate can recover after ordinary result entry resumes.

When an Open gymkhana has no remaining executable work, the field displays Completed. A past or future gymkhana still marked Open displays Open rather than a future or reconstructed estimate. Draft, Closed, Completed, and Cancelled gymkhanas display their actual status; for example, a Closed historical event remains Closed even when all runs have results. A missing or invalid Club Time Zone keeps today's estimate at Calculating…. Event, Class, Run Type, and Rider Search filters do not change it. The summary refreshes automatically without replacing an active result-entry editor.

Queue cards use the full authoritative run order rather than visible filters. Ordinary Pending rows feed the queue in schedule order. Re-Ride Pending is skipped; Re-Ride Ready enters the same queue engine at its current position while remaining clearly identified in the Re-Rides reminder. Registration staff or an Administrator or Announcer/Scribe user selecting Adjust Run Order may move either state without changing it. If later Completed, DQ, or No Time results establish that competition progressed past an old Ready position, it remains visible in the reminder but does not pull Up backward. Moving it to a future position lets it enter naturally as that position approaches.

Queue cards, run rows, result entry/correction context, Re-Rides, the Results reference, and Fastest Times use a rider's Preferred Name plus Last Name when present. A rider without Preferred Name appears exactly as First Name plus Last Name. Registration screens retain First Last (Preferred) so staff can see authoritative identity.

For an Event Group, the queue card shows the rider once with the group name and Not Started or compact completion progress. Enter each constituent result from its labeled event row in the grouped Runs section. Constituent events may be completed in any order. Ordinary Pending—including a constituent Reset or Restored to Pending while that grouped block is active—keeps the rider Up after another constituent is finalized. Completed, DQ, No Time, Scratch, and Re-Ride Pending resolve that event for the current group pass; Re-Ride Pending is deferred and Re-Ride Ready remains work to perform. The queue advances to the next rider only when no applicable constituent event remains executable. A rider entered in only one event in the group behaves like an ordinary single run, and an event the rider did not enter is not treated as a Scratch.

Reset to Pending uses that same reopened-Pending rule. A reset constituent inside the current grouped unit remains executable until that group is resolved; a partially completed later group does not split the current unit or advance past it. For separate units, a reset current/future run may become Up when it is the earliest executable work, but resetting an earlier result after a later complete unit has established progression does not drag Up backward. Reset does not create or reposition a run-order row.

Entering a Time

  1. In Runs, select Enter Result for the intended pending row.
  2. In the inline Scribe Result Entry editor beneath the selected row, confirm the rider, horse, event, class, and Primary or Extra Horse label.
  3. Enter the Time.
  4. Select Save Time.

Marking and Resolving a Re-Ride

Use Re-Ride when an attempt occurred but officials require another attempt. Do not use it when a result was entered before the rider ran; that is Reset to Pending.

  1. On the current Pending row, select Enter Result.
  2. In Re-Ride, check Mark this run Re-Ride? [rider] will leave the active queue and remain listed as Re-Ride Pending until resolved. Gymkhana Tools will not automatically reposition the rider. after officials approve the repeat attempt. The page shows the selected rider's name in place of [rider].
  3. Select Re-Ride and wait for Run marked Re-Ride.
  4. Verify the row leaves the active queue and appears in the filter-independent Re-Ride Pending reminder.
  5. After officials choose placement, select Adjust Run Order or coordinate with Registration to move the existing row. Marking Re-Ride does not move it, and moving it does not change readiness.
  6. In the Re-Rides reminder, select Return to Queue and accept Return this Re-Ride to the queue? The rider will become Re-Ride Ready at the current run-order position. Run order will not be changed. The row becomes Re-Ride Ready without moving.
  7. Verify the rider enters normal queue progression at the selected authoritative position.
  8. When the repeat attempt occurs, select Resolve Re-Ride. Use Save Re-Ride Time for a valid time, or select DQ, No Time, or Scratch.

The run remains Expected and not Completed through both Re-Ride states. Save Re-Ride Time changes Re-Ride Ready to Completed; DQ and No Time replace it with those final statuses. Scratch becomes the visible status while preserving the underlying Re-Ride state so Restore can reveal it again. Multiple Pending and Ready Re-Rides may coexist independently. Reopening a row after another operator changed it produces the normal stale-state warning rather than overwriting the newer state. Normal final entry is available from Re-Ride Ready; Re-Ride Pending must first use Return to Queue.

In System → Audit, the initial Re-Ride button is recorded as Re-Ride Required, and Return to Queue is recorded as Re-Ride Returned to Queue. These are Audit Log action names, not alternate Scribe control labels.

Do not re-submit just because a page refresh appears delayed. The form disables buttons while saving, the open editor is protected from automatic run-list polling, and the run list refreshes after the save completes.

DQ, No Time, and Scratch

Use DQ to save a DQ result. Use No Time to save a No Time result.

To Scratch a pending run from scribe:

  1. Open Enter Result for the row.
  2. Check I understand this will scratch [rider] from [event].
  3. Select Scratch.

Scratch requires the confirmation checkbox for new scratch submissions.

Editing a Completed Result

Completed, DQ, and No Time rows show Update.

  1. Select Update.
  2. Review Correct Existing Result and Current result.
  3. Enter the replacement time, or select DQ, No Time, or Scratch as appropriate.
  4. Check I understand this will overwrite the current result for [rider].
  5. Select Save Correction or the intended status button.

Use this correction workflow when the rider actually completed the run and only the recorded time/status is wrong.

Resetting a Mistaken Result to Pending

Completed, DQ, and No Time rows expose Reset to Pending inside the Update panel. Use it only when the current outcome was entered before the rider completed that run.

  1. Select Update for the finalized row.
  2. Review the current result and the separate Reset to Pending explanation.
  3. Check Reset this run to Pending? The current result will be cleared and [rider] will return to pending status.
  4. Select Reset to Pending.
  5. Wait for Result reset to Pending., then verify the run status and queue cards.

Reset clears the current raw/final time, penalty, notes, and finalized status. The run becomes persisted Pending, current Results/Public Live/records/standings/progress no longer use the removed outcome, and Administrator Audit Log preserves it. Reset is not available for Pending, either Re-Ride state, or visible Scratch. Restore a Scratch first; if the revealed prior Completed/DQ/No Time result was itself mistaken, then use Reset. Re-Ride is the separate workflow for an attempt that occurred and another attempt is owed.

Restoring a Scratch

Scratch rows show Restore.

  1. Select Restore.
  2. If the panel says Restore Scratched Run, check the confirmation to restore the run to Pending.
  3. If the panel says Restore Previous Result, check the confirmation to remove the Scratch and restore the existing result.
  4. Select Restore Run or Restore Previous Result.

A scratched run must be restored before a new time, DQ, No Time, or Scratch can be entered.

After Restore, confirm the queue cards. An immediate Restore may put that rider back in the active queue. If the event already continued through later finalized riders, the restored earlier row stays available for an approved result or run-order decision without displacing the current operational Up rider.

Close

Close closes the current inline result-entry editor and discards unsaved input only. It does not change stored times, statuses, placings, fastest times, standings, records, or live results.

Stale or Changed Entries

If another user or a registration edit changes the same run while your form is open, Gymkhana Tools may reject the save and ask you to reload the current result and try again. Reopen the row, verify the latest status, and coordinate with registration or the event director before correcting consequential results.

Public Live Scoreboard

Role required to configure/share: club administrator. Public viewers do not sign in.

Club Profile contains Public Live Scoreboard controls: Public Live Token, Public Live URL, QR Code Instructions, Generate Token or Regenerate Token, and Generate QR Code.

  1. In Club Profile, generate a token if Public Live Token is blank.
  2. Save QR Code Instructions with Save Club Profile if they changed.
  3. Use Public Live URL for sharing, or select Generate QR Code for a printable QR page.
  4. Verify the public page opens before posting or printing the link.

The public page is read-only. It uses the Club Time Zone to select today's active gymkhana by default. If there is no event today, it selects the most recent active past event; it never chooses a future event merely because the future event was created later, has a higher number/ID, or is Open. If the Club Time Zone is not configured or the club has only future events, the page shows a neutral message.

Use the compact Gymkhana selector and View to open another available today or past gymkhana. The selected gymkhana ID is kept in the URL, so browser refresh, back/forward, bookmarks, shared links, and automatic polling retain that event. Choosing another gymkhana resets Event, Class, Rider Search, and Run Type to their safe defaults; Run Type therefore returns to All. Historical View means only that the selected Gymkhana date is before the current date in the Club Time Zone. The separate status badge remains the club-managed operational status—Draft, Open, Closed, Completed, or Cancelled—so a historical Open Gymkhana is still shown as Open rather than being implied to be Completed. Current-day views show Live · Auto-updating; historical views continue automatic run/result polling without the Live wording. An archived or completed Season may contain valid historical events. Inactive and future gymkhanas do not appear.

The selected gymkhana drives the Filters, the same Registered Riders, Runs Completed / Expected, and Estimated Finish summary as Scribe, queue cards, Run Order, Additional Horse Runs, and Current Results. The Season Standings link remains the club-scoped standings entry point. Run Type defaults to All when the page is opened without an explicit selection, so Primary and Extra Horse runs are both initially visible; an explicit Run Type remains selected through automatic refreshes. Event Groups use the same group heading, labeled constituent rows, one-rider queue card, and block progress as Scribe. The progress summary and finish/status state cover the whole selected gymkhana and do not change with the display filters. For today's Open gymkhana, Estimated Finish remains Calculating… until six finalizations from that club-local event date establish reliable observed pace, then updates from the same selected-gymkhana state as Scribe. Older finalized rows remain visible in Runs and in authoritative progress but do not become today's pace evidence. It displays Completed when no executable work remains. Past selections show their configured status—including Open when an event was never closed—instead of a future estimate. Draft, Closed, Completed, and Cancelled gymkhanas likewise display their actual status. A completed historical event may naturally have empty queue cards; Live Updates shows current authoritative stored state and does not reconstruct a past queue snapshot. It refreshes automatically with the public run-order polling. Do not expose administrative screens, volunteer login credentials, member contact details, or public token values in screenshots or support notes.

Public queue, run, Current Results, Season Standings, and record-style event presentation use Preferred Last when a rider has Preferred Name and otherwise use First Last. Historical pages use the rider's current profile name presentation, as they already do for current First/Last profile values; Gymkhana Tools does not create a separate Preferred Name snapshot.

Regenerate Token invalidates the previous public scoreboard URL and QR code.

Season Standings

Public access: anyone with the club public live URL/token. Authenticated announcer/scribe users can open Season Standings from the navigation when the club has a public live token.

Season Standings shows [Club Name] Season Standings, a season selector, and compact groups by rider class. Each group includes Rank, Rider, and Points. The eligibility note explains why a separate Member column is unnecessary: every displayed standing is already an active linked club member.

Standings are calculated dynamically from completed primary-horse results for gymkhanas in the selected season. They include active linked club members only. Non-members may place in event results, but they do not appear in season standings and do not consume season point positions. Additional horse runs, DQ, Scratch, No Time, Pending, and other non-completed runs earn 0 points.

Standings aggregate by authoritative First Name, Last Name, and class rather than separating a rider's total by horse. Preferred Name affects display only and never merges or splits a standing.

Records

Role required: any signed-in user who can open Records; administrators and announcer/scribe users have navigation or dashboard access.

The Records page is titled Current Records. It shows Fastest completed primary runs by event.

Use the season selector to change Selected Season Records. The page also shows All-Time Records across seasons. Correcting a completed result can change records because records are calculated from current completed results rather than a separate stored record table. DQ, No Time, Scratch, Pending, and additional horse runs do not become records.

Records display Preferred Last when available, with First Last as the fallback. No current rider-name CSV/print/export path exists; the Grafana reporting views intentionally omit rider names.

Correcting Results and Registration Mistakes

Role required: depends on the correction. Registration corrections require administrator or registration. Result corrections require administrator or announcer/scribe.

Registration Corrections

Use Edit Competitor to correct rider details, Primary Horse Name, selected events, Additional Horse Runs, Paid, Checked In, Notes, or scratches. Save the competitor, then confirm scribe and public live show the expected status.

Stop and verify with the event director before changing entries after runs have started, especially if results already exist.

Result Corrections

Use Update for completed, DQ, and No Time results when the run occurred and the value/status is wrong. Use Re-Ride when an attempt occurred and another attempt is owed, Return to Queue when the chosen position should become executable, Resolve Re-Ride for its final outcome, and Restore for Scratch rows. Use Reset to Pending when the finalized result itself was entered before the rider completed the run. Confirm overwrite, reset, Re-Ride, or restore checkboxes when shown, and accept the Return to Queue confirmation prompt. The Administrator Audit Log names the initial Re-Ride transition Re-Ride Required.

Corrected results update the Scribe Results panel, public live results, records, and season standings after the save and refresh. Reset results return to unresolved Pending and remove the prior value from those current-state views while preserving Administrator audit history. If a stale-change warning appears, reopen the row and coordinate before retrying.

Closing or Finishing a Gymkhana

Role required: club administrator for gymkhana status changes; registration and scribe roles assist with verification.

Gymkhana Tools has Status values on the Gymkhana form: Draft, Open, Closed, Completed, and Cancelled. The current application does not provide a separate formal event closeout dashboard.

Practical post-event steps:

  1. In Registration, confirm all competitors have correct Paid, Checked In, and scratch state.
  2. In Scribe, use Results to review every Primary event/class; review Additional Horse Runs separately because they do not participate in class placings.
  3. Correct DQ, No Time, Scratch, or timing mistakes before declaring results final.
  4. Check Public Live Scoreboard and Season Standings.
  5. Check Current Records.
  6. If the club uses gymkhana Status operationally, have an administrator update the gymkhana to Closed or Completed.
  7. Avoid regenerating the public live token after the event unless old public links must be invalidated.

Troubleshooting

Login Fails

Recheck email/login and password. If the account should work, ask a club administrator to verify that the user and club are active. If the club itself is inactive, contact a platform administrator.

Expected Menu Is Missing

Confirm the account role and club name. On a phone or narrow screen, open the collapsed navigation menu. Ask a club administrator to verify your role.

Wrong Club Name Is Shown

Stop before entering data. Sign out and sign in with the correct account. If the wrong name remains, contact an administrator.

Rider Cannot Be Found

Check spelling in registration member lookup and Manage Riders. For member lookup, both First Name and Last Name searches may matter. If the rider needs off-event cleanup, use Manage Riders.

Duplicate Competitor Warning

Do not add another entry. Return to Entries, search for the rider, and use Edit.

Registration Change Is Not Visible to Scribe

Confirm both users selected the same gymkhana and filters. Refresh the scribe page. Check whether the row is under Primary or Extra Horse and whether it is scratched.

Result Entry Appears Stale

Do not keep pressing Save. Reopen the run row, review the current status, and coordinate with the event director if a correction is needed.

Live Page Does Not Update

Refresh the public page. Confirm the URL uses the current public live link. If a token was regenerated, old QR codes and old links no longer work.

Wrong Season or Gymkhana Selected

For Registration or Scribe, return to the dashboard or selector and choose the correct season or gymkhana. Confirm the club name beneath the logo before saving changes. For Public Live, use the Gymkhana selector and confirm the heading/date; if today's event is not the default, verify the Club Time Zone and that the gymkhana is Active rather than archived/inactive.

Mobile Menu Is Collapsed

Use the navigation toggle in the header to show the menu.

Browser Shows Stale Styling After Deployment

Refresh the page. If it still looks wrong, use the browser's hard refresh option and sign out/in if needed.

Application Error Page Appears

  • 403 Forbidden means the application denied the requested page or action. Return to an area available to your role or ask an administrator to verify your access. A missing or expired login follows the normal sign-in flow instead.
  • 404 Not Found means the requested page does not exist. Check the link or URL; visiting this page does not sign you out.
  • 500 Internal Server Error means Gymkhana Tools could not complete the request. Use Try Again for a safe page request, and contact an administrator if the problem continues.
  • 503 Service Unavailable means the application is temporarily unavailable. Wait briefly and use Try Again.

Error pages do not show technical details. When reporting a continuing 500 or 503, include the time, page, and visible request ID header if an administrator asks for it; do not send passwords, tokens, or session cookies.

Event-Day Checklist

Before Registration Opens

  1. Confirm the correct club name appears after sign-in.
  2. Confirm Club Profile points, queue labels, public live token, and QR instructions.
  3. Confirm rider classes, event types, season, gymkhana, selected events, and event groups.
  4. Confirm volunteer accounts and roles.
  5. Confirm member records needed for lookup and standings.
  6. Verify public live URL or QR page if sharing with spectators.

Before the First Event

  1. Confirm all competitors are entered in the correct gymkhana.
  2. Confirm registration balances/payment reconciliation and Checked In values.
  3. Confirm scratches.
  4. Confirm Run Order Adjustment for key events/classes if needed.
  5. Confirm scribe filters and queue labels.
  6. Confirm public live scoreboard shows the correct event day.

During Registration

  1. Use Add Competitor for new event-day entries.
  2. Use Edit for corrections and scratches.
  3. Watch for duplicates.
  4. Tell the scribe when consequential changes are made after the queue is active.

During Scribing

  1. Verify rider, horse, event, class, and run type before saving.
  2. Wait for save feedback.
  3. Use Update, Reset to Pending, or Restore rather than entering a false workaround or second result.
  4. Coordinate on disputed DQ, No Time, Scratch, or timing corrections.

Between Events

  1. Check filters and event/class context.
  2. Open Results and review the current placings.
  3. Confirm the next queue matches the arena plan.
  4. Refresh public live if spectators report stale results.

After the Final Event

  1. Review results by event/class.
  2. Verify standings and records.
  3. Make approved corrections.
  4. Update gymkhana Status if the club uses Closed or Completed for finished events.
  5. Keep public links private if they include token values in admin-facing materials.

Terminology

Club: the riding club whose name appears beneath the logo for ordinary users.

Season: a named date range used to group gymkhanas for standings and records.

Gymkhana: one event day with its own date, location, status, registration, selected events, run order, and results.

Rider Class: the participation division assigned to one gymkhana entry for run order, results, records, and standings grouping; it does not define Rider identity.

Event Type: a reusable club event definition selected into a gymkhana.

Event Group: per-gymkhana grouping that forms one rider queue/run-order block while keeping constituent results and points separate.

Primary Horse: the rider's normal horse for entered events; primary runs can count toward results and points.

Additional Horse: an extra horse run entered separately on Edit Competitor; these runs do not count toward class results or points.

Scratch: a run or entered event that should not be run.

DQ: disqualification result status.

No Time: result status for a run with no valid time.

Run Order: the ordered list of runs used by registration, scribe, and public live pages.

Registration: the event-specific competitor entry for one gymkhana.

Checked In: event-day attendance status maintained on competitor add/edit.

Season Standings: calculated season point totals for active linked club members, grouped by class.

Record: fastest completed primary run by event for the selected season or all time.

Known Limitations

  • No self-service password reset is implemented.
  • No invitation email or automatic credential delivery is implemented.
  • Ordinary users do not switch clubs inside the application.
  • Volunteers who work with multiple clubs need separate logins.
  • There is no separate Check-In dashboard.
  • There is no standalone horse-management workflow.
  • Additional horse runs do not count toward class results or season points. Equal final times receive deterministic sequential places; shared placing is not implemented. Penalty entry is not implemented in v1.5.0.
  • Public live links depend on club-specific token values; regenerating a token invalidates prior links and QR codes.
  • There is no formal closeout dashboard separate from registration, scribe, records, standings, and the Gymkhana Status field.

Registration Fees

Role required for configuration: club administrator.

Open Club → Registration Settings. The page is organized into Online Registration, Online Payments, Default Registration Fees, Additional Fixed Fees, and Financial Permissions.

  • Online Registration controls Eligibility Policy, Submission Processing, the Registration URL, and Registration Token regeneration.
  • Online Payments lets an Administrator connect the club's Square seller, select its eligible card-processing location, and enable or disable required Square-hosted payment for positive public-registration quotes.
  • Square payment confirmation comes from authenticated provider events, not the customer's browser return. Confirmed review items are visibly marked Paid via Square; accepting creates the normal Online/Card collection, while declining requires an explicit no-refund acknowledgement.
  • Default Registration Fees stores the Member fee per selected run and Nonmember fee per selected run. These are defaults for future Gymkhana schedules; saving them never reprices an existing Gymkhana or registration.
  • Additional Fixed Fees stores club-default fees that apply once per rider registration. Name, Amount, Applies To, and Active/archive state are maintained here. Only active defaults are copied to a new or deliberately reset Gymkhana.
  • Financial Permissions controls Allow Registration staff to record fee adjustments. It is Off by default. When Off, only Administrators may make adjustments; when enabled, the Registration role may also make them.

For a successful paid public registration, the return page may briefly show Payment confirmation pending while Gymkhana Tools waits for Square. It then shows either Payment confirmed — registration complete or Payment confirmed — registration pending review. Administrator and Registration staff review paid pending items through Registration → Online Submissions. Acceptance creates the Registration, fee assessment, and Square-backed Card/Online collection together; Entries and Reconciliation then show the paid balance and provider/source label. Declining requires the unchecked acknowledgement that Gymkhana Tools will not issue a refund. If a refund is required, authorized club staff must handle it separately in Square; the local decline neither calls Square nor creates a local finance refund.

When adding a Gymkhana, the Registration Fees panel previews the current club run fees and active fixed fees. Selecting Save Gymkhana pins that snapshot. Later changes to Registration Settings do not flow into the saved Gymkhana.

When editing a Gymkhana, use the same Registration Fees panel to change member/nonmember run fees, edit or archive existing Fixed Fees, or enter a new fixed fee. Change ordinary Gymkhana fields and fees together, then select Save Gymkhana once. The complete Gymkhana and fee schedule are saved together; there is no separate fee-schedule save step.

Select Reset Fees to Current Club Defaults to replace the displayed run-fee and fixed-fee values with the club's current defaults. This is an unsaved preview: inspect the values and then select Save Gymkhana to apply them. Leaving or refreshing the page before saving leaves the persisted schedule unchanged. Reset uses only the current club's active fixed-fee defaults and does not change registrations already assessed.

Existing Gymkhanas may legitimately retain a pinned $0.00/$0.00 schedule. They change only through a deliberate edit or reset followed by Save Gymkhana. Fee-schedule changes affect future assessments only. Existing assessment rates, assessment revisions, payments, refunds, and adjustments remain unchanged.

Registration staff record ordinary payments from Entries → Record Payment. Reconciliation remains the Gymkhana-level review for totals, method/source summaries, history, delegated adjustments, and Administrator-only refunds and pricing corrections. Every selected Primary or Additional Horse Event run uses the applicable per-run rate, and applicable fixed fees are charged once per rider registration. Scratches and withdrawals do not automatically reduce charges or issue refunds.

Connect Square for Online Payments

Role required: club administrator.

Open Club → Registration Settings → Online Payments. Select Connect Square, sign in to the intended Square seller, approve the requested merchant/order/payment permissions, and return to Gymkhana Tools. A successful return shows Connected and the Square business label; canceled or failed authorization leaves any existing connection unchanged. Never paste an access token or application secret into Gymkhana Tools.

Choose the intended active card-processing Square Location and select Save Online Payments. Turn on Enable Online Payments only after a location is selected. Connected means the seller authorization can be verified; Needs attention means Online Payments has been disabled and an Administrator should select Reconnect Square. Reconnecting the same seller preserves a still-eligible selected location; changing sellers requires selecting again.

Select Disconnect Square when the club should remove the authorization. Disconnect always disables Online Payments and clears the local seller tokens and location. If Square cannot confirm remote revocation, Gymkhana Tools still completes local disconnect and tells the Administrator that revocation was not confirmed.

When Online Payments is enabled and usable, a public registrant with a positive authoritative quote sees Continue to Payment. Gymkhana Tools prepares a durable attempt and redirects to Square's hosted checkout for the full amount; card details are entered only at Square. A $0.00 quote skips Square, and disabled/unconfigured Online Payments retains Submit Registration and the existing processing rules. If the enabled Square connection is unavailable, the form stops safely and does not create an unpaid registration.

Returning from Square displays Payment confirmation pending. That return does not prove payment and registration is not complete yet. Do not ask staff to create a duplicate manual registration while confirmation is pending. Provider confirmation, creation of the paid Online Submission/Registration, and online collection recording arrive with the separate confirmation workflow. Staff Record Payment remains unchanged, and Gymkhana Tools does not initiate Square refunds.