Use this when... you need to configure multi-branch operations, technical access, developer settings, API keys, integrations, or advanced organisation controls in TuitionFlow.

Before you start... treat this area as restricted admin work. Branch configuration affects people, lessons, billing, reports, and notifications. Developer settings and API access can expose or change data at scale. Only owners or trusted technical admins should make changes.

Use Settings for branch and advanced organisation configuration.

Branch settings define how your organisation separates locations, teams, reporting, permissions, scheduling, and sometimes branding or billing. Developer settings and API access support integrations, automation, data exports, or custom workflows.

Changes in this area can have wide effects. Plan them carefully and test with a narrow example before relying on them operationally.

Confirm whether branches represent physical locations, regions, teams, brands, franchises, or operational groups. Decide which users, tutors, students, leads, sessions, invoices, and reports should belong to each branch.

Set names, owners, contact details, scheduling defaults, notification owners, and reporting expectations. If branding or forms vary by branch, check those settings too.

Check Reports after branch changes so data appears in the expected place.

Only create API access when there is a clear use case and owner. Record what the access is for, which system uses it, who owns it, and when it should be reviewed. Never paste live keys into messages, notes, screenshots, or help articles.

After changing branch or API-related settings, test a safe record. Confirm the right users can see it, reports group it correctly, notifications go to the right people, and integrations behave as expected.

A user cannot see a record: check branch assignment, role permissions, and whether the record belongs to another branch.

Reports look split incorrectly: review branch assignment on students, tutors, sessions, invoices, and leads.

An integration stops working: check API access status, owner, secret rotation, permissions, and recent setting changes.

Review developer access periodically. Remove unused keys, rotate credentials according to your policy, and check whether connected systems still need the access they have. If a key may have been exposed, treat it as a security incident and rotate it.

Before launching a new branch, check branch name, owner, users, tutors, families, leads, rooms, services, forms, billing settings, notification recipients, and reporting filters. Create a test lead and test lesson so the team can see where records appear.

Every API key or technical connection should have a named owner, use case, creation date, and review date. If the integration belongs to an external supplier, record who to contact and what data the supplier can access.

Treat API keys and developer credentials as secrets. Do not paste them into support tickets, help articles, ordinary messages, screenshots, or shared documents. If a secret is exposed, rotate it and record the incident according to your security process.

After branch or API changes, review reports and permissions with a real admin workflow. A configuration can look correct in Settings but still create confusing operational outcomes.

Know who can disable an integration, rotate a credential, or reverse a branch mistake quickly. Advanced settings should have an owner who can respond when something breaks outside normal admin hours.

Keep a plain-language note explaining each branch and technical connection. Future admins should understand what it does without reading code or old messages.

If a developer setting supports an external supplier or integration, review it when the supplier contract changes, the integration owner leaves, or the connected workflow is no longer used. Remove access that no longer has a business purpose. Stale technical access is easy to forget and can become a security or data protection risk.

After changing branches or developer settings, test permissions, reporting, scheduling, billing, and integrations. Record the change owner and review date so future admins know why the configuration exists.