SUMMARY
Privacy follows organization, school, and user-role context.
Kesekolah is designed as a multi-tenant ERP. Operational data is separated by organization and tenant, while feature and data access is limited through authentication, roles, permissions, policies, and backend business rules.
Scope
This policy covers interactions with the Kesekolah website, demo or contact requests, and use of Kesekolah services provided to schools, foundations, or education organizations. Customer contracts may set more specific rules for a particular deployment.
- The company profile website, feature, pricing, demo, contact, and legal pages.
- Initial communication through email, WhatsApp, or another configured official channel.
- The School ERP application and modules enabled for a customer's organization or tenant.
Data that may be processed
Data categories depend on customer modules and configuration. The Kesekolah blueprint covers platform, SIS, academic, facility, operations, finance, document, and audit data.
- Account and contact data such as email, phone number, account status, and login information required by the authentication service.
- Organization, school/tenant, campus, building, floor, room, role, permission, and user-access relationship data.
- Student, guardian, and staff data such as student number, NISN/NIK, other relevant identifiers, name, date of birth, contact details, nationality, and configured profile information.
- Academic and operational data such as enrollment, homeroom, course section, schedules, attendance, assessments, gradebooks, report cards, and status histories.
- Finance and transaction evidence such as invoices, payments, expense requests, cash advances, settlements, fund returns, reimbursements, journals, related bank details, and attachments.
- Technical and audit data such as user actions, record changes, timestamps, workflow statuses, and metadata required for security and process traceability.
Website, contact forms, and browser preferences
The current company profile uses a simple frontend pattern. Information entered into a contact or demo form is assembled in the browser and handed off to an available official channel instead of being sent to this company profile backend.
- When a sales email is configured, the browser opens the user's email application with a subject and message assembled from the form.
- When WhatsApp is configured, the browser opens the official WhatsApp channel with a message assembled from the form.
- The interface language is determined by the URL prefix (/id or /en) and does not require storing a language preference in localStorage or cookies.
- After a user moves to email, WhatsApp, demo, payment gateway, or another third-party service, processing on that service follows the provider's terms.
Purposes of data use
Data is used as necessary to provide, operate, support, and secure Kesekolah according to the customer's enabled module scope.
- Provide authentication, tenant access, roles, permissions, and application experiences appropriate to user responsibilities.
- Run enabled academic, SIS, enrollment, facility, scheduling, attendance, grading, finance, and workflow processes.
- Process approvals, statuses, notifications, documents, transaction evidence, and configured integrations.
- Maintain audit trails, transaction consistency, business validation, troubleshooting, and operational support.
- Support migration, UAT, reconciliation, reporting, and compliance requirements within the agreed implementation scope.
- Respond to demo requests, commercial questions, support requests, or other official communications from users and prospects.
Access, isolation, and security
The Kesekolah technical baseline places authorization in the backend rather than relying on hidden UI. Available controls depend on the customer's modules and deployment.
- Protected application routes use authentication and token mechanisms according to backend configuration.
- Policies/Gates, roles, and permissions limit user actions according to resource and authority.
- Operational data uses organization and tenant context to prevent data from different schools or foundations from being mixed.
- Audit/activity logging is used on selected resources to help trace changes and user actions.
- Business validation, transaction boundaries, dependency guards, and ownership rules protect the integrity of connected records.
Data sharing and integrations
Kesekolah does not require every integration for every customer. Data only needs to leave the application when the selected function uses an external provider or channel.
- Authorized users within the customer's organization or tenant according to assigned roles and permissions.
- Communication channels such as email, WhatsApp, SMS, push, or in-app notifications when enabled and configured.
- Payment gateways, banking/payment workflows, or other transaction providers when relevant finance modules use them.
- Regulatory integrations, exports, APIs, webhooks, or third-party systems approved within the implementation scope.
- Infrastructure or technical service providers required to operate the deployment, according to the customer contract and environment configuration.
Retention, deletion, and data lifecycle
The technical baseline underlying Kesekolah does not define one global retention period for every domain. Production retention should follow operational needs, customer contracts, deployment configuration, and applicable requirements.
- Some resources use soft delete, some use hard delete/cascade, and some include guards preventing important records from being deleted while still used downstream.
- Audit logs or histories may have a different lifecycle from primary business data so important changes can remain traceable.
- Deletion requests must consider dependencies, recordkeeping obligations, unfinished transactions, and the rights of related users.
- Specific retention periods, backup, restore, export, or destruction procedures may be defined in implementation documents or customer agreements.
Student and school-age user data
Kesekolah is built for education organizations, so student data may include children or school-age users. Such data should be used within the school/foundation's authority and the customer's internal policies.
- Customers are responsible for ensuring appropriate authority before entering or importing student and guardian data into the service.
- Staff access should be assigned according to job needs and least-access principles through roles and permissions.
- Users should not enter sensitive data that is unnecessary for school processes or the agreed implementation scope.
- Student, guardian, tenant, and organization relationships remain contextual so data can be used without ignoring organizational and access boundaries.
Rights, questions, and policy changes
Data requests are handled according to the roles of Kesekolah and the customer in the relevant deployment. In some implementations, the school or foundation may be the first party to receive a request because it manages end-user data.
- Users may ask about access, correction, updates, export, restriction, or deletion through official channels.
- A requester's identity and authority may be verified before data is changed or released.
- Controller, processor, administrator, and response procedures may be defined more specifically in customer contracts or data processing agreements.
- Requests may be limited when they conflict with legal obligations, audit needs, unfinished transactions, or the rights of others.
- This policy may be updated when features, integrations, architecture, or operational obligations change; the latest update date will be shown on this page.
PRIVACY QUESTIONS
Need clarification about data or implementation?
Contact Kesekolah through an official channel. Active customers should include their organization/tenant and request context so the team can route the request appropriately.