If you want to offer users the ability to delete records in your application, but don't want them to be actually permanently deleted, you can implement a "soft deletion" feature (kind of like dragging files to the trash, but not emptying it yet).
To implement this, add a Yes/No field to the object called something like "Deleted?" and make the default value "No". (If you have existing records, you may want to use Knack Batch Update feature to mark all of them as "No".)
Then, when you build your tables or lists to show your records, instead of using the Knack feature to insert a Delete link (which would permanently delete the record), add an Edit form in a modal window. Remove all the fields that Knack adds to the form by default - this is really just a message window, but the purpose is to use the Record Rules (see below). You could add a Title field to say something like "Are you sure you want to delete?". You could also include some identifying fields on this form, such as the name of the record - you can set these to "Display the field value without a form input" so they don't show as editable:
On this "Edit" form, go to Form Rules / Record Rules. Create a rule to set the "Deleted?" field to "Yes", like this:
Finally, in your tables and lists showing these records, go to the Data Source page, and in the Data section, add a rule to show only records where "Deleted?" is "No".
Now, users will have a normal experience of deleting a record and it will no longer show up for them. But, the records still exist in the database. You could provide a "Trash Can" type of interface for users to "un-delete" these records, or you could make that option available only to admins.
So, once you have done this and "deleted" the record, how do I get the record back? I thought I would still see it in the records, but just showing a "yes" in the deleted column. but, I can't find the record.
Yes thanks Eric - I have just discovered the Text Formula function. Previously when I clicked on it I was not getting the potential relationships to other field hence (possibly a small hiccup in the interface after doing certain actions in builder).
Actually it has happened a couple of times I must make a note of the when where and what to report it to Knack.
Your suggestion did give me on an idea of not allowing deletions in the main data input screens but allowing you to flag a record for deletion at a later time. This approach assure that nothing is deleted immediately but only after changing to a specific function elsewhere to be performed at days end or whenever they choose (once a week, once a month etc)
The one disadvantage I have realised though in using a TEXT FORMULA in the CHILD records to determine the status of the PARENT is that should the PARENT be deleted, the CHILD formula field will not function. I guess therefore it should be that when selection CHILD records for deletion they act upon the formula field which contains no data.
(Yes I just tested that, deleting the parent and the child record no longer has a delete status value.)
So it basically achieves the same as what I have done already in a sense which is filtering the child records to show only those that have no Customer Reference stored (disappears when the PARENT record is deleted because of the one-t0-many relationship link).
So essentially the deletion side of things I still am left with a 2 step process. 1 delete the debtor then 2 delete the CHILD records. Now to work out how to delete them en-masse rather than line by line.
The scenario you describe is what would happen if you actually deleted the parent record. In the case of the approach I describe above, the parent record isn't actually being deleted, only being marked as "deleted" but changing a field value.
You could easily create a Text Formula field in your child object (Transaction) which copies down the deletion status of the parent (Customer) (something like "{Customer.Deleted?}") Now, you can filter tables which show the child records in the same way as I describe above for the parent.
Yes a good idea unless the deleetion is relative to a one parent to many child scenario.
Unless I am mistaken there is no way of deleting the lot by deleting the parent.
Instead you end up with orphaned child records with no "key field" existing.
Yes you could select records with "key field" is blank but becomes a two step process.
I like your idea and it would be useable IF you could make the determination that the parent record was flagged for delete when viewing list of child records other than by blank key fields in them
ie Customer 123 Transaction (linked by 123) 12 on file with 123 in the Customer field
Deleting 123 leaves 12 transactions on file but with Customer field now blank as record 123 no longer exists