How refiroo protects data
One set of rules applies on every path into refiroo. Browser edits, API calls and bulk loads meet the same model validation and permission checks. See What refiroo is for how these checks support shared reference data.
Values keep their types and rules
Section titled “Values keep their types and rules”A number stays a number, a date stays a date and a yes/no field stays distinct from text. The model can require a field, give it a default, make it read-only, limit a number’s range or require at least one of several fields.
A unique field value cannot be assigned to another record in the same workspace. A separate relationship rule can allow only one counting related record beneath each ancestor of a chosen type; this is how a model can limit one active representation per owner and group. A required field cannot be emptied. A declared validity period must end after it starts. Correct the reported value, or ask a model administrator if the rule itself needs to change. See Records and Types, attributes and relations.
Connections are checked too
Section titled “Connections are checked too”The model decides which record types can connect, whether a connection is required and how many are allowed. A parent must be a permitted parent in the same application and workspace. A record cannot become its own ancestor.
The parent link is maintained with the record’s position. Move the record to change its parent; ordinary relationship controls cannot alter that link. See Relationships and Hierarchies.
A save cannot silently overwrite newer work
Section titled “A save cannot silently overwrite newer work”Changes carry the version the editor read. If someone else saved a newer version, refiroo refuses the stale save and keeps the attempted input available for review. Read the current information and decide how to apply the intended correction.
A change set also checks for competing live changes when published. Unrelated live edits survive, but a conflicting change publishes nothing. Validation before publication is useful; it does not reserve values or guarantee that Live stays unchanged afterwards. See Change sets.
Review changes with wider effects
Section titled “Review changes with wider effects”Deleting a record first shows the impact: children, records it owns and relationships it would remove. Independent related records are disconnected rather than deleted. Review this preview before confirming.
Bulk changes and file loads offer previews showing what can be applied and what is refused. Their result depends on the chosen operation: publishing a change set is all-or-nothing, while a bulk job may apply independent items and refuse others. Cancellation cannot undo chunks an independent job already saved. Review the result rather than assuming every row succeeded. See Changing many records and Imports and exports.
History makes changes accountable
Section titled “History makes changes accountable”Record history names who changed what and when, including the person or client behind a background job. Publication changes name their publication. Older entries without attribution say Before sign-in; some operations did not record the previous value. History is evidence of changes, not a substitute for a complete backup. See History and Security, audit and privacy.
A limit is not an incomplete answer
Section titled “A limit is not an incomplete answer”Long collections are read in pages so people can continue through the complete matching list. A page size does not limit the whole dataset. Bulk selections and file loads have separate operation limits; exceeding one calls for a smaller operation, not an assumption that omitted records succeeded. See Lists, search and filters and Jobs and limits.
Validation checks the rules the model declares. It cannot decide whether a real-world name or code is correct, or whether a workbook’s matching column identifies the right record. Review proposed matches, omissions and losses before confirming a load or transfer. See Workbook onboarding and Copying and moving.