I want companies to be able to propose updates to their own data in the Zentral/Kerndaten database, but all changes should only be applied after I review and approve them.
Approach 1: Separate Staging Database
Use the existing Zentral/Unternehmenseingabe database as a staging area for proposed changes
Companies submit their updates to this database
After review, I manually transfer approved data from Unternehmenseingabe to Kerndaten
Pros: Clear separation between proposed and approved data
Cons: Manual transfer process required; need to track which fields were changed; two way sync required
Approach 2: Draft Fields Within Kerndaten
Add draft fields (e.g., “Name (Draft)”, “Address (Draft)”) directly in the Kerndaten database
Add a review status field to track approval state
Companies only edit draft fields; I review and copy approved changes to the main fields
Pros: All data stays in one place; easier to compare proposed vs. current values
Cons: Doubles the number of fields in the database; more complex field management
Question
Which approach is better for managing this review-and-approve workflow in Fibery? Are there other recommended patterns or features I should consider?
And: Kerndaten has some one-to-one and one-to-many relations (f.e. social Media Accounts, Sales Volume, coworkers). (how) Can I provide my customers a way to add new entities with help of the shared Zentral/Kerndaten entity? Is it a case for a Access Template with usung the option “Configure who can create SocialMediaAccounts on the DB Level”? Since I dont have Pro, I can not test it.
And Nr. 2: I have several Entity Views for Zentral/Kerndaten. Can I configure to only share chosen views and not all at once. I only know, that with a public link only the first one will be shared. But how does it look like with entities that I shared with specific persons? Currently they can see all views.
Your intuition on the pros and cons is indeed true.
I would go for the first option. Note that you actually don’t need to make the changes manually though, you can set up automations that populate the data when the change is approved.
I wouldn’t impliment two way sync either, just one way, then any new change is a new “Change Request” Entity.
You can either have a full database mirror, or create a new change request database per field that you want the users to be able to update. Then you add buttons “Request Edit {field}” buttons in the entity layout. A bit more maintainace, but might be good if people usually only edit one field at a time. Not sure what your exact workflow is.
“Create” is not configurable on the access template (yet), but on the database access control. Which you do not need pro for. So you can give them create access to the database, and make the relation required.
True, there’s a feature coming soon to be able to dynamically hide certain entity views, but this will be a pro feature.
Hope this helps! Feel free to ask if something doesn’t make sense.
Or actually!! Maybe a better option! Then you don’t need separate databases.
A self relation to same database.
So then each revision is another version of the same entity, related to the past version of it.
Then the right version is the latest version which is in the “Approved” state. You can add a formula to check for this.
But in order to preserve the relations to other things you probably will still need two databases, one main one, and one that contains all the fields, that will have the version control.
Then you can pull the data from the most recent approved field version into the main database. This is getting a bit confusing, and the UX might be less good, depending on what you need.
The tricky UX is that you can’t set “Default Values” on forms or button presses. Meaning when they go to update, they don’t see the previous values.
You can make some smart automations there if they leave the value empty, it will autofill the last used value, but this would need to be explained to the end user.