ab50439
Scholar

Re: Conditional Startup for when checkbox gets checked

Jump to solution
I see the confusion. I got my TEST to work. The test demonstrates that the value of checkboxes (Yes/No fields) are set to NULL for any items in the list created before the checkbox was added. There doesn't seem to be any way to check for null values of a checkbox in the conditional startup criteria. And the conditional startup criteria seems to be the only place you can check "previous values".
0 Kudos
Reply
Jekaterina
Scholar

Re: Conditional Startup for when checkbox gets checked

Jump to solution

@ab50439,

I was able to reproduce the behavior now - indeed, after creating the Yes/No column, the value is NULL for all existing items in the list and the workflow is not triggering.

Perhaps then you should consider less complicated approach...

 

If you decided to add a new column into the existing list and build the workflow based on it, I think it is normal to ensure that the data in the list is consistent. To achieve that you could update all items in the list where Yes/No field value is NULL and set the values to 'No'. This can be done throught the workflow as well (one action to update multiple items).

Another approach would be to create a calculated column in the list (=IF([FinishedReportAttached],"Yes","No")) and configure the start up options of the workflow to use this field instead.

 

I would prefer the first approach because I don't like the lists with unnecessary columns....

 

Reply
ab50439
Scholar

Re: Conditional Startup for when checkbox gets checked

Jump to solution

Thanks.  Updating the vaules of the new checkbox on all existing records is a possibility.  I want to avoid it, though, because it would change the the last modified date and last modified user on all records.

0 Kudos
Reply
ab50439
Scholar

Re: Conditional Startup for when checkbox gets checked

Jump to solution

I confirmed that adding a calculated field and using that for the workflow conditional startup works.  That's what I'll probably use since it doesn't change the modified dates of every list item.  Having to add an extra field for this is unfortunate, but this is a usable workaround.

0 Kudos
Reply