Privacy

Who this notice is for

This notice explains how UmojaHub handles personal information when you create an account, follow an association, receive a community update, organise or collaborate on an event, buy or receive a ticket, or contact us. An association may also be responsible for information it enters about its members, guests and event team.

Information we process

We process account and authentication details; private association follows and channel choices; privacy-minimum community notification and delivery receipts; association and organiser profiles; event, role and access information; buyer names and email addresses; orders, refunds, tickets, seating assignments and check-in records; optional guest display names, avatars and self-supplied profile details with a separate sharing choice for each field; programme schedules, collaboration tasks, acknowledgements, evidence, decisions, risks, issues, private operational documents, closeout records and audit records; and messages needed to deliver sign-in links, invitations, community updates, alerts and tickets. Where an association needs it to plan an event, its authorised team may record the minimum necessary accessibility, dietary, transport, supplier or VIP service information. Technical request and essential-cookie information may be processed to keep sessions secure and operate the service.

Payments

Stripe processes card payments. UmojaHub receives payment status, transaction references and limited customer details needed to fulfil and support an order. We do not store full card numbers or card security codes.

Travel and experience partner offers

A published event may show optional accommodation, transport, tour, excursion or related-event offers only after the association has accepted the partner-offer programme and while the selected placement and offer are active and within their stated validity window. Booking takes place with the partner under the partner’s terms. UmojaHub may earn a commission, but it does not take the partner booking payment, hold inventory, promise price or availability, or make the partner booking part of the event-ticket contract.

An outbound offer click is routed to the platform-entered stored destination. UmojaHub does not add an order, ticket, email, account or other guest identifier to that destination, does not set a partner-tracking cookie, and does not keep a row for an individual click. It keeps only an increment-safe placement-by-UTC-day count for operational reporting. Request-rate-limit subjects are keyed hashes retained briefly for abuse prevention. Click counts are indicative and are not conversions, revenue or earnings.

Association finance access and exports

Association owners control who may see financial summaries, masked order lists, customer identity, accounting exports, customer-data exports, refunds, billing and finance-access settings. These capabilities may be association-wide or limited to one event and may expire or be revoked. A platform administrator does not receive an association’s finance powers merely because they operate UmojaHub.

Accounting exports contain financial entry, event, order-reference and source information but no buyer name or email address. Customer-order exports are separately permissioned and may contain buyer contact details where an authorised association team needs them for fulfilment or support. Export attempts and completed exports are recorded in the append-only audit trail. Financial-entry records are append-only so sales and refunds remain reconcilable; UmojaHub does not estimate processor fees or payouts that are not available from an authoritative source.

Where an association enables Stripe Connect, Stripe hosts identity, business and bank verification and acts as that association’s payment processor for payouts. UmojaHub stores the Stripe account reference and coarse readiness or requirements status only. UmojaHub does not collect or store bank account numbers, sort codes, identity documents or Stripe’s verification answers.

Why we use it

We use this information to provide requested accounts, event workspaces and tickets; administer payments and refunds; secure the service; keep an accountable record of access and operational decisions; deliver service email; support users; and meet applicable legal obligations. Depending on the activity, processing is necessary to perform a contract, comply with law, or pursue legitimate interests in operating and protecting UmojaHub and the events hosted on it. We use consent where the law requires it.

Sharing and international processing

Information is available only to authorised association organisers, event collaborators and suppliers within their assigned scope. Organisers may issue an expiring, revocable pack containing selected approved operational document versions to a named event audience; VIP-sensitive and safety-sensitive files are not available through those external packs. We use service providers for hosting, authentication, payment processing through Stripe, and transactional email delivery through Resend. Providers process information under their own safeguards and contractual terms; some may process it outside the UK using recognised transfer safeguards.

Website usage analytics

