Wishing everyone a very HAPPY and prosperous new year 2017!
Now, company approached us and we are in process of fixing the issue.
We found that it that list has some workflow is too slow due to number of columns and workflow at times shows this error.
We raised a support ticket with Nintex and they asked to export form and import the form to a new list. While doing so we got the following error:
Nintex also concluded that because of large columns company should reduce no of columns. However, the company cant reduce the no of columns as they are important columns.
We are in process to re-develop the solution.
We are thinking to split the that lists and planning to Nintex form to query other lists within the form
Solved! Go to Solution.
Happy New Year :)
You could use the List Lookup control on the form to do a query on another list and display the information.
Do you know why they have so many fields on that list? Is it absolutely necessary?
You can have a bunch of controls on the form that aren't linked to fields and where needed, a workflow can query the data inside the form, rather than having so many fields on the list itself.
What Vadim Tabakman wrote is a really good solution. You have to review the columns list and decide if some of them can be considered as dictionary values for example. For such columns you should then create separate lists and use the lookup. This will also makes your workflow/ process data easier to maintain.
Maybe you can also find separable sub-processes in your workflow? Then you could create a separate list for each sub-process and trigger them one after another, using the "Start workflow" action.
Depending on how much the data within the list is going to grow, I would question whether SharePoint is the correct solution for this.
255 columns in a normal database table would be one very big, flat and unwieldy table, put that in SharePoint and it becomes more so.
Sounds to me like what you are now doing by breaking up the list into smaller lists is normalizing it and as we know SharePoint is not a relational database tool.
Have a good think about where this might head in the future. Whilst you might be able to manage the relationships between the tables now, will this be possible if the solution develops further. It might be worth looking at this as a database solution rather than a SharePoint solution.
Also, check out the column type limits here. This is for SharePoint 2013, but I believe similar limitations exist in O365
This is an interesting problem to say the least, because no matter what you do you will tend to run into one size limitation or another - even if you do resort to pulling in data from other places into a single form, your form could crash due to the amount of data.
You might want to consider building a series of forms, connected by a workflow, and then you could use task forms along the way to collect data and stash that data along the way (to either different lists, or to a data base). A data base table might be ideal, because you could then use a reporting tool that would be better suited to produce output that could be visually reviewed.
SP is great at a lot of things, but there are a few cases that make fitting it to a solution challenging.
Here is an article that describes the size limitations (pertaining to items) and some other interesting stats:
Thanks a ton for your valuable inputs.
I had to study this complicated form due to no of columns.
I found that 67 columns were the primary columns.
When a drop down item is selected (such as specific Database), other selections within a form with more fields such as SQL Server, Oracle, MySql etc as options is shown.
I need to make some more lists with lookup fields for this primary list with 67 columns and make solution more easier to maintain and scalable.
Any suggestion from experts?
I would break down the form into sections/tabs. Each section would be a different list. The first section that is created would have the automated ID that would be used in the other lists to pull the information together. I definitely would still try to reduce any fields that aren't necessary because that is still a lot of fields.
Thanks for your wonderful idea. That's my initial design to split the lists. I came up with following list design
Main List (General Information, Request Number is main column, Requested Date, Requested by (Current user), Current Date etc. )
Project Information and lookup to main list
Commercial Information and lookup to main list
Supplier Chain Information
Options and lookup to main list
Database and lookup to main list
Other’s Information and lookup to main list
In their paper form, it’s a 6 page and when a user checks the specific options such as Option A (each one has exactly same configuration ), Option B and Option C. Past partner created 25 columns each for options that amounts 75 columns.
That’s why I am planning to use repeating section and get just 4 columns instead of 75 columns.
Can you please suggest, how could I use automated ID which you suggested for all the lists? In my design each list will have its own ID.