Privacy & data disclosure

1. Partner CRM data — appointment and contact records that already exist in a partner practice's own CRM sub-account, mirrored into the portal so the practice can report on them.

2. Personal calendar data — optional, only if a user connects a work calendar. This is used solely for busy-time conflict checking and is kept separate from CRM data.

Signing in uses Google or Microsoft. The portal receives your basic account identity (email address, and the name/profile the provider returns) and uses it only to identify your account and decide what you may see. The portal does not read your mailbox, files or contacts for sign-in.

External partner users reach partner data only through an explicit membership of a specific partner company, recorded in the portal by a Super Admin. Internal ASHER staff signing in with a verified joinasher.com address are provisioned according to the portal's configured administrator domain policy rather than an individual invitation.

For each connected partner sub-account, the portal mirrors and stores:

• Contact identifiers and contact details as provided by the CRM (such as name, email, phone), and CRM contact tags used for confirmation status.
• Appointment records: CRM appointment id, calendar id, assigned user, start/end times, status and cancellation state.
• Outcomes recorded in the portal: attendance, sales outcome and any revenue value entered by an authorized user.
• Message history for a contact, read from the CRM where available, shown read-only.
• Integration state: CRM location id, connection settings, encrypted CRM access credentials, and operational event records (opaque ids and processing results only).

Access is company-scoped and enforced on the server: a partner user's requests are restricted to the company they belong to.

Connecting a personal work calendar is optional. When connected via Google:

• The portal requests identity scopes (openid, email, profile) and the read-only calendar scope https://www.googleapis.com/auth/calendar.readonly. No mail, files, contacts or calendar-write scopes are requested.
• The calendar connection is brokered by Nylas, a third-party calendar-integration provider. Nylas holds the calendar authorization grant on the portal's behalf.
• The portal stores: the connection/grant identifier, provider, the connected account's email address as reported by the provider, the company the connection belongs to, connection status and last error, and for each calendar its identifier, display name, time zone, primary and read-only flags, plus your conflict-calendar selection.
• For conflict checking the portal queries Nylas for the selected calendars over a bounded date window and requests only the when and busy fields; it keeps busy start and end times only. Event titles, descriptions, attendees, locations and conferencing details are not requested, parsed or stored by this path.
• The portal does not create, edit or delete events in your personal calendar.
• Microsoft personal-calendar connection is not enabled in this portal.
• Connecting a calendar is optional and the access requested is read-only. Google's authorization screen may ask for additional confirmation steps, and a connection is not guaranteed to complete on every account. Calendar connections that already work keep working, and declining or disconnecting affects nothing else in the portal.

A separate availability feature can write generic busy blocks into the practice's CRM calendar based on those busy intervals. Those blocks carry times only — no personal event details. The feature is off by default; each user turns it on for their own connection and company, and it can only produce CRM blocks once a Super Admin has mapped that user to a CRM staff member and calendar. Turning it off removes the blocks the portal created.

The measures below describe mechanisms that are implemented in this application. They are statements about how the software is built, not a certification or an audit result.

• Transport. The portal is served over HTTPS, and every request it makes to the calendar provider goes to an https:// endpoint; a configured API address that is not HTTPS is rejected and the default secure address is used instead.
• No provider tokens in the portal. Google access and refresh tokens are held by Nylas, the calendar-integration provider. The portal stores only the opaque grant identifier it needs to make read-only requests; it never receives, stores or logs your Google password or Google tokens.
• Server-side credentials. The keys used to talk to Nylas, and the webhook signing secret, exist only as server-side environment values read by server-only code. They are never included in the browser application and are never exposed to a signed-in user.
• Access controls on stored calendar records. Sign-in is required for every non-public page. The database tables holding calendar connections, calendar lists and busy-block records have row-level security enabled with a policy that denies direct access to signed-in application sessions, and no read privileges are granted to the browser-facing database roles. They are reachable only through server-side code, which scopes every read and write to the connection's own user and company. A calendar connection can produce CRM busy blocks only after a Super Admin has mapped that user to a CRM staff member.
• Connection flow integrity. The one-time value that ties an authorization attempt to the person who started it is stored only as a SHA-256 hash, compared in constant time, usable once, and expires after ten minutes.
• Notification integrity. The endpoint that receives calendar change notifications rejects any request whose body does not carry a valid HMAC-SHA256 signature made with the server-side webhook secret, caps the accepted body size, records each notification once so a replay cannot repeat work, and acts only on event created, updated and deleted notifications.
• Least data requested. Calendar reads use a GET request that asks for the when and busy fields only, so event titles, descriptions, attendees, locations and conferencing links are never received by the portal.

The portal makes no claim here about encryption at rest, key management, independent penetration testing or any compliance certification.

The portal writes back to the practice CRM only: appointment attendance updates, sales outcome and revenue values recorded by an authorized user, the confirmation contact tag, and generic availability busy blocks when a user has enabled that feature. It performs no writes to a personal Google calendar.

Automatic deletion of mirrored contact records from CRM deletion events is deliberately disabled in this release: such events are acknowledged and ignored. Appointment deletion events only mark a mirrored appointment as deleted after the CRM authoritatively confirms the appointment is gone for that company; any ambiguous answer leaves records untouched.

• GoHighLevel (the practice CRM) — source of appointment/contact data; receives the writes listed above.
• Nylas — calendar authorization and read-only calendar access, when a calendar is connected.
• Google / Microsoft — sign-in identity; Google additionally for read-only calendar access if connected.
• Supabase — the database and authentication service that stores portal data and user sessions.
• Lovable — the platform that builds and hosts the portal application.

The application contains no advertising or analytics-advertising integration, and it sends no calendar or CRM data to any AI, machine-learning or model-training service. Data obtained from Google APIs is used only for the busy-time conflict checking described above.

The portal's use of Google sign-in and Google Calendar data complies with the Google API Services User Data Policy, including the Limited Use requirements. Google user data is used only for the purposes described on this page — authentication and optional read-only calendar busy-time conflict checking — and is not sold, transferred, or used for advertising.

You can disconnect a personal calendar from the portal's Settings → Calendar Connections at any time. Disconnect first removes any CRM availability blocks the portal created, then asks Nylas to revoke the calendar grant, then deletes the stored connection and calendar selection for that company. The revocation request is best effort: if the provider call fails, the portal still removes its own stored connection but the upstream authorization may remain until it is removed at the provider. You can always remove the portal's access directly in your Google Account's third-party access settings.

Busy intervals are read on demand for conflict checking and are not retained as an event archive. What is retained for a connection is: the grant identifier, provider, connected account email, the company it belongs to, connection status and last error, plus each calendar's identifier, display name, time zone, primary and read-only flags, and your conflict-calendar selection.

Two short-lived operational records also exist for the calendar connection: the one-time authorization value described above, which is deleted when it is used and otherwise expires after ten minutes, and a de-duplication record per calendar notification holding the notification identifier, trigger name and processing result — never event contents. No fixed deletion schedule for those operational records is published.

CRM records mirrored into the portal are removed or changed through the CRM and the portal's administrators; the portal does not offer a self-service purge, and no promise of immediate or automatic deletion is made here. To request removal of specific data, contact charlene.laganson@joinasher.com. A formal retention schedule for this portal has not been published; requests are handled case by case.

This portal makes no certification claim of any kind (including HIPAA, SOC 2 or ISO), and no independent audit or production security verification is asserted here. This disclosure describes how the application is built, not a compliance attestation.

Asher Health's general company policies are published separately at joinasher.com/privacy-policy. They are provided as a general reference; the disclosure on this page is what applies to the Growth Portal application. See also the portal terms of use.