I would like to point out a bug - or misfeature at best! - regarding the Last Updated (person/time stamp) column type. I use this column (on subitems) to track which warehouse staff has picked a product for an order (the parent item). Since we have run into the 10,000 item limit on the Picking board, I needed to figure out a system to move older items to another board (rather than archive, in order to maintain searchability).
An initial idea was to duplicate the board. However, I found that when I duplicate a board, all of the Last Updated columns have updated to me!
Instead I set up an automation to ‘move’ the items individually to another board -based on date arriving, and found when I move the item, the Last Updated field is preserved correctly.
Why would the duplicate board function behave differently than the move function? Can we agree that they should not update to me? Since I am not updating anything, but just duplicating the board?
I think this has to do that when duplicating items (or a complete board) the duplicated items are NEW, hence they get an update date of now and the person set to the person that created the item (YOU).
Moving an item is completely different. An existing item just get moved to a different board and therefore the last updated timestamp is retained (the item is neither NEW nor UPDATED).
Yes that makes sense. I just wish there were a more graceful way to set a person field to current-user without requiring a manual field change by the user. So Last Updated is the best I’ve got until some future formula wizardry makes it possible.
The date-based move automation works fine for now, even if an archive of an archive of an archive makes me wince. In any case, the new columnstore infrastructure will make my grumblings moot.
In the duplicated board, the Last Updated columns should ideally retain their original values, as you’re not actively updating the items themselves. This behavior may be a result of how the duplication process is implemented in the platform you’re using.
When you move items individually to another board, the Last Updated field is preserved correctly, which is the expected behavior. This suggests that the move function handles the Last Updated field differently than the duplicate function.
It might be worth reaching out to the platform’s support team to report this behavior as a potential bug or inconsistency. They may be able to provide more insight into why this is happening and whether it can be addressed in a future update.