We use Umami, hosted at analytics.stargeneral.co.uk, to understand page visits, navigation, ticket selection and checkout submissions. It receives page paths, referring site origins, browser language and screen size, together with the technical connection information needed to receive the request. Public event and association paths help us understand interest in each event. Private routes are grouped without record identifiers. We do not send form contents, names, email addresses, ticket credentials, query strings or account identifiers in analytics payloads. A checkout submission is not proof of payment. Analytics use no advertising cookies. You can opt out below; this stores only your preference in this browser. Browser blocking and opt-outs mean these figures are not a complete count of visitors. With your permission, we also sample 15% of public event-page visits for session replay, for up to five minutes. Contact fields, other forms, headers and footers are excluded and inputs are masked. Replay uploads end when you leave the page. You can withdraw replay permission below.

Cookies

UmojaHub uses essential cookies for sign-in sessions, security and the private preview gate. These are required for the requested service. We do not use advertising cookies.

Following and community updates

Following is a private account preference. Public pages may show only an aggregate follower count: an association organiser cannot use UmojaHub to enumerate followers or export their email addresses. A follow grants no association membership, event role, workspace, guest, finance, incident, VIP or safety access. You can choose email and in-product new-event updates separately for each followed association. Only a discoverable event’s first publication creates an update, and delivery uses the current follow and channel choices.

Each community email explains why it was sent and includes a signed, association-scoped unsubscribe link. Its token is stateless, contains only the user, association, token version and expiry needed to apply the request, is not stored as a marketing profile, and expires after 30 days. Opening the confirmation page does not change a preference; submitting the unsubscribe changes only that association’s email channel. Unfollowing deletes the follow and its channel choices and stops future community delivery. A minimum prior notification receipt may remain as service history for display, deduplication and delivery accountability; it is not an organiser mailing list.

Association discovery, claims and platform administration

UmojaHub may create an association profile from public registers, an association’s public website or public event-organiser information and record a sourced business contact so the association can be invited to review and claim it. Claim invitations are expiring, single-use and tied to the intended email address; only a hash of the claim token is stored. Accepting a claim requires a signed-in, verified matching email address and creates the association owner access requested by that person.

Association owners may invite verified administrators and request an ownership transfer. These requests are expiring, single-use and tied to the named account; only token hashes are stored. Acceptance, cancellation, administrator revocation and completed ownership changes are recorded for access-control accountability. Removing permanent access may also revoke current event roles, financial grants and hub leadership while retaining historical authorship and audit evidence.

A small number of explicitly authorised UmojaHub platform administrators can view cross-platform association, event, claim, commercial-subscription and operational information needed to operate and secure the service. Community information and inbound group-digest operations are shown to them as aggregate counts; follower and attendee lists, guest profiles, group source labels or identifiers, digest summaries or excerpts, private EventOS documents, payment-card data, invitation tokens, queue payloads and secret values are excluded. Privileged changes and exports are recorded in an append-only audit trail. Association ownership alone does not grant this platform access.

Event-day and offline device information

Authorised event teams may record ticket check-in outcomes, shift attendance, briefing acknowledgements and incident observations needed to operate and account for an event. Incident access is restricted by role and classification. When a connection is temporarily unavailable, a scanner device may hold an expiring event label, public verification keys and a limited encrypted queue of provisional ticket scans or short non-sensitive operational observations. It does not download a guest list, payment information, private files, VIP or safety-sensitive records. Queued commands are deleted from the device after final server reconciliation, when they expire, when the user signs out, or when the operator clears the device. The server keeps minimum command receipts and rate-window counts needed for integrity, conflict handling and abuse prevention; these do not contain the QR value or incident narrative.

Consented group-planning digests

An association may invite one of its event-planning groups to an optional controlled digest service. The group must first receive the approved notice and agree, and a named association authority records that consent. A dedicated WhatsApp bridge or an authorised manual chat export may then pass messages into a restricted transient buffer. Phone-like numbers are redacted and message authors are pseudonymised before synthesis, attachments are not collected, and raw group identifiers are not stored in UmojaHub. Consent can be withdrawn at any time; withdrawal stops new ingestion and triggers deletion of that group’s transient buffer.

