Best way to store Audit Fields

Certified Lead Developer

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

Parents Reply Children
  • Certified Lead Developer
    in reply to Joshua F

    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.

  • Appian Employee
    in reply to Joshua F

    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.

  • In our environment (28,000 users), we see account names change fairly regularly.  With our setup it does create new accounts, so the user does lose group memberships and any tasks assigned, but only really adds admin burden for our heavy users / process administrators who need tasks reassigned over and group membership re-added.  End users with no tasks or elevated privileges don't notice.  Otherwise since our reporting, task audit history, etc is based on Employee ID, the full audit trail remains, since the Employee ID does not change when the account changes.

    Although, where I do see a multitude of annoying issues is when the deactivated account has initiated a number of currently-running processes.  I have an entire side system setup to reactivate certain accounts after our feed runs, for a period of time, since any task escalations, or script tasks set to run as the initiator, will fail, pause the process, and sometimes change task names to "ERROR...". 

    I think there was a Feature Request submitted a while back to request the ability to change the pp!initiator value by system admins if needed :)