Searching by user ID on the user record

Question

I was reading this link: https://docs.appian.com/suite/help/17.3/User_Management.html#-add-user-filters and didn't find the answer to my question. I would like to be able to search by user ID. Is there any way to do so?

Mike Schmitt · Answer

In one of my projects, to solve this I created a "user picker from database" custom component (which uses the generic picker field paired with my Users database table), as it allows inactive users to be searched in a similar fashion to the OOB user picker, but to allow inactive ones to be returned (along with a label saying "(deactivated)" after their name). This does require a "users" table to be created and maintained, but IMHO that's fairly essential for any project.

Mike Schmitt · Answer

Sorry for the late reply - for whatever reason I don't think I originally got a notification of this so I only just noticed after the newer reply was added below. 
 In general the user DB table can and should be fairly simple - with just enough to give you the control you need. The fields typically involved that I've seen: 
 
 user ID (primary key for the DB table, integer, auto-generated) 
 username (text mapping to the Appian user's username) 
 firstName, middleName, lastName, nickname, email address -- these values would be duplicative of ones stored within the Appian User, but would need to be stored in the DB table and synced by your processes, especially due to the need to be able to search users by name, etc. 
 is_active -- boolean; set to 1 by default, and set it to 0 if deactivating a user 
 created_date, created_by, modified_date, modified_by -- "standard" columns that store the username and edit date any time a record is created or modified via your in-process tools. These are optional but if you don't include these your O&M support personnel will probably hate you. I'm in the awkward position of being O&M support on a project where I designed a few tables without these, and hate myself for it ;-) 
 
 That's about all you would need - to support such a table, you would either need a process where admins can add/edit users via a front-end process, or at least a process that runs periodically and finds all current active user accounts in the system and syncs their data with the matching DB table entry, and creates one if none is found.

Mike Schmitt · Answer

I don't have such a process at hand, but it shouldn't be terribly hard to create from scratch. A few checklist items I can think of: 
 
 Create a subprocess that handles all of the actual "work" involved 
 Create a parent process that's launched by a timer, i.e. daily at 1 AM, calling the subprocess from step 1 
 In the main subprocess,
 
 call the "get users from group" function on a group that you set up to contain all applicable [active] users (such as all users in the system, or all users that meet certain criteria) by rule; save an array (PV) of usernames or "user" type 
 query all users from your DB users table (active and inactive), save into a separate PV 
 check for 3 subsets:
 
 Appian user accounts that don't exist in the DB
 
 for these, create a new DB entry

Appian user accounts that are in the DB but are marked as deactivated
 
 for these, the DB entry would need to be marked as active again

DB entries that are marked as active but not currently found in the users array
 
 for these, the user has presumably gotten deactivated, so the DB entry would need to be marked as deactivated

for the above step, i recommend feeding both the user array as well as db-queried CDT into one big expression rule which will then spit out a CDT array of just the needed changed DB entries (we're assuming that the Appian user accounts and their current states are the "source of truth"). This will make it incredibly easier to both develop as well as debug and test. 
 Write all modified DB entries to the DB table.

Optionally create an independent parent process that will also invoke the main subprocess but which can be kicked off by an admin, on an ad-hoc basis, if a midday update is needed, etc. This will have potential performance implications (especially if there are tons of users) but could be helpful if there is an occasional urgent need to allow them to update the DB immediately after a user change. 
 
 Let me know if any of that is unclear or if there are any other questions. This was all off the top of my head so I may have glossed over something.

Mike Schmitt · Answer

John Stretton said: Also, don't you wish that there were a better way to handle scheduling processes to run on a timer? 
 I'm quick to call out Appian in areas that I feel they need to improve, but as far as pure use cases like running a maintenance process once per day overnight, I feel it's fairly easy to do once you get used to the necessary controls. 
 The one thing I wish we could do, though, would be to set up process triggers based on internal events (like, "run this process every time a user is created, updated or deactivated via any internal mechanism", which would negate the need for a timer in most cases). But alas, I don't anticipate that happening any time soon.

Mike Schmitt · Answer

IF you really wanted to, you could potentially configure all (or most) of those use cases into one "daily launch" process model, which then calls various subprocesses (themselves not having any sort of timer), which could each do a double-check whether they should A) not fire "today" (and just exit), B) fire at a later time (wait at a timer node, then execute), or C) execute right away (stuff that should happen at 1 AM). 
 I mean, I suppose they could simplify it some, but then we'd likely lose some of the more complex capabilities we currently have.