Skip to main content

So this morning I was trying to write to a date & time field on a button click on the new responsive forms designer. I clicked on the button settings > Advanced > Connected To but in my list of columns, my Date & Time column wasn't there. It appears that only the text based columns can be written to here. This was frustrating, especially as you can write the date and time to a text column using the common references.

 

Ah-ha, I wonder? Let's see.

 

That light bulb moment you just witnessed was me thinking, if I set the button to write to a Single Line of Text (SLOT) using the "Current Time" reference, I get myself a date and time, that's fine, but no good for reporting really, I want my datatype to be Date and time, not just a string containing the date and time. Nevertheless, I published the form and knowing that my button was configured how I wanted it to be, then in my list, head to the List Settings, head to the SLOT column settings for the column I've just connected my button to and in these settings I can switch the data type from SLOT to Date and Time. 

 

Now here comes the test, firstly, is my form still configured? Head back to the form designer and check my button settings, all the configs are still there...great.

 

Now create a new item in my list and hit that button and Bingo! Date and time written to a date and time column, even though the form designer didn't really want me to. Perfect.

 

I'm guessing that Nintex didn't want people to be able to write to date and time columns because they might be prone to putting something other than the date and time in here and values will be lost, but as they give us a reference, it still seems odd to me.

 

Anyway, this relatively simple fix means you can write to a datatype using certain actions that you might not have thought you could. 

 

I wonder whether the same might work with a Choice column (you could allow Fill In choices for flexibility perhaps)?

 

On that note, what other workarounds/fudges/obstruction breakers/loopholes have you discovered in your journeys through Nintex? Not after whizzy javascript solutions here, stuff that people can do from the interface with no custom code. Intrigued to find out what else lingers out there.

Another Workaround I figured out today was to do with tasks in O365.

We have only 2 types of workflow task in O365, both require outcomes, as opposed to the Request Data task or To-do task available on prem.

It can seem a little illogical having a form that requires an outcome when all you are looking to do is ask the assignee to provide data or say that a job outside of the system has been completed.

Set the default value for your task outcome to Approved (or whatever you choose to call it) and hide the outcome control on the form. The user then has to just fill in the fields available on the form and hit Save to progress the workflow. The cancel button can still be available to allow the user to back out of the form and finish it another time. Obviously this is only useful if you expect the user to simply progress the workflow, if there are multiple outcomes with different actions as a result then the user needs to be able to choose an outcome.


Reply