Best way to store Audit Fields

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. 

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 :)

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 :)