Details: I have a user named Scott. His isAdmin = True.
Our database default is to set isAdmin = False.
When Scott updates his user profile, and the WF doesn’t specify a value for “isAdmin” - what’s the expected result in the database?
…I’m getting it set to False, but that doesn’t seem to me to be the desired logic for how this should behave. But, I could be missing something. Thoughts?
That’s odd I would think if you didn’t specify it shouldn’t touch isAdmin. Otherwise you’d have to set the value of every field everytime.
Is it:
isAdmin = [empty]
in the workflow? Or you don’t have a field change to “isAdmin” at all in the workflow?
If it’s “isAdmin” = [empty], I believe that will set to false each time. But if you’re not setting “isAdmin” as a field to change in the action, I also don’t think it should be changing it at all? 
If it was already set, it definitely shouldn’t change… right? I agree that if it was empty, then setting it to the default would make sense. Honestly though, I thought the default value only gets set when the thing is created for the first time and a value isn’t specified for the field. Meaning, it should not even be touched on “make a change” actions…
From reference:
Default value
The default value is a way to define what the field should be if there is no information in the ‘Create new thing’ action for the current field.
I’ll need to look further into this. Something in our app is changing the isAdmin to False for those who are, in fact, admin. Tracing back through the logs, it looks like this is what’s causing it, but I can’t be sure. May need to create a page to test this in an isolated environment. Will let you know what I discover.
Okay, so I think I’ve figured this out.
It doesn’t override an entry when I simply update a thing.
However, the default values do override an entry when I “create an account for someone else” even though I have selected “return the user if the account already exists.” I will file as bug report since I don’t believe this is the intended behavior.
@john3, @fayewatson, @romanmg , thanks for weighing in - I appreciate it.
We fixed this. Sorry for the bug.
Thanks for the quick fix!
