The database that I maintain at the moment has a simple text field for “Order Notes” which is used for various miscellaneous notes that don’t fit into any of the other fields. It’s a bit of a “catch all” receptacle. 

 

A couple of problems have emerged recently. One is that staff have been relying on notes that have been written quite some time ago, treating it as “gospel” when in some cases it has been superseded. What I’d like to do is have an indication on the field of when the information was input. It wouldn’t be hard to add a timestamp that is changed when the field is updated. The drawback I see with that approach is every alteration, no matter how minor, updates the timestamp, so we could have a recent timestamp, but old information, just because someone tapped the spacebar in the field. 

 

What I’m thinking about is storing each iteration of the Notes text as a separate record in a related table. There would be still only be one notes field visible to the user, but the various versions could be checked through if required. 

 

It doesn’t seem too complicated to have a script trigger when the information in the Notes field is committed, that copies it into a new related record. Then some form of portal to allow users to quickly flick through the versions. 

 

But I have a nagging feeling that this is a bit of a bodged inelegant way to go about it - is there a more straightforward way of achieving this that I’m missing?

1 hour ago, Angus McKinnon said:

What I’m thinking about is storing each iteration of the Notes text as a separate record in a related table.

Yes!

Or show a portal of related notes, sorted descending of creation time.

You could use a global field for the note input. Then a button "Add Note" which would script the creation of the Note record.

Some people use a one row filtered portal to add a record. the relation has Allow Create enabled. The display portal hides the fields in the last portal row if Isempty (related::Id).

Bottom line: No big Notes field in the parent, at all.