schema – forms overview – Neostella Support Center

Forms is the feature through which data becomes actionable.

This article is intended for admins responsible for configuring Forms. While the Data workspace defines the structure of information—objects, fields, relationships, and types— Forms define how that information is experienced by users like case managers, intake specialists or paralegals. They control what users see, what they can edit, and how information is captured at each stage of a case or workflow.

Forms do not create data. Instead, they project the data model into a user-facing interface, ensuring information is collected consistently and according to the rules defined by admins.

the role of forms in the platform

Forms act as the bridge between:

The data architecture configured by admins, and
The daily work performed by end users.

Every interaction a user has with structured data, such as entering values, reviewing case details, updating records, takes place through a form. Because of this, Forms are one of the most essential schema tools on Neostella.

In short, Forms translate technical data definitions into clear, guided experiences that users can understand and act on.

what forms are designed to do

Forms are designed to support the full lifecycle of a record by:

Capturing Structured Information
Forms allow users to enter data in a standardized format, using predefined field types, validations, and relationships.
Documenting Case Progress
Forms provide a consistent way to document important milestones, incidents, complaints, or updates as a case evolves.
Presenting Data Clearly
Forms define how information is displayed, grouped, and ordered, making complex data easier to understand and manage.
Enforcing Consistency and Control
By relying on the Data model, Forms ensure that users interact with information in a controlled and predictable way.

forms and the data model

Forms are entirely dependent on the Data workspace.

Every field displayed in a form originates from an Object.
Field behavior (Required, Hidden, Locked, or Restricted by Type) is enforced dynamically.
Relationships determine what related records can be viewed or selected.

As a result:

Changes made in Data directly affect how Forms behave.

A well-designed Form starts with a well-designed data model.

how forms work in practice

Forms work by layering presentation and behavior on top of the data model, without altering the underlying structure.

Admins begin by selecting an Object. This Object defines:

What type of record the form represents.
Which fields are available.
Which relationships can be referenced.

From there, the form determines:

Which fields are shown or hidden.
How fields are grouped into sections.
The order in which information appears.
Which fields users can edit and under what conditions.

As records move through different stages, Forms ensure that users see only what is relevant at that moment — while still relying on the same shared data definitions.

Due to Forms reusing the same data model:

The same field behaves consistently across Forms.
Reporting, workflows, and automation remain aligned.
Data entered through Forms is immediately usable elsewhere in the platform.

In simple terms, Data defines what exists; Forms define how users interact with it.

how forms are structured

The Forms tool is organized into two main areas:

Form Dashboard
The Form Dashboard provides a centralized view of all Forms in the system. From here, admins can review existing Forms, locate them using filters, and create new ones.
Form Editor
The Form Editor is where Forms are built and refined. It controls layout, field placement, visibility rules, and overall behavior.