UmojaHub receives only a short, unverified event-team digest with up to ten brief excerpts and proposed tasks, issues, decisions, risks or notes. It does not receive or store the raw transcript. Nothing is created or applied automatically: a current named event-team member must review and accept or dismiss each proposal under the normal workspace permissions. Digests cannot create VIP- or safety-sensitive records and do not affect readiness, gates, alerts, insights or analytics while pending.

Deterministic rules may create the digest locally. Where the association separately opts in and the documented provider safeguards are complete, pseudonymised message text and the minimum event-hub taxonomy may be sent to UmojaHub’s approved external AI provider for automated synthesis. The review screen identifies which mode was actually used. A provider failure falls back to rules mode. A count-only review update is not posted back to the group unless a separate controlled-pilot reply gate has been approved.

Guest profiles and seating

A ticket holder may use a private ticket-specific link to add a seating name and optionally upload an avatar or add pronouns, an organisation or community, a role or profession, and a short introduction. The seating name is visible to authorised organisers so they can run the seating plan. Every other field is hidden unless the guest separately chooses to share it. Shared profile information is available only inside the authorised event seating workspace and is not added to the public event or association directory. Guest bearer links expire 30 days after the event ends and the buyer can revoke and replace one immediately; buyer-account access may remain available while the profile is retained. A guest can change, unshare or remove profile details while they have access. Avatar files are kept in private storage and served only after current ticket-holder, buyer or authorised event-team access is checked.

Live event participation (Umoja Pulse)

Where an association switches on Umoja Pulse for an event, a ticket holder may open a private, ticket-specific link to take part during the event: sending branded reactions, boosting songs from the organiser’s list, answering polls, entering challenges and receiving voucher-code rewards. The link is separate from the admission ticket, can be revoked and replaced from the ticket page, and sets an essential cookie on the device that opens it. Pulse uses the seating name or the first name from the order that you already gave us; the organiser sees a name on a challenge entry only where you chose to show it, and performer and stage screens receive counts only. Check-in status comes only from the door scanner. Reactions are stored with the participant reference for up to twenty-four hours for rate limiting and the live meter, then deleted; only per-session counts and fifteen-second aggregate snapshots are kept. Onboarding steps are recorded as counts by platform type, never with an IP address or browser string. Reward codes are stored as hashes and redeemed once; draws, winners, redemptions and moderation are recorded in the audit trail. The after-event memory card contains the event, the night’s peak, your badges and your chosen name only.

Closeout reports and next-edition memory

A named authorised organiser may close an event and issue a bounded report containing attendance totals, public programme information, status counts, readiness, explicitly selected approved sponsor proof, warnings and human-authored approved lessons. The report excludes guest and payment records, private document content or links, incident narrative and location, decision rationale, and VIP- or safety-sensitive detail. Closing does not resolve incidents, approve finance or certify safety.

A sealed report and its source snapshot, approved reusable lessons, issued next-edition template and clone receipt form versioned organisational memory. They record named authority, time, source version and the link to a new draft edition, and cannot be routinely edited or deleted after issue. Only authorised association roles can use this private memory. Public event archives continue to expose only published or past public-edition fields.

Operational packs, suppliers and private safety records

An authorised organiser may explicitly activate a versioned operational pack. The activation receipt records the association, event, selected version, named actor, time and content hash so later catalogue changes do not rewrite the event’s history. Pack suggestions are planning aids: UmojaHub does not decide whether an event is legally in scope, certify compliance, approve safety arrangements or replace the organiser, venue, competent adviser, emergency services or Safety Advisory Group.

Safety and protective-security records are classified and available only to current named roles with the corresponding grant. Private reminders state only that a human review is due; they do not include procedures, risk detail or document content. A current supplier role sees only its assigned work, acknowledgements and exact current approved document versions in an assigned hub. Supplier access is rechecked on every request and stops on expiry or revocation. Suppliers do not receive guest, order, check-in, finance, VIP, safety-sensitive or unassigned event information through that workspace.

Private insights, operational analytics and integrations

