I am implementing on LTS 10.6 and in a app step operators are registering various values for a probe standardization. The app completes and the data is recorded correctly, and can be accessed in the history widget for the entry.
It would appear to me that presentation of logged process data could use a bit of tweaking.
It seems that logged process data is presented in random order, and the width of label and data columns do not use the space provided. Data updated in a table record (last action, registered at and by) use plenty of space and appear to follow update sequence.
No so fun replying to one self, but I also noticed that if I write a table record with User ID (e.g. current app info logged in user completing the step) and the user ID is the same there this wont show up in the history widget. The “Registered by” in my example is simply not there. I assume that this is due to player logic seeing the same User ID and not performing any update to the table. Now I highlighted “Registered by” buy my entry “Last action” exhibit same behavior when e.g. repeated back to back.
This makes it a bit tricky to use the history widget as a tool to show the transaction history. Is there a way to force an update to the table to make it appear in the history widget?
Regards
Asger
Don’t want you to think you are talking to yourself I am asking the team internally a bit more about your questions here and will report back!
I also know @jmlowden@MarkStuttard use the record history widget, so tapping them here to see if they have any input while I also work on my side to provide some help.
There is currently no way to configure or customize the order of logged process data. Best practice is to minimize the amount of process data collected so it is as concise and clear as possible for the reviewer.
I would encourage you to log a Product Suggestion in Community - this is a great way to let us know how we can improve the Record History Widget.
I tested logging a User data type to a table and got the following result: is this different than what you are seeing?
There is no Player logic that would ignore a Data Manipulation → Store action to a Tulip Table. Make sure you are writing to the same record placeholder that you are viewing in the RHW.
You might also check your User data type. Here is the trigger I used:
Thanks for your reply. I don’t think many end users are fans of unstructured data presentation. Maybe IT engineers feel differently. Some sorting should always be applied. If not possible to configure then at least alphanumeric should be used.
I think your test is too simple. You update a blank field to a value. Obviously the system will record the change. Could I ask you to extend your test and try to update “Produced By” more than once and maybe have the transition to complete the app. Then just do it a few times and post the result here.
Is the issue with the “Registered By” an issue with Table Data or App Completion Data?
If table data, perhaps you could force it to appear by clearing the entry in one trigger and then repopuplating in in another.
I have also considered using another column in the table to aggregate pertinent record history information into a delimited string, so that it can be searchable in table queries, and maybe provide some more options for accessibility of that information when working with the data offline (e.g. CSV export).
I am asking the team internally a bit more about your questions here and will report back!
