Privacy Policy

Version: 1.2 Effective date: upon first publication Last reviewed: 2026-05-07

Beta phase notice

The Flat Rock Events app is in a private beta phase. During beta, the platform infrastructure (the Firebase project, Cloud Functions, mobile and web codebases, deployment pipeline) is operated by Patrick Mikes (Serenica Digital) on behalf of the Client, the corporate event organizer using the platform.

The Client decides who is invited to events, what data is collected from attendees, what notifications are sent, and how the app is used at their events. Under GDPR and similar laws, the Client is the data controller for that personal data. Patrick Mikes provides the platform infrastructure as a data processor acting on the Client's instructions for those purposes.

For service-side telemetry that helps keep the platform working (crash reports sent to Sentry, system logs in Google Cloud), Patrick Mikes is an independent controller. These telemetry flows are described in section 7.5 and have personally identifying fields stripped client-side before transmission.

At public launch, the Client takes over the platform infrastructure itself and the processor relationship described above ends. You will be notified in-app before the transition takes effect. No new categories of data will be collected as a result of the transition, and no user consent will be re-collected — this is a change in the organization providing the platform, not a change in what is done with the data.

1. Who we are

This privacy policy covers the Flat Rock Events mobile app (iOS and Android) and its companion web admin portal.

During the beta phase, the data controller for your personal data (under GDPR Article 4(7) and equivalent laws) is the Client, the corporate event organizer that has invited you to participate. The Client decides who is invited to events, what data is collected from attendees, and how the platform is used at their events. The Client's identity is communicated to you when you receive an invitation; the Client is also identified in event-specific branding inside the app.

Patrick Mikes, an individual operating under the name Serenica Digital, located in the State of Michigan, United States ("we," "us," "our"), provides the platform infrastructure during beta as the Client's data processor (under GDPR Article 4(8)). Patrick Mikes is also an independent controller for service-side telemetry described in section 7.5.

For questions about this policy, how your data is handled, or to exercise any of the rights described in section 10, contact us at events-support@serenicadigital.dev. Requests we cannot fulfill on the Client's behalf will be forwarded to the Client and you will be notified.

For users in the European Economic Area, United Kingdom, or Switzerland, you also have the right to lodge a complaint with your national supervisory authority.

2. Scope

This policy applies to:

This policy does not cover:

The platform is designed for corporate events. Attendees, organizers, speakers, and internal team members all use the same mobile app with different permissions. Organizers additionally use a web admin portal.

3. What information we collect

We collect the minimum information needed to run an event, help you navigate it, and let the organizing team coordinate with you.

3.1 Account identifiers

When you create an account, we store:

3.2 Contact information

If you provide them, we store:

All of these are optional. You can leave them blank.

3.3 Profile content

If you choose to provide them:

All optional.

3.4 Health-adjacent information for event accommodation

The data model includes two fields we treat as sensitive under GDPR Article 9 (special category data):

When collected, these fields exist specifically so the organizing team can accommodate you at the event. They are visible only to you and to the event's organizers (see section 6).

Implementation status — section 3.4

