At the center of Neostella is a simple idea: software should adapt to firms, not firms to software.
Most case management systems force organizations to adjust their processes to fit a rigid data structure. Neostella takes a different approach. It provides a flexible schema layer that allows firms to, first, model their real-world operations, later to build workflows, forms, and tools on top of that foundation.
Schema is not just a technical configuration. It is the system’s shared understanding of how information exists, connects, and is used across Neostella.
One Schema, Two Perspectives
Schema operates across two connected layers that serve different roles in the platform.
On one side is the Control Center, where admins define structure, rules, and behavior. This is where the Schema is designed and governed.
On the other side is the Cases layer, where end users interact with that schema through forms, records, and workflows as part of their daily work.
End users never see the Schema directly, but it powers every interaction they perform such as entering information, updating a case, reviewing related data.
Data: The System’s Shared Understanding
Data defines how information is modeled inside Neostella.
Rather than working with a fixed database, admins design a data model that reflects how their firm actually operates. Objects represent real-world entities, fields describe them in detail, and relationships connect everything together.
This structure becomes the single source of truth for the entire platform. Once defined, it is reused consistently by forms, workflows, documents, reporting, automations, and AI-powered features. Nothing is redefined or duplicated across tools.
Although this process resembles database design, Neostella translates that complexity into a visual, admin-friendly experience. Admins focus on modeling their business, not managing technical constraints.
Under the hood, Neostella uses a graph-based data model, where information is stored as interconnected entities rather than isolated tables, so the system understands context. . A case is not just a record — it is connected to clients, documents, tasks, communications, and related entities.
Each firm operates within its own isolated data graph, ensuring that data never overlaps, customizations remain independent, and security is preserved.
In practical terms, Data defines what exists: which records the system can store, what sort of information they contain, and how they relate to one another.
Forms: Where Data Becomes Actionable
If Data defines structure, Forms define experience.
Forms are the mechanism through which users interact with the data model. They do not create new information or rules. Instead, they project the schema into clear, guided interfaces that users can understand and act on.
Every time a user enters information, reviews a record, or updates a case, they do so through a form. Forms control what users see, what they can edit, and how information is captured at each stage of a case or workflow.
Forms are entirely dependent on Data; therefore they inherit its rules automatically. Field behavior, validations, relationships, and permissions are enforced consistently, without requiring separate configuration.
This ensures that data is captured in a structured, predictable way — while still adapting to the context in which users are working.
In practice, Forms translate technical data definitions into usable, real-world workflows.
A Single Foundation, Many Outcomes
The power of Schema lies in how Data and Forms work together.
Data establishes a shared, system-wide understanding of information. Forms apply that understanding to real user interactions. Because both rely on the same foundation:
- Fields behave consistently across the platform.
- Reporting and automation stay aligned.
- Changes made upstream flow naturally downstream.
- Data entered once becomes usable everywhere.
This separation of structure and experience enables Neostella to remain flexible without losing control.
Why Schema Matters
Schema is what allows Neostella to scale with a firm over time.
As processes evolve, new requirements emerge, or teams grow; admins can extend the data model and adjust forms without breaking existing functionality. The system adapts, because the schema was designed to reflect the firm — not the other way around.
In simple terms:
- Data defines what exists.
- Forms define how users interact with it.
- Schema ensures everything works together.
Comments
0 comments
Please sign in to leave a comment.