Common object and record problems reported by makers, with the cause and the fix for each.
Overview
Common object and record problems reported by makers, with the cause and the fix for each.
Each section below is a real scenario: what you see, why it happens, and the fix.
My record fails to save with a "Non Empty Validations... add additionalProperties" error
What's happening: A workflow step that creates a record in a Storage object fails on every run. The error names one of the object's own fields and reads something like invalid; add additionalProperties <name> — the record is never created, and anything downstream that depends on it stays blocked.
Why: An Object field on a Storage object has its own set of sub-fields, declared separately from the object's top-level fields — you define them the same way you define top-level fields, just nested under the parent field. An Object field only accepts the sub-fields that have actually been declared for it; anything else in the payload is rejected, even though the object's other fields are fine. If the data your workflow is writing includes a sub-property that was never added to that specific Object field's own schema — for example, an upstream source starts sending an extra detail your object doesn't know about yet — record creation fails, and the error names the exact sub-property that's missing.
Fix:
Open the object and go to its Schema tab.
Click Add fields → Enter manually.
Add a new field for each missing sub-property named in the error, matching its type (text, number, and so on).
Nest each new field under the parent Object field named in the error, so it becomes one of that field's sub-fields rather than a new top-level field — the Schema tab shows nested fields indented under their parent.
Save to apply the schema change.
How to verify: Re-run the workflow step that creates the record and confirm it completes without the validation error, then open the object's records and confirm the new record was created with the previously-missing values populated.
Still stuck? See objects/screens/object-schema.md for adding and nesting fields, and built-in-nodes/screens/storage.md for the Storage node's create operation, or contact support@unifyapps.com.
Key takeaway
An Object field's own sub-fields are a separate, stricter schema from the object's top-level fields — declaring the parent field doesn't make it accept arbitrary extra properties nested inside it. When a create or update fails naming one nested property as invalid, add that property under the named parent field rather than assuming the object's overall schema is the problem.
I'm an admin with full Object Manager permissions, but I can't add a record to this object
What's happening: A user holds every Object Manager permission at the role level — View, Create, Edit, Delete, and Share — yet trying to add a record to one particular custom object fails. The user isn't blocked from objects in general, only from this one.
Why: Role-level permissions and access to an individual object are two separate layers. A role's Object Manager permissions control what you're generally allowed to do with objects — but that doesn't automatically give you access to any specific object's data. To create, edit, or view records on a particular custom object, that object must also be shared with you or your team, using the Share action on the object's row. The one exception is being a member of an administrator group that already has all records shared with it — those members reach every object without needing individual sharing.
Fix:
Ask someone who already has access to the object (or another admin) to open the object in the objects manager and use its Share action.
Add your user or team to the share list and assign them a role for the object that includes the permissions you need — at least View and Create (add Edit and Delete too if your work requires them).
Save the sharing settings.
How to verify: Open the object's records and try adding a new record — it should save without an access error.
Still stuck? See objects/screens/objects-manager.md for how object-level sharing works, or scenarios/objects/object-records-not-visible-despite-access.md if the object opens fine but its records list still looks empty afterward — that's a separate, record-level access setting. Otherwise contact support@unifyapps.com.
Key takeaway
Don't assume broad role permissions (like full Object Manager access) mean you can act on every object — each custom object also needs to be explicitly shared with you or your team before you can view or change its records, unless you belong to an administrator group that already has all records shared with it.
I have object access and the right role, but the records list is still empty
What's happening: The user can open the object — its schema and structure are visible — but no records show up in the table, even though they have object-level access and the role that's supposed to grant them. Other users, typically on one particular team, can see the same records without any issue.
Why: Object-level access and record-level sharing are two separate layers. By default, an object's records follow per-record sharing: you only see the rows that were shared with you or your team, so opening the object successfully doesn't guarantee you'll see any of its data. In this case, the records had been shared only with a specific team (not the affected user's team), so the object's records list stayed empty for everyone outside that team — turning on Enable Global Access for the object made the records visible to everyone immediately, since Global Access allows default sharing of records across all workspaces/users instead of relying on per-record sharing.
Fix:
Go to the object and open its Settings tab, then Access Control.
Toggle on Enable Global Access, then click Save on the Settings tab to apply the change.
If Global Access isn't appropriate for this object (for example, the data is sensitive), instead use the Share action on the individual records, or on the object, to add the specific users or teams who need to see them.
How to verify: Have the affected user refresh the records page and confirm the records are now visible. Confirm users from other teams/workspaces can see them too, and that a newly created record is also visible by default.
Still stuck? See objects/screens/object-settings.md (Access Control section) and objects/screens/records.md for record-level sharing, or scenarios/objects/object-access-permissions-not-granting-record-access.md if the object itself isn't accessible at all. Otherwise contact support@unifyapps.com.
Key takeaway
Object access and record visibility are enforced separately: having permission to open an object and the right role doesn't mean you'll see its records — those are governed by per-record sharing unless Enable Global Access is turned on. Global Access is off by default and needs the Settings tab's Save action to take effect, but it's a broad setting (it shares records across all workspaces/users), so weigh it against manual per-record or per-team sharing for anything sensitive.
I turned on reporting for an object, but records that existed before that don't show up in reports
What's happening: After turning on Enable Reporting for an object that already had records, reporting dashboards and analytics for that object either show no data or only show a partial dataset — records created before reporting was enabled are missing.
Why: Enabling Enable Reporting only starts sending an object's records into the platform's reporting/analytics data store from that point forward. It does not automatically go back and sync records that already existed in the object before reporting was turned on, so any data created earlier is simply absent from reports and dashboards until it's synced separately.
Fix:
Confirm Enable Reporting is turned on for the object (Object › Settings › Monitoring & Logging).
Contact support@unifyapps.com and request a manual sync of the object's existing records into reporting. This pushes the object's pre-existing records into the reporting store so they become available for reports and dashboards alongside records created after reporting was enabled. Depending on how many records the object has, this sync can take some time to complete.
How to verify: Open the reporting dashboards/analytics for the object and confirm records created before reporting was enabled are now visible, that data counts and metrics reflect the complete dataset, and that report generation includes the older records.
Still stuck? See objects/screens/object-settings.md (Monitoring & Logging section) for what Enable Reporting does, or contact support@unifyapps.com.
Key takeaway
Turning on Enable Reporting doesn't backfill records that already existed in the object — only records created after you enable it are synced automatically. If you know an object will need reporting, turn it on before you start adding records; if you enable it later on an object that already has data, plan for a manual sync (via support) to bring the older records into reporting.