During beta, the app does not collect this data from you directly. The structured fields above exist in the schema and the security rules tier them appropriately (only you and the event's organizers would be able to read them), but no in-app input UI writes to them today. If the organizing team needs your dietary or accessibility information during a beta event, they will collect it through their own channels outside the app (registration forms, email, or direct conversation), not through this app. The in-app input UI is deferred until after beta. When that UI is built, this section will be updated to reflect what the app actually collects, and an explicit consent surface will be added at that time per section 11.

3.5 Event participation data

As you use the app, we record:

3.6 Notification engagement

When an organizer sends a notification, we record:

This is used to show you unread counts and to give organizers aggregate delivery statistics.

3.7 Device and technical data

For push notifications to work, we store:

Each time the app starts it also records the app version and build number you are running, your platform (iOS / Android), and the time of that launch, so we can tell which installs still need an update.

If the mobile app or the admin web app crashes or throws an uncaught error, we send the stack trace, error message, and a small amount of device metadata (operating system or browser version, device model, app or build version) to our crash reporting provider, Sentry. We do this so we can find and fix bugs before they affect more users. Personally identifying fields (your name, email, phone number, profile content) are stripped from these reports before they leave your device. See section 7.5 for the full disclosure.

We do not collect, store, or transmit any of the following: advertising IDs (IDFA, AAID), device fingerprints, telemetry, analytics session data, or any other identifier not needed to deliver a push notification or fix a crash. See section 7 for our explicit non-use of third-party tracking and analytics SDKs.

3.8 Email delivery metadata

When we send you an email (invitation, notification, or event announcement), we record the delivery state (queued, sent, failed) and the timestamp, so organizers can confirm you received important messages and so we can troubleshoot delivery failures.

3.9 Internal notes about you

If you attend an event as an external guest of the organizing company, members of that company's internal team may record short administrative notes about you in a separate internal collection — for example, the name of a company you are associated with, or a tag used to group attendees for event operations. You cannot read these notes yourself. They are visible only to the organizing company's internal team, organizers, and admins.

We disclose this because the data exists and the law requires transparency about what is stored, even when access is restricted.

4. How we use your information

We use the data described in section 3 for the following bounded purposes:

PurposeData used
Letting you sign in and stay signed in3.1, 3.7
Showing you the event agenda and its navigation3.5 (membership, audience-group assignments)
Showing you the event map, your travel arrangements, and weather at the venue3.5 (travel)
Letting you browse speakers, sponsors, and other attendees3.1, 3.2, 3.3 (subject to your privacy settings, see section 5)
Letting you save private notes to individual sessions3.5 (notes)
Recording your survey responses for organizers3.5 (survey responses)
Delivering push notifications and emails about the event3.6, 3.7, 3.8
Accommodating your dietary and accessibility needs at the event3.4
Giving organizers the contact details they need to reach you about the event3.1, 3.2
Giving internal team members context for event operations3.9

We do not use your data for:

5. Privacy controls in your hands

The platform is built with privacy as the default. When you first create an account, your information is visible only to you and to the event organizers who need it. You do not appear in the attendee directory until you explicitly choose to be listed, and even then only the specific fields you choose to share are visible to other attendees.

5.1 The master toggle

There is a single master setting: "Show me in the attendee directory." It is off by default. While it is off:

5.2 Per-field visibility

If you turn the master toggle on, you then control — field by field — which details of your profile are visible to other attendees:

Each field is individually off by default and must be turned on explicitly.

Your name and profile photo are always visible in the directory if you have opted in — that's the minimum to be findable at all. If you want complete invisibility to other attendees, leave the master toggle off.

5.3 How changes take effect

When you turn a toggle on or off, the change takes effect immediately. A background process running on our servers synchronizes the change across the app.

Implementation status — section 5

The master toggle and per-field toggles exist as data fields in the app's database today and the server-side sync is in place. The mobile app's privacy settings screen that lets you actually flip the toggles is in development and is not yet shipping. Until it ships, the defaults above are enforced automatically (nothing is visible) but you will not see the UI described in this section. This policy will be updated to match the shipping app when the screen lands.

6. What your event organizer can see

This section is the single most important disclosure in this policy. Please read it carefully.

Event organizers and the organizing company's internal team have access to your full profile regardless of your privacy settings. The controls in section 5 affect what other attendees can see. They do not restrict what organizers see.

Specifically, organizers of events you are a member of can see:

Organizers cannot see:

The organizing company's internal team (staff and employees) additionally may record notes about you — the "internal notes" described in section 3.9 — which you cannot read.

Plain-language summary: treat anything you put in your profile as visible to the people running the event you are attending. If you would not want the event organizer to see it, do not put it in the app.

Organizers also have the technical ability to set a profile photo on your behalf — for example, when you are a speaker at an event and the organizing company's marketing team already has a professional headshot for you. When this happens, the photo becomes your profile photo across the whole app and is visible on your profile everywhere.

7. Sharing with third parties

We share your data with the following third parties, and only for the purposes listed. During the beta phase, the Client is the data controller for your personal data and Patrick Mikes (Serenica Digital) is the data processor providing the platform infrastructure (see the beta notice at the top of this page). Patrick is also an independent controller for the service-side telemetry described in §7.5. The parties below are sub-processors of the Client, sub-processors of Patrick's telemetry processing, or independent controllers as noted.

7.1 Google Cloud / Firebase

The app runs on Google Cloud, using Firebase (Firebase Authentication, Firestore database, Firebase Cloud Messaging, Firebase Cloud Functions, Firebase Storage, and the Firebase "Trigger Email" extension). Google is our primary data processor.

7.2 SMTP email delivery

Email messages (invitations, notifications, confirmations) are delivered via an SMTP service. The service receives:

During beta, the platform uses Mailtrap's transactional sending service for real email delivery from events.serenicadigital.dev. (In developer environments, a separate Mailtrap sandbox inbox captures messages for testing without delivering them.) At public launch, email delivery transitions to the Client's corporate mail infrastructure; the specific provider will be named in this policy at that time.

7.3 Push notifications via Google Cloud Messaging

Push notifications are delivered through Firebase Cloud Messaging (FCM), operated by Google. FCM receives:

FCM does not receive your name, email, user ID, or any other personal identifier. The mapping between FCM tokens and users stays inside our Firebase project.

7.4 Sign-in providers

If you sign in with Google, Apple, or Microsoft (instead of creating a password), the relevant provider processes the authentication:

7.5 Crash reporting via Sentry

When the mobile app or admin web app crashes or throws an uncaught error, the diagnostic information described in section 3.7 is sent to Sentry (sentry.io), operated by Functional Software, Inc. Sentry is configured to:

The data is hosted in Sentry's United States region. Our contractual basis is Sentry's standard Data Processing Addendum.

You cannot opt out of crash reporting in-app. It is operationally necessary for a small team to maintain a working app for thousands of users. If you object to crash data being collected at all, the practical outcome is account deletion.

7.6 Apple WeatherKit and Apple MapKit

The mobile app shows weather forecasts at event venues and renders maps of event locations.

These flows are subject to Apple's privacy policy.

7.7 Microsoft 365 ecosystem (Client tenant)

The platform is integrated with the Client's Microsoft 365 tenant for organizer workflows. These integrations replicate event and attendee data into the Client's Microsoft tenant, where it is governed by the Client's Microsoft tenant agreements rather than this policy.

The Client controls retention, access permissions, and downstream use of all data inside their Microsoft tenant. If you have questions about how the Client uses data inside their tenant, contact the Client's organizer team via the contact in section 1.

7.8 BigQuery analytical mirror

Event data is exported from Firestore to a Google BigQuery dataset for analytical reporting via the Firebase firestore-bigquery-export extension (one install per collection, currently seven collections exported).

7.9 App Review demo account

Apple App Store reviewers and similar app-distribution review processes require functional demo credentials to evaluate the app. To support this, we maintain a deterministic demo account (email contains the prefix apprev-) and a scoped demo event that exists alongside production data. Reviewers use this account to navigate a representative event during their review. The demo account and demo event do not contain real attendee data, and the account is the only way for an outside reviewer to access the platform without an organizer-issued invitation.

7.10 What we do not share, and do not use

The platform does not currently use:

We do not sell your personal information, and we do not share it for cross-context behavioral advertising. For users in California, this means we do not engage in "sale" or "sharing" as those terms are defined by the CCPA.

We do not share your data with any party beyond the ones listed above.

8. Where your data is stored

Your data is stored in Google Cloud's us-east1 region (United States) for Firestore and Firebase Storage. Firebase Authentication data is stored in Google's global authentication infrastructure. Push notification tokens are processed by Firebase Cloud Messaging's global infrastructure.

The BigQuery analytical mirror (§7.8) is also located in us-east1 during beta. Data replicated to the Client's Microsoft 365 tenant (§7.7) is stored in whatever region the Client's Microsoft tenant is provisioned for; consult the Client's organizer team for that region.

For users in the European Economic Area, the United Kingdom, or Switzerland: your data is transferred to the United States. We rely on Google Cloud's Standard Contractual Clauses as the transfer mechanism. Additional transfer mechanisms (binding corporate rules, sector-specific adequacy decisions) for both Google and Microsoft processors will be confirmed at public launch.

9. How long we keep your data

Retention windows are set per category:

CategoryRetention
Account data (profile, contact, privacy settings)For as long as you have an account
Event participation (memberships, audience-group resolutions, travel, survey responses, notes)For as long as you have an account, or for as long as the event exists — whichever is shorter
Email delivery recordsUp to 90 days after the final delivery state is known
Notification receiptsUp to 180 days after the notification was sent
Queued outbound emails (mail collection)Up to 30 days after delivery
Invitation records (active and accepted)Up to 90 days after the invitation is accepted by your first sign-in
Invitation records (revoked)Up to 30 days after the status changes
Event content (sessions, speakers, sponsors, locations, groups, travel items)For the lifetime of the event
Daily Firebase Auth metadata backups30 days, per the storage bucket lifecycle policy
Archived eventsRetention window to be decided by the Client at public launch
Implementation status — section 9

Several of these retention windows (notification receipts, email deliveries, invitation records) are proposed defaults, not currently enforced. The scheduled cleanup jobs that would enforce them are listed as engineering work to be done. Until they ship, these records persist indefinitely in the database. The 30-day TTL for queued outbound emails (mail collection) and the 30-day lifecycle policy on Auth metadata backups are live. This policy will be updated as additional enforcement work lands.

When you delete your account (see section 10.1), most of your personal data is removed within a reasonable time frame. Some records are kept as described in the next section.

10. Your rights

You have the following rights over your personal data. Section 10.5 is the jurisdiction-specific summary for the EEA/UK and California.

10.1 Account deletion (right to erasure)

You can request the deletion of your account and all personal data associated with it. When this happens, the following will be erased:

A consequence to be aware of: because we delete your survey responses, the aggregate counts and average results shown to organizers will adjust downward when your account is deleted. This is the result we prefer over retaining anonymized records indefinitely.

What is not erased by account deletion:

How to delete your account

In-app account deletion is available from the mobile app at Settings → Delete Account. A confirmation dialog describes exactly what is deleted; confirming triggers the cascade described above within a few seconds and signs you out. If you cannot reach the in-app button for any reason, email us at the contact address in section 1 and we will delete your account on your behalf within one month (GDPR Article 12(3)).

10.2 Access to your data (right to know / right of access)

You have the right to obtain a copy of the personal data we hold about you.

Implementation status — section 10.2

Self-service data export is not yet implemented. Until it ships, access requests must be submitted via the contact address in section 1. We aim to respond within one month. The export will include a copy of your profile, event participation, check-ins, feedback, notes, and notification receipts in a structured JSON format.

10.3 Correction (right to rectification)

You can correct your profile, contact information, and privacy settings yourself in the app at any time. Corrections take effect immediately. If a correction requires action we cannot take on your behalf through the app (for example, correcting a historical check-in record), submit the request via the contact address in section 1.

10.4 Objection and restriction

You can ask us to stop processing your data or restrict how we use it. Submit the request via the contact address in section 1. Note that certain processing is required for the app to function — if you object to all processing, the practical outcome is account deletion.

10.5 Jurisdiction-specific rights

European Economic Area, United Kingdom, and Switzerland (GDPR / UK GDPR): The Client is the data controller for your personal data during the beta phase. Patrick Mikes (Serenica Digital) is the data processor providing the platform infrastructure, and is an independent controller for the service-side telemetry described in §7.5. Lawful bases for processing are: (a) performance of a contract (Article 6(1)(b)) for account creation and event participation, (b) legitimate interest (Article 6(1)(f)) for organizer access to contact information, notification delivery, and crash reporting, and (c) explicit consent (Article 9(2)(a)) for the dietary and accessibility fields described in section 3.4. At public launch, the Client takes over the platform infrastructure itself and the processor relationship ends. You have the right to lodge a complaint with your national supervisory authority. Contact information for supervisory authorities is available on the European Data Protection Board's website.

California (CCPA / CPRA): California residents have the right to (a) know what categories of personal information we collect, (b) access their specific personal information, (c) request deletion, (d) correct inaccurate information, (e) limit the use of sensitive personal information, and (f) opt out of the sale or sharing of their personal information. We do not sell or share personal information as those terms are defined by the CCPA, so there is no opt-out mechanism to display — we simply do not do it. To exercise any other right, contact us at the address in section 1. We do not discriminate against users who exercise their rights.

Other jurisdictions: If you are located outside the EEA, UK, Switzerland, or California, you still have the rights described in sections 10.1–10.4 under this policy.

11. Sensitive (special category) information

Section 3.4 described two fields that we treat with extra care:

We collect these fields only if you choose to provide them. Their purpose is to let the organizing team accommodate you at a physical event: plan catering menus that meet your dietary needs, and ensure the venue and materials are accessible.

Under GDPR Article 9, these can qualify as "special category data" because dietary restrictions may reveal health conditions (e.g. celiac disease, diabetes) or religious beliefs, and accessibility needs are health-adjacent. Our lawful basis for processing them is your explicit consent under Article 9(2)(a).

How we limit access:

You can leave these fields blank, and you can clear them at any time by editing your profile.

Implementation status — section 11

The explicit-consent toggle is deferred along with the in-app input UI that would need it (see section 3.4). Because the app does not currently collect dietary or accessibility data from you directly during beta, there is no in-app surface where Article 9(2)(a) consent would need to be captured. When the in-app input UI is built post-beta, the explicit-consent toggle will be added at the same time, and this section will be updated. If the organizing team collects this information from you outside the app during a beta event, the legal basis for that collection lives in whatever process they use, not in this app.

12. Children's privacy

The platform is designed for adults attending professional and corporate events. It is not intended for and not directed at children under 16 (or under 13 in jurisdictions where the applicable age threshold is lower, such as the United States under COPPA). We do not knowingly collect personal information from children.

If you believe a child has created an account, contact us at the address in section 1 and we will delete the account.

13. Security

We use Firebase's managed security controls to protect your data:

No system is perfectly secure. If you become aware of a vulnerability, please contact us at the address in section 1.

14. Changes to this policy

We may update this policy from time to time as the app evolves, as regulatory obligations change, or as we add or remove features. When we make a material change, we will:

Minor corrections (typo fixes, clarifications of existing behavior) may be made without notice.

You can always find the current version of this policy at this URL and inside the app under Settings → Privacy Policy once that screen is implemented.

15. Contact us

Questions about this policy, or requests to exercise any of the rights in section 10:

For security vulnerability reports, use the same email address and include "Security" in the subject line.