Hello Community,
It has been a standard for a while to store usernames in audit fields in Appian apps. A while back Appian added the ability for users to change their username.
I am just looking to see if this changed your approach for audit fields.
Discussion posts and replies are publicly visible
For this reason, and best data practice, we use an "Employee ID" value for any piece of data associated with a user account. This ID is essentially the HR identifier for all employees in the company, and will never change. Usernames that can change are not appropriate for identifying employees/users.
We load this into our Custom Field 1 on the user profile and in our MSSQL "Users" data - any views to retrieve audit data / history are joined from the application data's Employee ID value to the Users data for real-time account information.
I highly recommend synching Appian user profile data to your database, in a "Users" table, this is invaluable for reporting, etc - if anyone has not done so yet.
The additional 'Employee Id' Approach is a solid one with some drawbacks. For example you would then need to always get the employeeId before setting the audit field. Compared to the username where we just do a quick loggedinuser(), you are now hitting some DB table to grab the id. So a bit of a performance issue there. You negate that by using your customfield approach. But now you need to maintain the additional table and the custom field when a name change occurs. But if the customer is using active directory with a sync how are you even going to know the change happened to kick off a model to update all these attributes.
Yes the customField does negate the DB call, typically we will just grab this from the user profile with 3-4 ms performance:
user(ri!userIn, "customField1")
In my scenario, I work as a FTE in a single large environment, so we do not have the issue of recreating the wheel with each new client, and we do not sync with AD for the other reasons you mention in this thread. Instead we use data delivered via file to the server based on Employee ID for deactivations, activations and updates. This works great for control, but has more moving parts than a simple AD sync.
Otherwise unless the AD configuration has an identifier value other than the account name, if the account name (identifier) changes, there is no way programmatically to know for certain if this is a new account or an updated account.