Skip to main content
synthEd
Log inStart free trial
Version 1.2.0

Privacy Policy

  • Effective Date: 2026-09-09
  • Provider: SynthEd LLC, an Oregon limited liability company ("synthEd," "we," "us," "Provider")

1. Overview

This Privacy Policy describes how synthEd collects, uses, shares, and protects information when a School, District, or other educational institution ("School") and its Authorized Users use the synthEd planning platform (the "Service").

The Service is designed for use by School staff to plan and coordinate events, tasks, and communications. We act as a service provider to the School and as a school official for purposes of FERPA, processing School data exclusively under the School's direction and for the educational purposes the School designates.

This Policy is provided alongside our Terms of Service and our Sub-Processors page, and is incorporated into the Terms of Service. Defined terms used here have the meanings given in the Terms of Service.

2. Information We Collect

We collect only what is necessary to operate the Service. The categories below describe what we store and where it comes from.

2.1 Account information

When an Authorized User signs in, we store:

  • Name, email address, role, and School/Department assignment;
  • A hashed password (when password authentication is used);
  • Passkey/WebAuthn credentials (when passkeys are enrolled);
  • Two-factor authentication secrets (when TOTP 2FA is enabled);
  • Single sign-on identifiers (when a user signs in with Google or Microsoft): the provider's account identifier, the Workspace domain or directory tenant ID we check the sign-in against, name, email address, and profile picture URL;
  • Notification preferences (in-app, email, daily digest time, scope).

We never see or store plaintext passwords. Passkey private keys never leave the user's device. Signing in with Google or Microsoft does not, by itself, give us access to the user's mail, files, or calendar.

2.2 Customer Content

Authorized Users create and store content in the Service, including:

  • Task titles, descriptions, statuses, and due dates;
  • Subtask assignments and notes;
  • Event information and calendar entries;
  • File attachments uploaded to the Service;
  • Hyperlinks to external resources ("Linked Content");
  • After-Action Report links and notes;
  • Messages and notifications generated within the Service.

This content belongs to the School. We process it solely to provide the Service and at the School's direction.

One narrow exception is described in Section 3: we may reuse the de-identified structure of the events, tasks, and templates a School builds — titles, dates, sequencing, and generic role labels — to improve our own template library. That reuse never includes names, notes, messages, attachments, links, Student Data, or the identity of your School, and a School can opt out.

2.3 Files and attachments

When an Authorized User uploads a file, it is stored in encrypted object storage operated by our hosting sub-processor and is addressable only by signed URLs scoped to authenticated users in the same School. File names and metadata are stored alongside the file. We do not scan or inspect file contents except as necessary to deliver them to authorized requesters.

2.4 Linked Content (URLs only)

When an Authorized User attaches a hyperlink (for example, to a Google Drive or OneDrive document), we store the URL string and a label — not the contents of the linked resource. The linked resource remains hosted by the third party that controls it. The Service does not fetch, cache, scan, or index the contents of Linked Content. As noted in our Terms of Service §10, URLs themselves can carry personally identifiable information; Schools are responsible for ensuring URLs and file names do not embed student PII where avoidable.

2.5 Connected Google accounts (Drive and Calendar)

Two optional features connect the Service to an Authorized User's own Google account. Both are off until the individual user connects them, and either can be disconnected at any time from Settings.

What we request. We ask only for narrow, per-resource scopes:

  • https://www.googleapis.com/auth/drive.file — lets us create a document in the user's Drive when they choose "Open in Google" for an AI-generated artifact. This scope grants access only to files the Service itself creates. It does not allow us to see, search, or read anything else in the user's Drive.
  • https://www.googleapis.com/auth/calendar.app.created — lets us create and maintain a synthEd calendar in the user's Google Calendar and write their School Planner events to it. This scope grants access only to the calendar the Service creates. It does not allow us to read the user's other calendars.

What we store. For each connection we store a Google OAuth refresh token and a short-lived access token, the identifier of the Drive file or Google Calendar we created, and sync bookkeeping (last sync time, error state). The tokens are encrypted with an application key before they are written to the database, are used only to perform the actions above, and are deleted when the user disconnects the integration or when the account is deleted under Section 7.

