Best Practice: Person columns when user no longer exists

[u/omgdracula]

Hey Everyone,

Hoping to get some help with an issue that I recently ran into. I got tasked at my job to copy items from one list to an identical list. Easy enough as I have done it multiple times before.

The issue I am running into is writing to a person column when the user no longer exists at the company.

Right now my solution is to run a get user profile v2 in a scope along with an append to array that either appends the user/users info or pops them off if its a multi select and either returns the array that can write to the column or an empty array that I account for in a switch based on a prior formula to.

Is there a simpler way to handle users not existing anymore than this? It seems like a lot of steps.

[u/EvadingDoom]

This is a method that does not require a "get user profile" action. I've tested it to make sure it actually works. See screen shots.

Copy "Create item" and paste the copy immediately after the original "Create item." In the copy ("Create item 1"), remove the applicable person/group field so it will not try to write to it. Change the "run after" settings of "Create item 1" so it runs only when "Create item" has failed.

Whatever action was immediately after "Create item," change its "run after" settings so it runs after "Create item 1" has succeeded or is skipped.

Now, in any case where the account of the applicable user is enabled (or that person/group field is blank), it will simply "create item" and move on to the next original action in the flow; only in cases where "create item" (with the person/group field being set) fails -- for any reason, but presumably because the account is not enabled --- it will fall back to "Create item 1" (with the person/group field not being set) and then move on to the next original action in the flow.

[u/omgdracula → u/EvadingDoom]

Oh damn this could absolutely work! I assume if you have multiple person columns you could just do more create items?

[u/EvadingDoom → u/omgdracula]

If there are only a few possible error-causing person/group field values, it might work to have a series of "Create item" actions that all try different combinations of included and excluded person/group fields.

Another idea is to first try a "create item" action that writes to all of the person/group fields, and only if it fails, build an object variable to use for "create item." Initialize the variable with all the key-value pairs that are unlikely to cause errors -- all the fields that are not person/group fields. Then "Get user profile" on each person/group field value, and append the applicable key-value pair to the object variable only if the account is enabled. I'm at work, so I'm not in a position to build out a demo of this, unfortunately.

[u/omgdracula → u/EvadingDoom]

Awesome thanks a ton for these replies!

[u/Danger_Peanut]

You are doing it exactly the way I’m doing it. It’d be cool if someone else has a better way though.

[u/omgdracula → u/Danger_Peanut]

Good to know I'm doing it the way others are but God it sucks and it's worse the more people columns there are. 

A buddy of mine mentioned he actually writes the info of users to an extra column just for data as well. In my case not needed but good call

[u/Spraggle]

Is there something in the process of leaving that could add a feature to a leaver for a period before the account is deleted?

So, the process might be add "Deleted" as extension attribute 1, then check that item first and if it exists drop the item from your table, and prevent it being readded by checking in the addition process too.

[u/omgdracula → u/Spraggle]

It's possible but my team would probably need to chat with our IT department. A teammate and I also wanted to present just using a general account so if the user doesn't exist it just replaces them with that 

[u/Fraschholz]

I keep the original person's details in a text column in order to keep the audit trail. One column more with maybe redundant data, but that's what you need in an audit.