Publishing and Reviewing Changes
As the project evolves, schema and data changes need to be saved, reviewed, and then published.
In PlayServ Backoffice, publishing is the step that turns draft changes into active project changes. This makes the review stage important, because it gives the team a chance to check what exactly is about to change before those updates are applied.
Draft changes and published changes
When you edit schema objects or data records, those updates do not become active immediately.
Instead, they first exist as draft changes. This allows the team to continue shaping the update before publishing it.
A published change is a change that has already been confirmed and applied.
Draft changes are still being prepared. Published changes are already part of the active project state.
This distinction is important because it separates editing from release. It gives teams room to review changes before they affect the live working version of the project.
Why the review step matters
Reviewing changes is not just a final click before publishing. It is the point where the team confirms that the update is complete, correct, and safe to apply.
This is especially important when the changes affect:
- object structure
- field definitions
- enum values
- inheritance
- references between objects
- existing records in the Data view
Even a small change in schema can have a broader effect on how data is created and managed later.
The more central the object is in the schema, the more carefully its changes should be reviewed before publishing.
Review pending changes
Before publishing, review the pending updates in the Backoffice.
The goal of this step is to understand:
- what changed
- which objects were affected
- whether the change matches the intended update
- whether any dependent structures may also be affected
This is where the team checks that the result matches the original intention, not just that the edit was saved successfully.
Understand the diff
The diff view helps show how the current draft differs from the published state.
Depending on the type of change, the diff may include:
- added fields
- removed fields
- renamed values
- updated constraints
- changed inheritance
- modified enum entries
- record changes in data
The purpose of the diff is to make the change visible before it is applied.
A diff is most useful when the team can quickly understand not only what changed, but also what that change may affect.
For example, changing a field name is not the same as changing a field type. Updating an enum list is not the same as removing a value already used elsewhere. The review step helps catch that difference.
Publish changes
Once the review is complete, the next step is to publish.
Publishing confirms that the current draft should become active.
After publishing:
- the reviewed changes become part of the active project state
- the project moves forward with the updated schema or data
- future edits start from this new published version
Publishing should be treated as a deliberate action, not just the last step in editing. Once changes are active, the rest of the team will work from that updated state.
Review schema changes carefully
Schema changes often need more attention than data-only updates.
This is because schema defines the structure that records depend on. A change in schema may affect:
- which fields are available in the Data view
- which values are valid
- how nested objects are stored
- how references connect between objects
- whether records remain easy to edit and understand
Examples of schema changes that deserve careful review:
- changing a field type
- switching between Type and Reference
- updating enum values
- changing Parent Type
- enabling Singleton
- tightening constraints on an existing field
If a schema change affects how records are shaped, check the Data view after publishing to confirm that the result still behaves as expected.
Review data changes carefully
Data changes should also be reviewed, especially when they affect shared or important records.
This is particularly true for:
- global configuration records
- singleton objects
- shared balancing values
- records referenced by other objects
A record update may look small in isolation but still have broad impact if other parts of the project depend on it.
Common things to check before publishing
Before publishing, it helps to confirm the following:
- the intended objects were changed
- no unintended fields or values were modified
- enum updates still make sense across the schema
- references still point to the correct objects
- singleton objects still behave as intended
- constraints are not stricter than necessary
- record updates match the expected final values
A change can be technically valid and still be the wrong change. The review step is there to catch that before publishing.
After publishing
After the changes are published, treat the new version as the current working baseline.
At this point, it is useful to:
- reopen the updated schema object if the structure changed
- reopen the Data view if records were affected
- confirm that key objects still behave as expected
- verify that the resulting project state matches the reviewed diff
Publishing is not the end of validation. It is the point where validation should continue against the active state.
Why this workflow matters
A save-first, review-before-publish workflow makes collaboration safer and clearer.
It helps teams:
- avoid accidental releases of incomplete edits
- understand what changed before it becomes active
- review schema and data updates with more confidence
- keep the project state easier to track over time
This is especially valuable in projects where multiple people may be working on structure and content at the same time.
Next step
Once changes are being reviewed and published reliably, the next step is to continue working across the rest of the Backoffice with a stable schema and data workflow.
If needed, return to: