Mark Roethof
Tera Patron

Articles, Blogs, Videos, Podcasts, Share projects - Experiences from the field

 

The issue described in this content, has been fixed by ServiceNow in Patch 4 of the Madrid family release.

 

Hi there,

 

A short article about gained knowledge concerning the incorrect Date format in submitted variables through Multi-Row Variable Sets. Out-of-the-box, for date settings other than yyyy-MM-dd, this does not seem to work as expected. It's listed as a Problem, targeted to be fixed in New York (PRB1325027). Because not every instance will be on New York within 3 / 6 / 9 months, a temporary workaround could be more than welcome.

The Issue

When your system has a date format that differs from yyyy-MM-dd, submitted Date variables through Multi-Row Variable Sets display as (for example) 09-11-0027, 09-11-0034, 09-11-0035, etc.. This occurs while entering the date through the date picker, manually, etc..


Looking at the submitted variables (Multi-Row Question Anwers table) though, the values do look oke. It's just not represented well in Requested Items.

 

find_real_file.png

Workaround

The issue is that the values in the Multi-Row Question Answers table are stored exactly like what the user entered through the Catalog Item / Record Producer. The values should actually be stored as yyyy-MM-dd! Changing the values manually would already fix the issue.

 

So... updating the values automatically 😀. Just create a Business Rule and follow these steps:

 

find_real_file.png

 

find_real_file.png

---

And that's it actually. Hope you like it. If any questions or remarks, let me know!

 

C

If this content helped you, I would appreciate it if you hit bookmark or mark it as helpful.

 

Interested in more Articles, Blogs, Videos, Podcasts, Share projects I shared/participated in?
- Articles, Blogs, Videos, Podcasts, Share projects - Experiences from the field

 

Kind regards,


Mark Roethof

ServiceNow Technical Consultant @ Paphos Group
---

LinkedIn

Comments
Mark Roethof
Tera Patron

"It's listed as a Problem, targeted to be fixed in New York (PRB1325027)"...

Just noticed, this is already fixed in Madrid patch 4! No need for a workaround anymore with this patch.

Kind regards,
Mark

---

LinkedIn

AbhishekGardade
Giga Sage

Great work Mark! Kudos!!! That is really helpful

Version history
Last update:
‎08-31-2025 04:20 AM
Updated by:
Contributors