Skip to content
EMEGA EMEGA
Trust, privacy, and responsible use

Privacy Policy

How EMEGA and participating schools handle account, communication, student, parent, operational, and integration data.

Last updated: 22 May 2026 Managed policy
This policy describes the standard EMEGA service. The operating school or organization must confirm its legal identity, contact details, enabled features, service providers, retention schedule, and lawful bases before publication.

1. Scope and roles

This policy applies to EMEGA websites, administrator workspaces, shared inboxes, CRM records, admissions and support workflows, website chat, connected communication channels, automation, artificial intelligence features, and approved school-system integrations.

Depending on the deployment and the applicable agreement, a school or organization normally decides why school, parent, student, applicant, and communication data is processed. EMEGA or its operator may process that data on the organization’s instructions. EMEGA may act independently for its own account administration, service security, billing, product support, and legal compliance. The exact roles are determined by the relevant agreement and applicable law.

2. People covered

This policy may cover organization owners, administrators, staff, teachers, applicants, candidates, parents, guardians, students, prospective families, website visitors, support contacts, and people who communicate through connected providers.

EMEGA is designed for education and may process information about children and students. Schools and authorized guardians must use age-appropriate notices, permissions, and access controls where required. EMEGA does not sell children’s personal data or use school records for behavioral advertising.

3. Data we may process

  • Workspace and account data, including names, work contact details, roles, branches, departments, teams, permissions, sign-in records, and preferences.
  • Parent, guardian, student, applicant, candidate, and contact profiles, including identifiers, contact details, relationships, branch, grade, program, language, and CRM fields configured by the organization.
  • Admissions, academic, attendance, fee, payment, transport, document, certificate, support, complaint, recruitment, and follow-up data when the relevant module or integration is enabled.
  • Conversation content and metadata, including messages, internal notes, attachments, audio, provider identifiers, delivery and read events, assignments, tags, summaries, and automation history.
  • Knowledge Base and AI data, including approved articles, retrieved excerpts, prompts, outputs, confidence and grounding records, approvals, corrections, and safety decisions.
  • Integration data, including channel account identifiers, access scopes, webhook events, token metadata, provider errors, and encrypted credentials where needed to operate a connected service.
  • Technical and security data, including IP address, browser and device information, cookies, session records, audit logs, diagnostics, abuse signals, and backup records.

Some configured school workflows may involve sensitive or special-category data. Such data must be limited to what is necessary and handled under an appropriate legal basis and stronger safeguards.

4. How data is obtained

Data may be supplied by the person, a parent or guardian, an authorized school employee, an imported school record, a connected education platform, a communication provider such as Meta or Telegram, a website chat session, or automatically through service and security logs.

An organization must have authority to upload, connect, or disclose data to EMEGA and must keep source records accurate. Provider data remains subject to the provider’s terms and privacy practices.

5. Why data is used

  • Provide the shared inbox, CRM, admissions, support, recruitment, task, reporting, and branch-management functions requested by the organization.
  • Match provider identities to the correct contact and maintain a complete authorized communication history.
  • Route work, notify responsible staff, manage service windows, record delivery status, and prevent duplicate or conflicting actions.
  • Retrieve approved knowledge and generate grounded drafts or replies under the organization’s AI and human-approval settings.
  • Authenticate users, enforce role and branch permissions, protect accounts, detect abuse, investigate incidents, and maintain audit records.
  • Provide support, diagnose failures, improve reliability, administer subscriptions, and meet contractual or legal obligations.

Data is not used for a materially incompatible purpose without notice and an appropriate legal basis.

7. Artificial intelligence and automated assistance

EMEGA can retrieve approved Knowledge Base content, classify intent, summarize conversations, propose CRM changes, and draft customer replies. AI output may be incomplete or wrong. Configuration should require human review for sensitive, high-impact, low-confidence, or ungrounded actions.

EMEGA should not be treated as the sole decision-maker for admission, employment, discipline, fees, health, safeguarding, or other decisions with significant effects. Authorized staff remain responsible for final decisions and for reviewing automated outputs.

8. Sharing and subprocessors

Data may be shared only as needed with authorized organization users, the relevant school or branch, contracted hosting and infrastructure providers, configured AI providers, messaging and email providers, storage or backup providers, and professional advisers or authorities where legally required.

EMEGA does not authorize third parties to use school data for their own advertising. Active third-party services should be listed on the Subprocessors page or in the customer agreement. Provider APIs may independently receive data needed to deliver their service.

9. International transfers

Connected providers, hosting, support, or AI services may process data outside the person’s country. The organization and EMEGA operator must assess transfer requirements, use required safeguards, and disclose relevant locations and recipients. A feature should not be enabled when a lawful transfer mechanism is unavailable.

10. Retention and deletion

Data is retained only for the period needed for the stated purpose, the organization’s configured schedule, contractual support, security, dispute resolution, backup rotation, and applicable legal requirements. Different records may have different periods.

When data is no longer required, it is deleted, anonymized, or securely isolated until backup expiry. Deletion requests may be limited where retention is legally required or necessary to protect rights, investigate abuse, or preserve an audit record. The public Data Deletion page explains how to submit a request.

11. Security and access

EMEGA uses role, branch, team, and permission controls; encrypted transport; protected credentials; private storage controls; validation; provider signature checks where configured; audit logs; and operational monitoring. No online service is risk-free.

Organizations must use strong authentication, remove access promptly, protect exported files, configure least privilege, maintain supported software and backups, and report suspected compromise without delay.

12. Your choices and rights

Depending on applicable law, a person may have rights to be informed, access data, receive a readable copy, correct or complete data, object or restrict certain processing, withdraw consent, request deletion, and complain to a competent authority.

Requests may require identity and authority verification, especially for student or child records. A guardian’s request may be checked against school records. EMEGA and the organization will respond according to their respective roles and applicable deadlines and exceptions.

13. Contact and changes

Use the Contact and Support page or the Data Deletion page to submit a privacy request. Include only the information needed to identify the relevant account, school, branch, or conversation.

This policy may be updated when services, providers, laws, or operational practices change. Material changes should be communicated through the website, workspace, contract contact, or another appropriate channel. The date shown on this page identifies the latest published revision.