It's common practice to store the Appian username to the database for the createdBy, updatedBy, assigned, and similar fields. It's easy to handle in Appian to support search and filter capabilities when referencing those fields in a record type. But occasionally an associate has a name change, which subsequently causes their Appian username to change, since it's often their email address or something similar. That change disrupts the different features that depend on the username to match in Appian.
At my current client, we're trying to mitigate that disruption by storing the UUID for each user instead. It's easy to use the People Functions plug-in to derive all of the user's information from that UUID.
But, search, filters, and sorting will use the UUID. I tried remedying that by creating a custom record field, but it doesn't allow the user() function (or any plug-in function) to be called from the expression.
How can I do this without resorting to a CDT and writing a bunch of custom code to enable search, filters, and sorting? Is there a better approach to handling occasional name changes, rather than storing the UUID in the database? I'm also trying to avoid the need to update several tables.
Discussion posts and replies are publicly visible
The user record contains the UUID and all other relevant fields. With modern apps, using synced records, you can easily fetch these values from the user record. This should also work with custom record fields.
Understood, Stefan. I was attempting to call the user() function from within the custom record field, but it cannot be used there.
But I tried a different approach that worked, effectively following your guidance of leveraging the User object by creating a relationship with my record type. It allowed me to relate the UUID (text) field of my record type to the uuid field/property of the User object. From there, I was able to create a custom record field using the concatenation custom field function (which Appian autofilled with the first/last name User fields).
I see that this capability was added in 22.4, so it seems I missed that