Database User Schema

To start, what/how are you saving into the LastModified columns that is generating a hash, vs a username?

Currently we are saving the UUID from the Appian User Object. We see were we could change that to the User Name, for example: jsmith. But this still doesn't allow us to join the usr table for useful User info, for example in an ETL report we wanted to say this row was edited by John Smith.

My few notes:

Logging user interaction with username instead of the UUID should allow for easier mapping - I really haven't worked with Appian's user UUID at all in my experience however.  Also, we typically use our own "UUID" as the employee ID in our HR systems, which allows consistency across both environments, and employee name changes. 

You could script a process to parse all user accounts, create a new table which contains username and UUID, plug in each field with the user account and user(ri!user,"uuid"), then you will have a mapping table.  

The primary data source "usr" table you are referencing does have a user_uuid column, but in all of my environments, it is completely empty.  I can't speak to it's designed use and likely would not receive much support on it being within the primary/Appian DS..

For similar reasons this is why we also maintain a DB table with user accounts and their metadata in our business data source, we update this daily as we refresh our user accounts - has been immensely helpful, such as for joining to via employee ID or account in reporting views.

My few notes:

Logging user interaction with username instead of the UUID should allow for easier mapping - I really haven't worked with Appian's user UUID at all in my experience however.  Also, we typically use our own "UUID" as the employee ID in our HR systems, which allows consistency across both environments, and employee name changes. 

You could script a process to parse all user accounts, create a new table which contains username and UUID, plug in each field with the user account and user(ri!user,"uuid"), then you will have a mapping table.  

The primary data source "usr" table you are referencing does have a user_uuid column, but in all of my environments, it is completely empty.  I can't speak to it's designed use and likely would not receive much support on it being within the primary/Appian DS..

For similar reasons this is why we also maintain a DB table with user accounts and their metadata in our business data source, we update this daily as we refresh our user accounts - has been immensely helpful, such as for joining to via employee ID or account in reporting views.