Individual configuration screens are rarely the hardest part of a school software implementation. The harder problem is the map: knowing what depends on what, what is still unfinished, and whether something that looks configured is actually ready to use.
That is where implementations quietly go wrong. A school "finishes setup" in July and discovers in September that report cards were never configured, or that this year's fee structures are last year's, or that the admission form parents were sent has been sitting in draft the whole time.
Guided Setup exists for that problem. It is a dependency-aware checklist of what a school needs configured, presented in a workable order, where each item's status is derived from the school's current configuration rather than from a note that someone once pressed a button.
It is a map, not a gate. Nothing here stops you working the way you prefer; it tells you where you are.
Guided Setup reflects the current configuration
Guided Setup does not keep a separate record of your progress. Every time the checklist is requested, each item is evaluated against the school's current configuration, reading the same underlying records the rest of the platform works from. There is no wizard-only version of the truth to keep in step.
Two consequences follow, and both are intentional.
Work done anywhere counts. Configure something through the normal administration pages, or through any other authorised workflow, and the checklist reflects it. Nobody maintains a second progress tracker alongside the real system, and reopening Guided Setup picks up whatever has happened since.
If the configuration changes, the next evaluation reflects that changed state. Remove something essential and the corresponding item can return to incomplete, bringing the setup prompt on the dashboard back with it. A setup status is a statement about the school's configuration now, not a certificate that it was correct once.
What Guided Setup actually covers
Twenty-one checklist items across five groups. Twelve are required and nine are optional recommendations.
- Foundation: branch, institution details, governance policy
- Academics: academic year, classes, sections, subjects, daily schedule, grading scale
- People: roles, HR and payroll masters, staff, students
- Fees and finance: fee categories, fee structures, financial year, chart of accounts, opening balances
- Communication: payment gateway, notifications, admission form
The wizard presents these as nineteen steps, because two pairs are naturally configured together: sections sit inside the classes step, and the chart of accounts sits inside the finance step.
Administrators meet it first on the dashboard, where a card shows how many required steps are done and offers the next few that are actually actionable, meaning not finished, not optional, and not blocked by something else.
Existence is not readiness
This is the idea the whole feature rests on, and it is worth understanding before trusting any setup checklist, including ours.
The naive check asks whether a record exists. That is almost always the wrong question, because a great deal of configuration is created automatically, seeded on your behalf, or enabled by default. Ask "does a row exist" and you will congratulate a school for configuring things nobody has opened.
So each check asks a different question: does the configuration satisfy what this item actually needs to be usable?
| The record exists, but | So the check requires |
|---|---|
| A governance policy row is created the moment someone opens the page | The policy to carry real configuration, or at least to have changed from its untouched state |
| System roles are seeded for every school | At least one active role the institution created itself |
| The admission form is auto-created with its version left in draft | A published version |
| Email and SMS are enabled by default on platform credentials | The school's own provider, which is why this item is optional |
| Fee structures may belong to last year | Structures for the current academic year |
| Students may be archived, withdrawn or alumni | Students who are actually active |
| Staff may have resigned or been terminated | Staff whose employment status is active |
| A daily schedule may hold only lunch and recess | Teaching periods |
| A financial year can be marked current and also closed | Current and not closed |
| A chart of accounts can consist only of its system accounts | At least one active account that is not a system account |
One example is worth expanding, because it shows the difference between counting and checking. Sections used to be counted on their own, and a school with fourteen sections passed. Except that all fourteen belonged to one class, and eleven of the other twelve classes had none. The count was true and the conclusion was useless. Classes and sections are now evaluated together, and where classes are missing sections, the checklist names them.
There is matching honesty in the other direction. When a check cannot be evaluated, the item is reported as indeterminate rather than incomplete: the checklist flags it in amber and says it could not check that one right now, rather than showing a school a failure it has not earned. A live check is still software, and treating an error as "not done" would be its own kind of false report. It also does not make the validation logic infallible, which is why the checklist tells you what it found rather than asserting that everything is correct.
Required and full completion are different states
Required setup complete means all twelve required items are satisfied. This is the operational milestone: progress is measured against required items only, and the dashboard card removes itself, with no dismiss button, because nothing essential remains.
Full checklist complete means every item is satisfied, optional recommendations included. That is what produces the completion screen.
Optional items never block required setup and never reduce required progress. They stay visible and reachable. A school that has deliberately not connected a payment gateway is finished with required setup, not stuck in it.
Forms inside, links out
Six steps are inline forms: branch, institution and locale, academic year, classes, HR and payroll, and finance setup. These are focused tasks that genuinely fit in a modal, and they write through the same paths the normal pages use rather than a parallel implementation.
The other thirteen are guide steps. They explain what is needed, show whether it is done or blocked, and link straight to the real page. Bulk imports, form builders, multi-record configuration and work involving several people do not belong in a wizard, and rebuilding them there would mean maintaining a second, worse copy of a feature that already exists.
The principle: a setup wizard should not become a second, inferior copy of the application.
Two steps depend on apps being enabled: HR and payroll needs the HR & Payroll app, and finance setup needs Accounting. Rather than offering a button that would fail, the wizard checks first and shows guidance with a link to the App Store.
Dependencies, locked steps and skipping
Guided Setup sequences work along the dependencies the platform actually enforces. These are Guided Setup dependencies, not claims about school administration in general:
- Almost everything follows the branch, which is the first thing to exist.
- Sections follow classes.
- Students follow classes and the academic year.
- Fee structures follow fee categories, classes and the academic year.
- The chart of accounts follows the financial year, and opening balances follow both.
Two deliberate non-dependencies are worth stating, because the intuitive order is stricter than the real one. Adding students does not require fee structures to exist first. Adding staff does not require HR masters, which are optional; gating staff on an optional step would strand any school that skipped it.
Skipped and locked are different states. Every accessible step can be skipped: skipping defers it, keeps it visible, and marks nothing as done. A step whose prerequisite is missing is locked and cannot be opened, because opening it would only produce an error. The checklist names what it is waiting for, so "why is this locked" is answered on the row itself, and it unlocks by itself once that prerequisite exists.
One exception is intentional: an item that is already done reports no blockers, even if it was completed out of order. If staff were added before HR masters existed, that is a real state of the school, and flagging it afterwards would be noise.
Initialization is a baseline, not a policy
Two items offer a one-click action, and precision matters here.
HR masters can be initialized with a standard set of departments, designations, leave types and salary structures, so a school starts from something workable instead of an empty screen. It is safe to run more than once: repeating it does not create duplicates.
The chart of accounts can likewise be initialized into a standard account tree, also safely repeatable, and it needs a financial year first. Its completion check looks specifically for an active account that is not a system account, so the system skeleton alone does not read as a configured chart.
Initialization satisfies the requirement because it establishes the necessary baseline. It does not assert that the school has reviewed that baseline against its own structure, which remains real work.
Configure, populate, validate, go live
Guided Setup is one stage of an implementation:
- Configure. Establish platform structure and required configuration. This is what Guided Setup covers.
- Populate. Create or import students, staff, historical records and opening balances.
- Validate. Review configuration, data, financial figures, integrations and real workflows.
- Go live. Begin normal operation.
These are a practical model rather than formal product phases. Note that opening balances appear as an optional item explicitly labelled as migration: the platform points at that work, it does not do it for you.
What "setup complete" does not mean
Completing required setup means the required configuration is present and the platform has the structure it expects. It does not mean:
- Every student or staff member has been imported
- Historical records have been migrated
- Opening balances have been entered and validated
- Every fee rule has been reviewed against your policy
- Every timetable has been checked
- Users have been trained
- Integrations have been tested
- Real operational workflows have been exercised end to end
- The institution has completed go-live validation
Saying so plainly is not a weakness in the product. A checklist that implied otherwise would be setting schools up to discover the gap in September.
Stopping, resuming and changes
Guided Setup is safe to leave halfway, because there is no separate progress to lose.
Resuming re-evaluates the current state rather than restoring a remembered position. Reopening the wizard takes you to the first unfinished required step, so anything completed in the meantime is already accounted for.
Guide steps carry a refresh status action. Finish the task in another tab, come back, refresh, and the step flips to done in place without dragging you onward.
The same derivation that makes this work is what allows an item to move back to incomplete if its configuration is later removed. The wizard is a view of current readiness, not a bookmark of past progress.
After setup
With required setup satisfied, the card is gone and the normal ScolaOS modules become the working environment, which is where the guide steps were pointing all along. Optional recommendations stay available from the checklist hub.
Guided Setup is not a separate operating mode. It is a configuration layer over the real platform, and it keeps reflecting the current state rather than becoming a historical record.
That is also a small illustration of how the wider platform is built: it can reason about the relationships between institution, branch, academic year, classes, people, finance, communication and the apps a school has enabled, rather than treating each module as an isolated screen.
What Guided Setup helps an administrator answer
- What still needs to be configured?
- What is required, and what is a recommendation?
- Why is this step locked, and what unlocks it?
- What exactly makes this item count as complete?
- Can I do it elsewhere in ScolaOS instead? (Yes.)
- Why does something still show incomplete when the record exists?
- What work remains outside Guided Setup entirely?
Completed items display the configuration behind them rather than a generic tick, so an administrator can confirm what is actually set instead of trusting the mark.
Frequently asked questions
Where do I find Guided Setup? On the admin dashboard. A card shows required progress and the next actionable steps, with buttons to open the wizard or view the full checklist.
What does it configure? Platform structure and foundations: branch and institution details, academic year, classes and sections, subjects, roles, HR masters, fee categories and structures, financial year, chart of accounts, opening balances, admission form and communication settings.
Can I skip a step? Any accessible step, yes. Skipping defers it and marks nothing complete. Steps blocked by a missing prerequisite are locked rather than skippable, and unlock once the prerequisite exists.
Does my progress save? There is nothing to save. Status is evaluated from your configuration each time, so it is current by construction.
What if I configure something outside the wizard? It counts. The checklist reads the same records regardless of where the work was done.
Why does a step show incomplete when the record exists? Because the check asks whether the configuration is usable. A draft admission form, last year's fee structures, a closed financial year or a schedule of breaks only will each read as incomplete.
Does Guided Setup import students or staff? No. Those are guide steps linking to the real pages, where records can be added individually or imported in bulk. The wizard does not move your data.
What if HR or Accounting is not enabled? Those two steps check first and show guidance with an App Store link instead of an action that would fail.
Does completing it mean we are ready for go-live? No. It means the required configuration is present. Population, validation and training are separate work, and go-live readiness is your team's decision.
What if someone changes configuration later? The relevant item can return to incomplete and the card can reappear. That is deliberate.
How long does setup take? That depends on your data rather than the settings, so any figure we quoted would be invented. The configuration steps are short; preparing student, staff and financial data is what to plan for.
In summary
Guided Setup is not a checklist of buttons to click. It is a way to understand whether the underlying configuration of a school is actually ready, and it derives that status from the school's current state rather than a stored completion flag.
That is why an item can be complete when someone did the work elsewhere, why it can stop being complete when the configuration changes, and why a record existing is never by itself the answer.
When ScolaOS marks a setup requirement as complete, it is reporting a configuration state, not remembering that someone once clicked a button. Something in your school is configured and usable, not merely present.
To see how the pieces fit together, explore the ScolaOS platform, browse the app catalogue, read the frequently asked questions, or talk to our team about what your school's configuration would involve.
ScolaOS is a product of Terra System Labs Pvt Ltd, which is ISO 9001:2015 compliant and ISO 27001:2022 compliant.