What we send to Google. Only the content the user is exporting or syncing: the body of the artifact they chose to open in Google, or — for calendar sync — the title, date, and a short description of the user's School Planner events and assigned action items. Planner items carry no time-of-day or location, so calendar entries are written as all-day events. We do not send Customer Content to Google for any other purpose.

Limited Use. synthEd's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. We do not use Google user data for advertising, we do not sell it, we do not transfer it except as necessary to provide the feature the user requested or as required by law, and we do not use it to train generalized machine-learning models.

Once a document is in the user's Drive, or an event is in the user's Google Calendar, that copy is governed by the School's own agreement with Google — not by this Policy. Deleting data from the Service does not delete copies the user placed in their Google account.

2.6 Calendar subscription feeds

An Authorized User may generate a personal calendar-feed URL to subscribe to their School Planner schedule from Apple Calendar, Outlook, or Google Calendar. The URL contains a long random token, and that token is what authorizes access — anyone holding the URL can read that user's schedule without signing in: the titles, dates, and status of their events and assigned action items, the department each belongs to, a link back to the item, and — in the calendar's own name and description — the user's name and the School's name. Feed entries are all-day items; the planner stores no time-of-day or location, so the feed contains none. We store the token, the user and School it belongs to, and basic usage data (last fetch time, fetch count) so a user can tell whether a subscription is live. Users should treat the URL as a credential and can rotate it at any time from Settings; rotating immediately invalidates the previous URL, which is also how a feed is revoked.

2.7 AI-assisted features

