Well, the good thing is I got it to work, the bad thing is I still don't understand why the earlier version didn't.
When I was looking at your video, I was thinking about the place of the condition (on workflow vs on task) as well, but then I read you had thought of that as well and you tested it.
I performed the same trick you did, setting a text field only when the value of the checkbox changed to 1, and that worked! It left the text field alone when expected and altered it when expected.
Then I duplicated that task, but then used a send-email task and then that one didn't.
I also opened my entire coreBOS folder for this project and searched ALL files for the checkbox's name. No results came up other than the log files, which is correct because I logged a lot of these changes. But no events that changed the field whatsoever.
To be clear: this task was inside a workflow. The workflow had no conditions of its own. There were 3 tasks in the workflow, including this one. None of the other tasks touched the checkbox I was trying to monitor. I added a fourth task that updated a text field, the task had the 'has changed to true' condition and it worked. The original task, that was setup the same but used a send-email task didn't.
Then I created a completely new workflow and added the condition 'has changed to true' to the workflow and added only the one task (send e-mail). I made the workflow function unitll the first time a condition was met. This worked!
So basically the 'old' setup worked when I used it to update a text field, but not to send an e-mail. Moving that task to its own workflow did the trick. I'm glad it's working now, but I have no idea why the old one didn't work. Somehow, the e-mail task could not get the EntityDelta right, which whomever created it knew would sometimes happen, considering the code and comments they wrote. It's too bad they never added a comment that stated why they knew this wouldn't work sometimes.
When I was looking at your video, I was thinking about the place of the condition (on workflow vs on task) as well, but then I read you had thought of that as well and you tested it.
I performed the same trick you did, setting a text field only when the value of the checkbox changed to 1, and that worked! It left the text field alone when expected and altered it when expected.
Then I duplicated that task, but then used a send-email task and then that one didn't.
I also opened my entire coreBOS folder for this project and searched ALL files for the checkbox's name. No results came up other than the log files, which is correct because I logged a lot of these changes. But no events that changed the field whatsoever.
To be clear: this task was inside a workflow. The workflow had no conditions of its own. There were 3 tasks in the workflow, including this one. None of the other tasks touched the checkbox I was trying to monitor. I added a fourth task that updated a text field, the task had the 'has changed to true' condition and it worked. The original task, that was setup the same but used a send-email task didn't.
Then I created a completely new workflow and added the condition 'has changed to true' to the workflow and added only the one task (send e-mail). I made the workflow function unitll the first time a condition was met. This worked!
So basically the 'old' setup worked when I used it to update a text field, but not to send an e-mail. Moving that task to its own workflow did the trick. I'm glad it's working now, but I have no idea why the old one didn't work. Somehow, the e-mail task could not get the EntityDelta right, which whomever created it knew would sometimes happen, considering the code and comments they wrote. It's too bad they never added a comment that stated why they knew this wouldn't work sometimes.