Authorised association roles may see deterministic suggestions derived only from that association’s approved reusable lessons and sealed closeout sources. Every suggestion explains its source and classification. Selecting, dismissing or applying one creates a named receipt; applying it adds a new planning item to a draft cloned edition and does not change the sealed source. VIP- and safety-sensitive lessons remain grant-scoped and are excluded from general insight counts.

Operational analytics use event-scoped counts and bounded date ranges for readiness, blocked work, acknowledgements, staffing, seating and lesson adoption. Small positive acknowledgement and staffing groups are suppressed, and exports contain fixed aggregate metrics rather than guest or supplier identities. An association owner may configure an allowlisted HTTPS integration endpoint. Signing secrets are encrypted and never displayed after entry; deliveries use a versioned minimum-data envelope, signature, timestamp and idempotency key. Delivery history stores hashes, status and safe error codes rather than response bodies or unnecessary payload copies. Endpoints can be disabled, revoked or rotated.

Retention and security

We retain information only while it is needed for the service, event accountability, dispute handling, security and applicable legal or financial-record obligations. A follow and its channel choices last until you unfollow, close the account, or the association is removed; unfollowing deletes both. Community notification receipts are kept only while needed for the user-facing history, deduplication and delivery accountability, and are removed if their user, association or event is deleted. Unsubscribe tokens are not stored and expire after 30 days. Sign-in, checkout and offer-redirect rate-limit windows contain only keyed hashes and counts and are automatically removed after 48 hours. Partner-offer wording and destination snapshots, placements and day-bucket click counts may be retained as commercial and display accountability evidence after an offer is paused or archived; they contain no guest identity. Pending claim tokens expire after their stated invitation period; accepted, expired and revoked claim state and the minimum associated audit evidence may be retained while needed to prove authority and protect the association page. Sourced onboarding contact details are reviewed and removed or corrected when no longer needed or when the association supplies authoritative details.

Raw group messages in the restricted orchestration buffer are deleted after their synthesis window and no later than seven days, or earlier when the source is revoked. Count-only terminal delivery evidence is deleted after 30 days. UmojaHub retains only the bounded digest, minimum hashed envelope receipt and named human action provenance as event accountability while the association uses the service or they are needed for security, disputes or legal obligations. Provider request and response bodies are not stored in UmojaHub.

Draft supplier activity and operational records remain subject to the association’s managed event lifecycle and access revocation. Pack activation and upgrade receipts, insight decision receipts and integration delivery attempts are retained as append-only accountability evidence while the association uses the service or they are needed for security, disputes or legal obligations. Integration endpoint secrets are replaced on rotation and endpoint configuration can be revoked; delivery bodies and remote response bodies are not retained in delivery receipts. Aggregate analytics are calculated from the underlying operational records rather than retained as an independent personal profile.

Draft or rejected closeout material remains subject to the association’s managed event lifecycle. Sealed closeout reports and source snapshots, approved reusable lessons, issued templates, clone receipts and their named audit links are retained as immutable event accountability and organisational memory while the association uses the service or they are needed for disputes, security or legal obligations. Orders, financial entries and related audit evidence are retained for applicable tax, accounting, fraud, dispute and legal requirements. Privileged grant, claim, export, onboarding, subscription-reconciliation and controlled-retry audit evidence is retained while needed for security, accountability, disputes or legal obligations. When other information is no longer required, it is deleted or anonymised where technically and legally appropriate. Private storage, classification-aware access controls, scoped and expiring roles, privacy-safe rate limiting, least-privileged runtime database access, encrypted integration secrets, hashed share links and an append-only audit trail protect event collaboration records.

Your rights

Under UK data-protection law you may have rights to access, correct, erase or restrict your information, object to some processing, and receive portable information. You may also complain to the UK Information Commissioner’s Office. Some rights are limited where information must be kept for payment, fraud prevention, legal claims or an immutable accountability record.

Contact

To ask a privacy question or exercise a right, email privacy@umojahub.co.uk. We may need to verify your identity and, where an association controls the relevant information, coordinate the response with that association.