When saving data on a form, I understand that the traditional way is to create a save button and have this data saved to a database, and with every instance of the data saved, a new entry with a new ID will appear in the database.
With auto binding, it appears that if the data within the form is updated with new text, the data is saved immediately, but a new entry is not created as with the above method. Instead, the existing entry with its ID is simply updated.
Is there a way to have a new entry with new ID with every update to a form with auto binding enabled, so the admin can see a record of updates each with their unique database IDs and creation time etc.
Yes, instead of using autobinding you can use “When an input is changed” by right-clicking on an input then “Start/Edit Workflow” and then creating a new thjng.
The app seems to automatically create a new thing whenever the user clicks ‘save’ or ‘submit’ when filling out the form (this is of course when autobinding is not enabled).
On my autobinding form, I can’t see ‘Start/Edit Workflow’ when I right click on the field. I’m trying to figure out how I can create a new thing for autobinding enabled forms so it captures the entirety of a form as a new thing when even one field has changed.
Your app doesn’t automatically do anything It has to be told from somewhere - there must be a workflow on the relevant buttons.
Are you using a template by any chance?
Autobinding is like an auto save for that record (think like google docs, you open it, edit it and it saves for you) - autobinding means any changes made to THAT record will be saved against THAT record.
If you want a new record to be saved when someone changes an input you need to have autobinding unchecked and just use a workflow on a ‘save’ button OR if you want the user not to have to use a save button you need to make a workflow on every single element. If doing this, I’d suggest creating a custom workflow to save the record and on each element have a workflow ‘when X input changed’ → step 1. trigger Y custom workflow.
You’re right, for the form with a save button, my workflow starts with ‘create new thing’ so I suppose any hit of the save button, irrespective of whether there’s been any change in the content, the app will create a new record in the database.
I’m using the Canvas template.
I’ve been using the traditional workflow on a save button for quite a few forms now, but want to explore more about how create a new thing when ever there is a change to the field using autobinding works. Perhaps this might create a better experience for users.
I don’t mind applying it to each field, it will be time consuming, but that’s okay!
Can you help me setting this up autobinding?
If I go to Workflow, and apply this rule to test out on a normal text field, I’m guessing I would still go to ‘create new thing…’ and then under the dialog box that appears, use the field at the bottom that says ‘only when…’ to program it to trigger on a change? I’ve looked into this but can’t seem to find an option to only run when the contents were to change
Do you want to create a new form and then have autobinding while the users finishes completing the form? In this case you would need to create a new thing first so that there is something for the inputs to bind to. So whatever is your way of creating a new form, add another step to create a new thing, then display that thing in the form. Then autobinding will work.
It makes no sense to have the form display data for a record, have autobinding turned on AND want to create new records when an input is changed.
My objective is to have users change data within a field, not have to worry about clicking save, but allow the changes to be recorded as different entries in the database so there is a change history if they needed one.
In the current way AB works, no one knows what they entered in originally and because my fields are going to be in frequent change, keeping a track of the updated data will be an important feature.
I display the data in the fields for that record within the form, so when users return to it weeks or months later they edit that record and save it again. Using the tradition save button creates a new record which is how I need it to work. Resetting the fields on a form won’t work with my use case because users need to go back to see what they entered initially, and then make smaller tweaks to that text.
So if you want users to be able to continually update the SAME form, but you also want to enable a type of version control?
I would probably not create a new instance of the form when something is changed, I would potentially just create a new datatype for change logs. And have a workflow that creates a new change log when an input is changed. For this you could use a backend workflow ‘database trigger’ and then whenever a change is made to the form datatype it would trigger a ‘create new change log’ with date and changes made.
So in your front end you would autobind the input elements on the form, and then in the backend have one database trigger workflow.
This would be a much cleaner set up in terms of workflows AND database.
Correct, the whole point of saving different versions of the data when a user changes the content is so they can go back and see what they entered on X date or time.
I’m not familiar with change logs, how do they work and how would I use it to reproduce the data from a previous version, or display it to the user? Eventually I will build a feature that will display the data of previous versions to the user for them to view. This might be possible with change logs but I’m not sure how they correspond with the database itself or keep track of those values that have been changed.
A change log is just a generic term for anything that records changes. You set this up as a datatype with whatever relevant fields you need. You can then display this data anyway you want in your app just like any other data in your database.
Yep, the trigger event you found in the reference guide is what I was referring to
It has to be told from somewhere - there must be a workflow on the relevant buttons.