The GxP App Building Basics article explains
I interpret this as recommending any GxP data must be stored in a Table record, but understand this isnt the case, and its fine in some circumstances to store GxP data only in the Completion Table as it meets the DI requirements. Otherwise this would mean creating Tables even for very simple GxP apps if they record data. Can anyone clarify the recommendation?
Hi Dodd, great question and thank you for highlighting this. I believe we need to edit the support page to be much clearer.
What we are recommending is that you use Tables to represent tangible production artefacts, ie thing that exist on the shop floor such as batches, work/process orders, equipment, materials, etc. This is true to any manufacturing environment not only in GxP. Once you have a table of an artefact, Batches for example, then the system will automatically track the history related to table in the table audit log, which is viewable with the Record History widget.
Let take an example. You have a batch “B-001” that you have recorded in the Batches table. The record ID (Table ID) is of course “B-001” and it has values in the table columns such as status, operation, expiry date, etc. Every change that is made to this records, and its values, is recorded in the table audit log. When you for example change the status, let’s say from “In Process” to “In Review”, the table audit log will show that.
Now in addition the table audit log also links to any completion record that was posted when the table was changed. So if you have a trigger that changes a record’s value and then also either completes the app or performs an “App.SaveAllData” then the you will be able to see that in the Record History widget.
So the best practice is to use tables to track the status of production artefacts and always record a completion when you change a table record value. Using this method you can have Tulip track complete history records in a compliant manner.
Also remember that you can add columns to the table to store important values that may be used in app trigger logic. In the batch example that would be for example a critical parameter (CPPs or CQA) that are used to determine batch disposition, quality status, etc. These values will then be available in the record and will be tracked in the table audit log and completion record for a fully compliant history record.
I hope this helps?
Thanks
Thanks for responding Gilad, yes that clears it up and makes sense. One related quick question, will the ability to save signatures into Tables be coming any time soon? I wondered perhaps if this may be part of the eSig widget that’s in the pipeline?
Dodd
Hey @Dodd,
There is work in-flight with a custom widget to allow exactly this. User can sign in the widget and it can be stored to a table.
In the development process for this widget we found a bug in the platform that is being addressed in an upcoming release. This change is minor but it the work hasn’t been completed yet, so I can’t commit to a release date for that fix, or the widget that is blocked by it.
Its coming 
Pete