Skip to main content

I decided to try and use the new responsive form designer to create a form in SharePoint Online.  I really like the new designer, but have come across the following issues and am wondering if I am doing something wrong or are these bugs.

 

1. I added a list lookup control name SystemLL to the form that returns 2 values from another list in the same site.  Let's just say for this example the values are "System1" and "System2".  I created a string variable and used the parselookup(SystemLL) to extract the string value from the lookup. I then created an On Form Input Rule that populates the variable value into a text box that is bound to a SharePoint Column when the SystemLL Control is filled.  I test the form and everything works.  However when I save the form the value is not being saved, System.ObjectO] is being saved instead.  If I click into the text field after the rule fires and then save, the value will be saved correctly to sharepoint.

 

2.  Along the same lines, I have another list lookup that returns either "Green", "Red", "Black".   I was trying to create a variable to map the color to a value ranking using the ifElse.  I used the following syntax ifElse(parselookup(Ranking) == "Green", 4, 2).  No matter which color I choose, the value is always 2.  If I create a variable with just the parselookup function, it returns the correct color.  I was able to work around this issue by removing the parselookup function and using a contains instead of equal on the loookup field itself.

 

Any suggestions would be appreciated.  

 

@EuanGamble  @blalocb @eharris04 

For your second question, I suggest watching Euan's video titled, "How to build a risk management matrix in Nintex New Responsive Forms for Office365". Here's the link: https://youtu.be/NRwj-prW_Ms

Hi @mdoak,



 



Thanks for trying out the New Responsive designer. Would you mind attaching your form to this post so I can have a look?



 



Cheers,



Euan

Thanks for the response @EuanGamble .  I am attaching a simplied form that shows both issues.  I'd expect the Ranking to be 4 when "Green" is selected.  I've watched the video posted above and I think I'm doing everything correctly.  Thanks again for taking a look.





 





 

Hi @mdoak,



 



So I have had a look and think I know what is happening. The parseLookup is displaying the correct text you would expect, but in memory it is still stored as the multi-property value that a List Lookup understands. 



 



So for your first  "Green" option, try:



ifElse(contains([Form].[RankingLL],"Green"),4,2)


The problem, however, is that the parseLookup is now passing what it knows in memory (List Lookup data) to the Single Line of Text and the column does not understand that data type. Hence it says "System.Object[]".



 



This is a bug and needs to be addressed. I have raised it with the development team, but it would be really helpful if you could also log a call with support? Please just email them the details and include this community post to support@nintex.com. That way it will be tracked and managed.



 



Thanks,



Euan

Thanks @EuanGamble.  I actually had a support case open about it, so I have linked this discussion to it.  The case number is 00289683.

Thanks for that @mdoak.




I have recorded a video for support and dev team replicating the issue. Support will be able to update you with the progress from here.



 



Cheers,



Euan

Until the parseLookup issue is resolved you can implement your own.

This example handles ID's with 1, 2 or 3 digits:

ifElse(contains(substring([Form].[RankingLL],2,1),"#")
,substring([Form].[RankingLL],3,255),
ifElse(contains(substring([Form].[RankingLL],3,1),"#")
,substring([Form].[RankingLL],4,255)
,substring([Form].[RankingLL],5,255)
)
)

To support ID's with more digits just add more nested ifElse clauses with a higher valued offset.

If anyone is experiencing the parseLookup function issue, please raise it with support@nintex.com as it helps us prioritize the defect based on the number of affected customers.



 



Thanks,



Euan

glad to have seen this - i've been wrestling with the same issue for days now. I will raise the issue immediately. Disappointing though as my form and process deadline is looming!

Any update on this? - I have raised a support ticket on the same but the parse lookup suggested won't work for what I need. Grateful for any other immediate help. Case number 00293880.

Hi @JulieJ,



 



For updates, please go through support as they will be managing the case. I have emailed support regarding your case however.



 



Regards,



Euan

I have raised a ticket too. In the meantime, I will use the workaround. Too bad there is no indexOf function to make the formula less longer.

Thank you very much. Without this, I'd have had to rebuild a very complex form in original responsive.

Hi @shaunlub,




Can you confirm the issue is now resolved?



 



Thanks,
Euan

Well this was not my issue originally, but it was an issue for me. I'm not sure it is fully resolved as I am using the workaround explained by v-tmasenko - which I am using in place of the parseLookup function.
I had hit the System.Object[] and tried as best I could to work past or around it. Only after finding v-tmasenko's workaround can I now proceed with work as normal.

Sorry, @shaunlub. I misunderstood your previous post.



 



The issue has still not been resolved as yet.



 



Cheers,



Euan

I was having a similar issue with the new responsive form, variables and rules. I am developing a form to submit product parts orders. The form looks up the parts in another list (less than 200 rows of items) on the same SharePoint site and populates the associated data (list price, unit measure, part # and an image of the part) on the form.





 


Initially I was creating variables to get the data to be populated. For example, this formula looks up the Part Number in the list:


 




lookup("Parts Catalog","ID",parseLookup(convertToString([Form].[Section IL 7000].[IL7000 Description]),false),"Part #")




I would use a rule to populate the other fields on the form. This worked fine in preview mode, but once a user filled out the form in the published version, the form would not submit or they needed to press the submit button multiple times.




 


Based on the information in this post, I decided to see if I could do away with the variables. I took the formulas I created for the variables and directly entered them in the rules and it worked. And the form is now faster.


 


I am surprised this hasn't been fixed after almost a year.




Hi @David-,



 



I have not seen this issue before. Did you raise a support case so the team can investigate?



 



Cheers,



Euan

Yes, I submitted a ticket to the support desk. Thanks!

Hi @David-,



 



What is your case number? I would like to understand what the issue is.




Cheers,



Euan

Good day, Eric:



 



This is the case I submitted: https://customer.nintex.com/cases/Pages/detail.aspx?caseId=5002v00002qKHoCAAW. If you would like, I can show you the issue via MS Teams/Skype if you send me an e-mail with your contact information. I was able to resolve the issue on my own by not using variables and instead I directly coded the functions into rules.



 



For example, this is one of the rules to populate a field on the form:



lookup("Vehicle Info- Data","ID",convertToNumber(parseLookup([Form].[Lookup Years],false)),"Constant Color") + " +"

Originally I used two variables for this (maybe three).





  1. Vehicle ID: convertToNumber(parseLookup([Form].[Lookup Years],false))


  2. Constant Color: lookup("Vehicle Info- Data","ID","Vehicle ID","Constant Color") + " +"




Referencing a variable in a rule seems to be a known issue in Nintex for SharePoint 365. Attached is a copy of my form. The three fields at the top of the form, Lookup Make, Lookup Model and Lookup Years, all lookup data in another SharePoint list. My rules then populate the rest of the form. It also seems like that if you have a variable and it is not populated on the form, this causes problems as well, which is why I nested the formulas. This is probably more efficient, but since I am not a programmer, it was a bit confusing at first.



 



I originally created variables to do this and made the variables the default value for these fields. However, when I went to submit the form, it would not submit most of the time. Although, on a few instances it did. This is when I submitted the original help desk ticket and started browsing the forums. I came across an issue where other people were having problems with variables and lookups, and decided to see if I could do away with variables, which is when I went the route of using rules and putting the functions directly in the rules.

Hi @David-,



 



Please send me an email at euan.gamble@nintex.com.



 



Thanks,



Euan

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings