Okay, so what I think is going on…
You have some sort of registry of things currently recorded in a single worksheet within a single spreadsheet. Your app is attached to that single worksheet by a single table. You have two slices on top of that single table to differentiate two distinct subsets of data. Each of these data subsets has its own set of views and input choices. That table is and/or the slices are either explicitly configured to allow only updates and not adds or deletes, or the app is constructed in such way that users can only edit existing rows but have no means to add or delete rows.
Currently, updates to the table overwrite existing data, which leads to a loss of historical data. You want to maintain a record of the historical data as well, while also presenting a view of the current state of things.
I would suggest this model:
Users will never add, modify, or delete rows of the first table. Users will only be able to view the first table. The first table is strictly for reference.
All user changes are recorded as new rows in a second table. This table will provide the historical record.
Workflow rules within your app will propagate the changes described by the rows added to the second table to the current status recorded in the first table.
For instance, if the user repaired something that was previously broken, the row in the second table would note the thing, that it was repaired, and the timestamp. A workflow would see the new row added to the second table, would locate the row in the first table that corresponds to the thing, would adjust the thing’s current status to reflect the repair (e.g., set it to Repaired or In Service), and would update the thing’s timestamp.