Where AI-assisted features are used, prompts and the Customer Content needed for the request (for example, a school's event and task structure) are sent to a third-party AI provider to generate a response. The provider and any underlying model operators are listed on the Sub-Processors page, and are contractually required to use the inputs and outputs solely to return the requested result and not to retain them for their own model training. We do not send Student Data to an AI provider beyond what is present in the Customer Content a user submits.

AI features are available where a School (or its District) has enabled the AI Planner add-on. They can also be invoked by a district administrator — a role with system-level access across the district's schools — on a school's behalf, including for a school that has not itself enabled the add-on. A School with no add-on whose district administrators do not use AI features has no data sent to an AI provider at all.

2.8 Billing and payment information

For Schools on a paid plan we store billing contact name and email, purchase order number, plan and add-on selections, term dates, and invoice status and history. Payments are processed by our payment sub-processor. We never receive or store full payment-card numbers or bank account numbers — those go directly to the payment processor, which returns only a customer reference and the status of each invoice. Billing information is School business information, not Student Data.

2.9 Technical and operational data

To operate and secure the Service we automatically collect:

  • IP address (used for session security, abuse prevention, and audit logs; retained on Terms-of-Service acceptance records);
  • Browser user-agent string;
  • Cookies and session identifiers (see Section 6);
  • Server-side logs of requests, errors, and security events. Logs are scrubbed of personally identifying values (email addresses, names, attachment URLs) before being transmitted to error-monitoring sub-processors.

2.10 Product analytics

We collect product-usage analytics — feature adoption, page views, aggregate counts — through PostHog. For a signed-in user we register who is using the product alongside their events: the user's email address and role, the names of their school, district, and department, and institutional context such as school size, plan, and add-on status. Event properties themselves are limited to identifiers, event names, and non-PII values (e.g., task counts, attachment types, School IDs), page addresses are scrubbed of record identifiers before they leave the browser, and we do not record user sessions. Customer Content — task titles, notes, attachment URLs — is never transmitted to our analytics provider.

Analytics also runs on our public marketing website; Section 6 describes the analytics cookie and what is collected from anonymous visitors.

2.11 What we do not collect

We do not knowingly collect:

  • Student grades, transcripts, disciplinary records, IEPs, or 504 plans as primary or original records;
  • Social Security numbers;
  • Health information governed by HIPAA;
  • Payment-card data subject to PCI-DSS;
  • Personal information of students under 13 beyond what is strictly necessary to schedule events and tasks that involve them.

The Service is not designed to be a system of record for any of the above. The School agrees not to store such records in the Service, as set out in Terms of Service §3.

3. How We Use Information

We use the information described above only to:

  • (a) provide, maintain, and improve the Service;
  • (b) authenticate users, secure sessions, and prevent abuse;
  • (c) deliver notifications and emails that users have opted into;
  • (d) respond to support requests from Authorized Users and School administrators;
  • (e) bill the School and collect fees due;
  • (f) generate aggregated, de-identified statistics about platform usage, following the de-identification standard in 34 C.F.R. § 99.31(b);
  • (g) reuse the de-identified structure of events, tasks, and templates created in the Service — titles, dates and school-day offsets, sequencing, recurrence, and generic role and department labels — to build and improve the templates we offer to other Schools, as described in Terms of Service §17. We strip everything identifying before we do: no personal names, assignments, notes, messages, attachments, links, Student Data, or identification of your School. A School administrator may opt out at any time by writing to legal@synthed.co;
  • (h) comply with our legal obligations and enforce our Terms of Service.

We do not:

  • Display advertising of any kind in the Service;
  • Sell, rent, or share Student Data for advertising, marketing, or any other commercial purpose unrelated to providing the Service;
  • Build behavioral profiles of students or School staff for any purpose other than providing the Service;
  • Use Student Data or Customer Content to train any general-purpose machine-learning model, or permit any sub-processor or AI vendor to do so.

4. FERPA, COPPA, and Student Privacy

4.1 FERPA — School Official designation

For data the Service processes on behalf of the School, synthEd operates as a "school official" with a legitimate educational interest under FERPA, 34 C.F.R. § 99.31(a)(1)(i)(B). This means:

  • We are under the direct control of the School with respect to the use and maintenance of Education Records;
  • We are subject to the same restrictions on the redisclosure of personally identifiable information from Education Records as the School itself;
  • We will not disclose Education Records except to the School or as the School directs.

4.2 COPPA — School-authorized consent

The Service is not directed at children under 13. Where a child under 13 appears in Student Data, the School represents that it either operates under the school-authorization exception (16 C.F.R. § 312.5(c)(10)) or has obtained verifiable parental consent. We use such data only for the educational purposes the School specifies and never for commercial purposes such as advertising or profile-building.

4.3 State student-data-privacy laws

We comply with applicable U.S. state student-data-privacy laws (including California SOPIPA, New York Education Law § 2-d, Illinois SOPPA, Colorado SB 16-187, and Connecticut Public Act 16-189). On request, we will sign a state-specific data privacy agreement or the Student Data Privacy Consortium's National Data Privacy Agreement where required.

5. How We Share Information

We share information only with the parties below, and only as needed to provide the Service:

5.1 With your School

Authorized Users within the School can see information consistent with the School's role and department structure. Super-administrators within the School can access all School data.

5.2 With synthEd personnel

synthEd personnel may access a School's data only to operate, secure, or support the Service, on a least-privilege basis. The Service includes an administrative capability that lets designated synthEd personnel view the Service as a School user in order to diagnose a reported problem. Its use is restricted and recorded in the audit log, and access without a documented operational reason is treated as a Security Incident and reported to the School under Terms of Service §14.

5.3 With our sub-processors

We rely on a limited set of vetted third-party providers for hosting, email delivery, error monitoring, analytics, file storage, payment processing, and AI model inference. Each is bound by a Data Processing Agreement requiring confidentiality and data-protection obligations no less protective than those in our Terms of Service.

A current list of sub-processors — including the data each one accesses and a link to its DPA — is published at /sub-processors. We provide advance notice of material changes to that list as described there.

5.4 For legal reasons

We may disclose information when required by law, court order, or valid legal process; to enforce our Terms of Service; or to protect the rights, property, or safety of the School, our users, or the public. Where we receive a legal demand for School data, we will notify the School unless legally prohibited from doing so.

5.5 In a business transfer

If synthEd is acquired, merged, or reorganized, the acquiring entity will be bound by this Policy with respect to information transferred. We will notify the School in advance of any such transfer.

5.6 With other Schools, as de-identified template structure

Where we reuse the de-identified structure of a School's events, tasks, or templates under Section 3(g), the resulting template may be offered to other Schools. What reaches them is structure only — titles, timing, sequencing, and generic role labels — with no personal information and no indication of which School it came from. We do not identify a School in a template or in marketing without that School's separate written agreement. See Terms of Service §17.

5.7 With your consent

We share information for other purposes only with the explicit consent of the School or, where applicable, the individual user.

6. Cookies, Local Storage, and Analytics

The Service uses cookies and similar technologies for:

  • Authentication and session management — keeping you signed in and remembering a sign-in verification in progress. Session cookies are first-party, signed, and restricted to same-site requests, which is how we protect against session theft and cross-site request forgery;
  • Sign-up, sign-in, and connection flows — briefly remembering an in-progress signup, the page to return to after login, and the state of a single-sign-on or integration connection while it completes;
  • User preferences — remembering theme (light/dark), task-view settings, and other UI state;
  • Product analytics — our analytics sub-processor (PostHog) sets a first-party analytics cookie and browser storage entry to distinguish visits and measure feature usage, as described in Section 2.10.

Our public marketing website too. The analytics described above also runs on our public marketing pages, so the analytics cookie is set for anonymous visitors as well as signed-in users. For visitors who are not signed in we collect page views and anonymous usage events only; we do not build a profile of an anonymous visitor or link their visit to a later account except as an ordinary consequence of signing in from the same browser.

Records of Terms-of-Service acceptance are kept in our database (see Section 7), not in a cookie.

We do not use advertising cookies of any kind, do not participate in cross-site advertising networks, and do not use analytics data for advertising or to profile individuals.

Browser local storage and the offline cache may hold application data on the user's device so the Service works quickly and offline, and may briefly queue diagnostic error reports on the device before they are transmitted to our error-monitoring sub-processor. Signing out through the app clears the session and the cached Customer Content associated with it; some non-sensitive preferences (such as the light/dark theme) persist until the user clears their browser storage.

7. Data Retention

Active data. We retain Customer Content for as long as the School's account is active.

Export window. On termination or written request, we make Customer Content available for export in a structured, machine-readable format for thirty (30) days.

Active-systems deletion. After the export window closes, Customer Content is deleted from active systems within thirty (30) days.

Backups. Database backups are encrypted before they reach backup storage and expire on a fixed schedule, published on the Sub-Processors page: point-in-time recovery history after seven (7) days, daily backups after thirty (30) days, weekly after one hundred eighty (180) days, and monthly after five (5) years; one encrypted yearly archive per year is retained long-term for disaster recovery. Deleted Customer Content therefore ages out of operational backups within days to months. Where a School asks us to remove its Customer Content from the long-term archives as well, we complete that as soon as each archive's tamper-protection lock allows, and in no case later than twelve (12) months after the active-systems deletion.

Integration credentials. Tokens for connected Google accounts are deleted when the user disconnects the integration, and in any case as part of the active-systems deletion above. Calendar-feed tokens are deleted with the user's account and are invalidated immediately on rotation.

De-identified template structure. De-identified structure we have already incorporated into our own templates under Section 3(g) is not Customer Content and is not removed by the deletions above — it contains no personal information and no identification of your School. Opting out under Section 9.2 stops future reuse; see Terms of Service §17(f) for what can and cannot be recalled.

Logs, diagnostics, and analytics. Error and diagnostic reports are retained by our error-monitoring sub-processor for ninety (90) days. In-product activity logs are retained for one hundred eighty (180) days for operational events, and for two (2) years for security-relevant events (sign-ins, role and permission changes, deletions, and support access) — security logs are kept longer deliberately, so that an incident investigation is not blinded by our own retention policy. Product-analytics events are retained by our analytics sub-processor while the School's account is active and are deleted on verified request.

Billing records. Invoices, payment status, and related financial records are retained for as long as required by tax and accounting law, typically seven (7) years, independent of the deletion of Customer Content.

Compliance records. Records of Terms-of-Service acceptance (including IP address and user-agent at acceptance time) are retained for the life of the account and a reasonable period thereafter to evidence consent.

We retain information beyond these periods only where required by law, and such retained data remains subject to the confidentiality and security obligations of our Terms of Service.

8. Security

We maintain administrative, physical, and technical safeguards appropriate to the sensitivity of the information we process, including:

  • Encryption of Customer Content in transit (TLS 1.2 or higher) and at rest;
  • Role-based access controls and least-privilege access for synthEd personnel;
  • Audit logging of administrative actions;
  • Regular security updates and dependency management;
  • At least annual internal review of our security program against a recognized framework (SOC 2, ISO 27001, or equivalent);
  • Multi-factor authentication (including passkeys and TOTP) available to all Authorized Users.

Certification status. We do not currently hold SOC 2, ISO 27001, or equivalent third-party security certification. The commitment above is to operate our security program by reference to those frameworks; nothing in this section represents that we hold, have applied for, or are in active audit against any such certification. See Terms of Service §12.

No system is perfectly secure. If we become aware of a Security Incident affecting Student Data, we will notify the School in accordance with Terms of Service §14 — without undue delay and in no event later than seventy-two (72) hours after confirming the Incident.

9. Your Choices and Rights

9.1 Access and correction

Authorized Users can view and update most of their profile information from the Settings area of the Service. For information not editable in-product, write to the contact below.

9.2 Export and deletion

The School controls export and deletion of Customer Content. Authorized Users should direct requests to their School administrator. Schools may at any time:

  • Export their data in a structured format;
  • Request deletion of specific records or of the entire account;
  • Opt out of the de-identified template reuse described in Section 3(g), by written notice from the School's designated administrator to legal@synthed.co.

A School administrator can erase the School's planning data and start over from the Settings area. Deletion of the School's account in full — including user records — is handled on written request from the School's designated administrator. Full deletion timing is described in Section 7.

9.3 Notification preferences

Users can disable in-app notifications and email notifications independently from Settings. Transactional emails required to operate the account (such as password resets and security alerts) are not subject to opt-out.

9.4 Connected integrations

Users can disconnect a linked Google account, and rotate a calendar feed URL (immediately invalidating the old one — rotation is how a feed is revoked), at any time from Settings. Disconnecting stops all further data flow to that third party and deletes the credentials we hold; it does not remove copies already placed in the user's own account.

9.5 Cookies

Users can clear cookies through their browser. Some cookies are required for the Service to function; clearing them will sign the user out and reset preferences.

9.6 State-specific rights

Where applicable state law (including California, Colorado, Virginia, Connecticut, and others) grants additional individual rights, those rights are available to residents of those states. Because the Service is provided to the School and we act as service provider / processor, individual rights requests should ordinarily be directed to the School. We will assist the School in responding to verified requests.

10. Children's Privacy

The Service is not directed at children and is intended to be used by School staff. We do not knowingly collect personal information from children under 13 outside the school-authorization framework described in Section 4.2.

If a parent or guardian believes a child under 13 has provided personal information to the Service outside that framework, please contact us at the address below and we will investigate and, if appropriate, delete the information.

11. International Users

synthEd operates the Service from the United States, and the Service is intended for use by U.S.-based Schools. Our sub-processors process data in the United States; where any sub-processor may process data outside the United States, we identify it on the Sub-Processors page. If you access the Service from outside the United States, your information will be transferred to and processed in the United States, which may have different data-protection rules than your jurisdiction.

12. Changes to This Policy

We may update this Privacy Policy from time to time. Material changes will be communicated to the School at least thirty (30) days before they take effect, by email to the School's designated administrator and by notice within the Service. The "Effective Date" at the top of this Policy reflects the most recent update. Continued use of the Service after the effective date constitutes acceptance of the updated Policy.

Where this Policy and our Terms of Service conflict on a privacy-related question, the Terms of Service control.

13. Contact

Questions, requests, or concerns about this Policy may be directed to:

SynthEd LLC — Ashland, Oregon

For a Security Incident affecting your School, please follow the breach notification procedure in our Terms of Service §14.