Schema – Data Overview

Data = the shared system understanding used across tools and processes

Data is the foundation of how firms model and manage their data inside the Neostella case management system (CMS). Rather than working with a fixed database structure, Data allows admins to design a data model that reflects how their firm actually operates.

Every object, every field, and every relationship defined here becomes part of the system’s shared understanding of data. This structure is later consumed by forms, workflows, documents, reports, and other tools across Neostella. In practice, everything that users will eventually fill out or interact with starts here.

 

What the Data Tool Is Responsible For

Data manages Neostella’s data model. It gives firms control over how information is represented and connected inside the system. Instead of adapting business processes to a rigid schema, admins define the schema itself.

This work revolves around three core elements: objects, fields, and relationships.

• Objects act as the main containers of information.
• Fields describe those objects in detail. 
• Relationships connect objects so information can flow naturally across the system. 

Together, these elements form a complete data model that represents the firm’s operational reality. These definitions form a shared, system-wide understanding of data. Once created, they are used consistently by other tools rather than being redefined multiple times in different places.

Although this process may resemble traditional database design, Data abstracts that complexity into a visual, admin-friendly experience.

Data is responsible for identifying what type of records exist in the system, what information those records contain, and how those records are connected to each other.

How Data Is Stored and Isolated

Neostella uses a graph-based database model. This means data is not stored in isolated tables with rigid constraints. Instead, information is represented as interconnected nodes (Objects) and links (Relationships).This approach allows the system to understand the context. 

For example, a case is not just a record — it is an object connected to clients, documents, tasks, communications, and related entities. These connections are first defined in Data and later leveraged everywhere else in the platform.

Each firm operates within its own isolated data graph. This tenant-level separation ensures that:

• Data never overlaps between firms.
• Customizations are fully independent.
• Security and data integrity are preserved at all times.

Data as the Foundation for Other Tools

Everything built in Data exists for one main reason: to be consumed later. Data is intentionally upstream of many other features.

Admins are not creating data structures in isolation. They are defining the backbone that forms, processes, and other types of users will rely on in the future. Before any of the other tools can act on information, that information must be modeled in Data.

How Data Works in Practice

Data works designing a database model, but without requiring database expertise.

Admins begin by defining Objects, which represent real-world entities such as cases, projects, clients, or documents. These objects establish what types of information the system needs to store.

Next, fields are added to describe those objects. Fields capture details such as statuses, dates, assignments, and identifiers. Over time, these fields become the structured data that powers reporting, automation, and search.

Once objects and fields exist, relationships are defined. Relationships ensure that data is connected instead of siloed. A client can be linked to multiple cases. A case can reference many documents or tasks. These connections allow Neostella to present complete, contextual information wherever it is needed.

To keep data models flexible, objects can be organized using types and subtypes. Types inherit attributes from their context while allowing for variation. This approach avoids duplication and supports complex structures without unnecessary overhead.

Finally, Schema applies context to the data model to control how information is displayed and accessed across Neostella. Lists, tables, forms, and sections all draw from the same underlying data model. Once defined, these configurations apply consistently across connected modules such as communications, workflows, document generation, reporting, and AI-powered search.

Data Concepts Explained

• Context

Context = the situational lens that determines how data is presented and interacted with across the platform.

Context defines where and how an object is being used at a specific moment. While Objects, Fields, and Relationships define what data exists, Context determines how that same data behaves depending on the user’s position, task, or workflow stage.

Context neither creates new data nor  alters the underlying data model. Instead, it applies meaning and relevance to existing data by shaping its presentation and behavior.

A single object can exist in multiple contexts. For example, a case viewed during intake, active case management, or review may reference the same underlying record, but appear differently depending on the situation.

• Objects

Objects = structured containers that define what data the system can manage.

Objects are the primary building blocks of Neostella, representing the main entities around which information is organized.

Some objects are provided by the system and they cannot be removed or structurally altered. By default, these system objects are visually represented as hexagons and ensure that core Neostella functionality remains intact.

Other objects are created by admins. These custom objects are initially represented as pyramids and extend the system’s data model to meet firm-specific needs. While admins can add fields and relationships to custom objects, system-required fields — such as the object name or API identifier — cannot be removed.

Neostella includes foundational system objects such as Project and Organization, while common examples of custom or extended objects include cases, clients, documents, and tasks.

• Fields

Fields = the atomic data points stored within an object.

Fields define the specific attributes of an object. Each field represents a data element that is materialized as part of a record, capturing the actual values that describe that record.

Fields can be either system fields or custom fields. Some fields are provided by the system and are required for core platform functionality. These system fields — such as Project Name or Stage — cannot be removed or restricted, as they ensure consistent behavior across the platform.

Other fields are created by admins to support firm-specific needs. These custom fields extend the data model and can be configured, grouped, reused, and, where applicable, limited through forms and context rules.

Fields are intentionally flexible. They can belong to object types, subtypes, or field groups, and in some cases span multiple levels at once. This design allows admins to reuse field definitions and maintain consistency across the data model.

For example, a case object may include fields for status, assigned lawyer, start date, and end date. Each of these fields contributes to how cases are displayed, filtered, and processed throughout Neostella.

• Relationships

Relationships = the defined links that connect objects across the data model.

Relationships define how objects are connected to one another. Without relationships, data would exist in isolation.

Neostella supports common relationship patterns such as one-to-many, many-to-many, and one-to-one connections, allowing the system to reflect real-world interactions of clients linked to multiple cases.

Unlike systems that only group or display information together at the interface level, Neostella defines relationships at the data level. This means records are truly connected and can be reused, navigated, and referenced across the platform — not just within a single screen or workflow.

By defining relationships upstream, Neostella ensures connected data remains consistent and available everywhere it is needed.