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
Waking the sleeping dog ???
As the username is the only value to identify a user, I would not change that pattern.
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.
My clients typically sync their users from active directory. This way, storing the username as an audit field is also save.
I agree, no reason to make things more complicated than they should be. But unfortunately we don't always get to make the final decision. Humor me and lets go down this path with the idea that the product owner is determined to have the ability to change a user name.
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.
Also Appian does give us a nice UUID for the user object. Which when I saw this made me think it could be an easy swap from username to uuid. The problem their is that as far as I can tell, there is no way to convert from UUID to users.
Is it safe? When the change occurs are you able to even know about it? For example a common use case could be someone's user name is based on their real name (first.last) and then they get married and change their legal last name. When AD makes the change now all the audit fields in your system have usernames for a user that doesn't even exist anymore. Furthermore you have no way to link them back together.
Again maybe (hopefully) I am missing something with the approach.
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.
This is an interesting conversation, but do we ask the right question here? If our client decides to rename user accounts, they will loose track of that users activity in many places. That is at least my assumption. Now, why do I need to somehow try to mitigate this issue in Appian?
I understand that there are situations in which we might have to take care of this. I never had a client asking for this.
There is a function in the people functions plug-in that allows you to get the username given the UUID.
That being said, I agree with others that this is typically a rare enough event that it usually isn't worth explicitly planning for. Plus, if your changes occur due to active directory changes, wouldn't you end up with a new user and having the old user deactivated? If anything that seems like more of a problem, and you might need to think about how to identify whether a user has been changed or not in the active directory sync.