Working with Game Data
Once the schema is in place, the next step is to work with the records created from it.
In PlayServ Backoffice, the Data view is where you create, edit, and manage actual records based on the schema defined for the project. If the schema defines the structure, the data view is where that structure is filled with real values.
Schema and data work together
Schema and data are closely connected, but they serve different roles.
Schema defines what can exist:
- which objects are available
- which fields they contain
- which values those fields can store
- how objects relate to one another
Data contains the actual records created from that structure.
This means the data view always depends on the schema. The fields available in a record, the type of values they accept, and the overall shape of the record are all determined by the schema first.
Schema defines the structure. Data stores the actual values entered according to that structure.
What a data record is
A data record is one actual instance of a schema object.
For example:
- if the schema defines a shop item structure, a data record is one specific shop item
- if the schema defines a player configuration object, a data record is one saved configuration based on that structure
- if the schema defines a global settings object, the data view contains the actual settings values stored for it
A simple distinction helps: schema defines the shape, a data record contains the values.
Open the Data view
To work with records, switch from Schema to Data for the object you want to manage.
The Data view shows the records created for that object and provides the entry point for adding new ones.
In most cases, this view becomes the main working area after the schema itself has already been set up.
If the record structure feels confusing in the Data view, the problem is often in the schema design rather than in the record editor itself.
Create a record
To add a new record, use Create New in the Data view.
The record form is generated from the schema, which means:
- the available fields come from the object definition
- field types follow the schema configuration
- constraints and required rules are applied here
- array fields behave as lists
- type fields appear as embedded structures
- reference fields point to existing objects
This is one of the main advantages of schema-driven data management: once the structure is defined correctly, record creation follows that structure automatically.
You do not design the record form separately. The form is derived from the schema.
Edit an existing record
Existing records can be opened and updated in the same data flow.
When editing a record, the interface continues to follow the schema definition. This means:
- field types remain consistent
- required values stay required
- constraints still apply
- table display and field layout continue to reflect the schema
This helps keep data records aligned with the structure originally defined in the schema editor.
How field types affect data
The way a record behaves in the Data view depends heavily on the field types used in the schema.
Primitive fields accept direct values such as text, numbers, or boolean values.
Enum fields restrict the value to one of the allowed options defined in the enum.
Type fields embed structured nested data directly inside the current record.
Reference fields point to other objects instead of storing the whole structure inside the current record.
Array fields store multiple values instead of one.
The data experience is a direct result of schema decisions. Clean schema design usually leads to simpler and clearer records.
How Singleton changes the Data view
If a schema object is marked as Singleton, the Data view behaves differently.
A regular object can have multiple records. A Singleton can have only one.
This makes Singleton useful for:
- global configuration
- shared settings
- one-time project-wide records
When deciding whether to use Singleton, the key question is simple: should this object exist once, or should it exist as a list of records?
Import records from JSON or CSV
If multiple records need to be added at once, the Data view can also be used for bulk import.
Instead of creating each record manually, you can prepare the data in JSON or CSV format and import it into the selected object. This is useful when the project already has prepared content, configuration values, or other structured records that should be added in batches.
Imported data still depends on the schema. This means the file must match the structure already defined for the object:
- field names should match the schema
- values must follow the correct field types
- enum values must use allowed options
- required fields must be present
- arrays, nested objects, and references must follow the expected structure
Import does not replace the schema. It fills the existing schema with records.
When to use JSON
Use JSON when the data includes more structure, such as nested objects, arrays, or more complex record shapes.
JSON is usually the better fit when the imported data needs to reflect the full structure of the schema more precisely.
When to use CSV
Use CSV when the data is flatter and easier to represent in rows and columns.
CSV is usually the better fit for simple tabular imports where each row represents one record and the values do not depend heavily on nested structure.
If the object contains nested Type fields or arrays, JSON is usually easier to work with than CSV.
Why data depends on schema quality
The quality of the Data view depends directly on the quality of the schema.
A clear schema makes records easier to create and maintain. A confusing schema makes the data harder to work with, even if the interface itself is functioning correctly.
Good schema decisions usually lead to:
- clearer record forms
- fewer invalid values
- easier navigation
- better reuse of structure
- more predictable data editing
This is why schema design should be treated as the foundation of data management, not as a separate concern.
Common things to check
When working with data, it helps to check the following:
- whether the object structure is clear enough for record creation
- whether required fields are really necessary
- whether array fields are used only where multiple values are needed
- whether references point to the right standalone objects
- whether a singleton object is really meant to exist only once
A data model can be technically valid and still be difficult to use. Good schema design should make record management easier, not just possible.
Next step
Once records can be created and edited successfully, the next step is to review how changes are saved, tracked, and published.
Continue with Publishing and Reviewing Changes.