Someone on the forum once mentioned a workaround to updating user's first name with a nickname via Fusion. Does anyone have a working example? My biggest concern is what to use as the event trigger. We use SSO and I have a trigger set up on each user update. If the user's lastlogindate is less than 10 seconds old, it will check if the user's first name should be updated. Is there a better way?
Solved! Go to Solution.
Views
Replies
Total Likes
It should just be available as an output from your trigger module - no need to set a custom variable. You can see in my example, I didn't do anything to make it available.
You may have to run the scenario in order for the trigger module to know what outputs it can make available to downstream modules as inputs. I have to do that frequently in order to get outputs to show up.
If an output from a prior module isn't available, you can manually enter it in a field with this syntax (presuming the module number you want the output from is module 1):
{{1.newState.ID}}
It will show up in orange text/white background like your example, because the scenario hasn't validated it as a valid input.
Views
Replies
Total Likes
Hi Jason, that may have been one of my posts.
And, that's very similar to how we do it (trigger on user update). We used to run it on a schedule, but users were confused as to why they sometimes (briefly) saw the "wrong" name.
What is it that concerns you about that approach, or leads you to wonder if there's a better way?
Views
Replies
Total Likes
I was wondering if there was another trigger. Something like a login event. Right now, the code runs on every user update and also runs multiple times for each user within that 10 second timeframe.
Views
Replies
Total Likes
We tried doing it off something like the value of login count or last login date having changed, but those didn't trigger the scenario as expected.
I ended up putting a calculated field on the user form "useAlias" that is either true or false depending if the preferred first or preferred last name fields contain a value. I use that as a filter right after the trigger so it never bothers to check users that don't use preferred names.
For those who do use a preferred name, it will always run twice: once when SSO resets their name, then again when Fusion overwrites that.
Views
Replies
Total Likes
Thanks. I'll give that a try. Does your event trigger use the user ID? If so, how are you pulling it? In my test scenario I have a custom variable that is "newsTate.ID", but I can't figure out how I got that.
Views
Replies
Total Likes
I believe that's what Fusion uses to compare the old value and new value of properties that may have changed on the record update, so you can perform logic based on the change itself if needed.
My first module after the trigger event is a read record, where I read the user record based on newstate.ID. You could use oldState.ID as well, since the ID is never going to change.
The read record module looks at useAlias, first name, last name, preferred first name, and preferred last name.
The filter after read record is "If useAlias=true AND first name ≠ preferred first name, OR If useAlias=true AND last name ≠ preferred last name"
If it passes the filter, it moves on to the update record module.
Views
Replies
Total Likes
Right. newState appears, but ID isn't listed in the collection. In a different scenario, I have newState.ID as a "custom variable". How do I create custom variables.
Views
Replies
Total Likes
It should just be available as an output from your trigger module - no need to set a custom variable. You can see in my example, I didn't do anything to make it available.
You may have to run the scenario in order for the trigger module to know what outputs it can make available to downstream modules as inputs. I have to do that frequently in order to get outputs to show up.
If an output from a prior module isn't available, you can manually enter it in a field with this syntax (presuming the module number you want the output from is module 1):
{{1.newState.ID}}
It will show up in orange text/white background like your example, because the scenario hasn't validated it as a valid input.
Views
Replies
Total Likes
Thanks for the expanded explanation. I didn't know about running the scenario to help populate the list. I ended up adding a module with the "Set Variable" tool. I attached the blueprint for anyone interested.
Views
Replies
Total Likes
Views
Likes
Replies