Split huge list with 255 columns into 4 or 5 lists

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.

Regardm,

Tomasz

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:

SharePoint Server 2010 capacity management: Software boundaries and limits 

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.

Hi Guys,

The environment is Office 365 and I guess there is no way to touch the access the database. #greenawayr  The only option is have some kind of “relational database” using a couple of lists with list lookup. The solution design is pretty bad by previous partner and we have to re-design the form.


Current list has 255 columns and I found that there are redundant columns which could be reduced.

Current list has linked to 8 simple approval workflows that run in sequence. Mike M  you suggested to have built a series of forms.  The similar advise is given by Sean Feeney  Nintex video as well in terms of optimizing the performance of the Nintex form.  List lookup limit is 8 for a list.  The form should NOT be larger than 500K in size.

1. Sean suggested if have a very lengthy form and break into individual task forms & then collect that data. Data can be viewed by others to see at different portion of workflow.
2. If it’s a single user, he further explains that although its large a FORM, it’s a right way to build the form.
   
   
3. If there are certain portion that has to be filled by individuals, then we need integrate forms with workflow. 

In our new form re-design, staff members will be large part of form with 67 columns. So I will choose 3 option. I can’t reduce the columns further as these information are key columns for the Form and then they go for further approvals for different departments such as

Project office manager: with exact same 25 columns. Previous partner has named columns approver comment, Database etc. as Approver_Comment_A, Database_A etc.  

Requestor Review: with exact same 25 columns. Previous partner has named columns approver comment, Database etc. as Approver_Comment_B, Database_B  

Program manager: with exact same 25 columns. Previous partner has named columns approver comment, Database etc. as Approver_Comment_C, Database_C etc.

Closure approval: : with exact same 25 columns. Previous partner has named columns approver comment, Database etc. as Approver_Comment_D, Database_D etc. 

  I want to use a main list with 67 columns to be main form and other lists (don’t finalized the list names yet). The reporting can be used.

I will planning to use 4 new lists like

• Project office manager with 25 columns with lookup within the main list.
• Requestor Review with 25 columns with lookup within the main list.
• Program manager with 25 columns with lookup within the main list.
• Closure approval: with 25 columns with lookup within the main list.

Q: Is above list design okay or you experts have better advice on list design?     
Q: How do I create task forms for new lists? Any walk through would beneficial

Thanks a ton for your help in advance. 

Hi Sandy, 

To offer a quick reply for question two, you design the task forms on the task actions themselves from within the workflow.   Assign a Task for example will allow you to edit the associated Nintex form from within its configuration.   So unlike a list form where you are editing the form directly on top of the list, you will instead edit the Nintex form from within the workflow itself, on the Assign a Task action itself.  Let me know if you need further instruction.

As for the overall architecture, I'd have to take a closer look and examine it a bit more in depth.   I've got to run at the minute but hopefully I can get back to this, if not someone else may chime in.

Thanks,
Mike

Hi guys,

I was talking to a senior engineer who has in Nintex more experience than me today. He suggested to use repeating section for this kind of scenario. So, I will have   following form design

1. Main List (with 67 Columns)
2. Repeating section Database column with 25 controls. 
3. Repeating section Project office manager column with 25 controls
4. Repeating section  Requester Review column with 25 controls.
5. Repeating section Program manager  column with 25 controls
6. Repeating section Closure approval  column with 25 controls.

Please let me this approach with repeating sections with 72 columns within a Nintex form.

‌ ‌ ‌ ‌

Thank you!!

Ryan Greenaway‌ Thanks a ton for your insight and about performance. Company is using SharePoint Online.  Last partner had exactly the same performance issue due to number of columns. its MY FIRST Nintex project and want to deliver the project successfully. 

"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"

Vadim Tabakman‌ Do you mean I use Repeating section and not linked to fields? Can you please advise if using splitting lists and using repeating sections for could be potential solution??

Please advice experts!.    

We had more controls in our repeating sections and far fewer rows required to crash it.

Hi experts, 

I am deep diving the current Nintex form (developed by past partner) which as more than 250+ columns and loading time is around 30 seconds.

There are 7 sections in the farm.

1. General: 8 columns (Request Number is main column, Requested Date, Requested by (Current user), Current Date etc. )
2. Project Info: 16 columns (Project description, Project Category, Project Category etc. )
3. Commercial Info: 19 columns (Product Life, Yearly Quantity, Customer Information etc. )
4. Supply Chain Info: 5 Columns (Delivery type, customer location etc. )+ Base Option (25 Columns, lighting, connectivity, database etc. )

5. Product Specifications: 4 Columns (Battery type, battery size etc.)
6. Other Info: 5 Columns (Certification, Protocol etc. )
7. Requestor Comments: 2 Columns
   
   

The minimum columns for the form are 84 columns.


However, Supply Chain Info section has 5 columns and base information product with 25 columns. Columns types includes 5 radio buttons, 7 drop down lists, 2 checkboxes and remaining are single line of text.

User also have different options within the form and can select Option A, B and C. All the options have exactly same information as base option with 25 columns as base information with(5 radio buttons, 7 drop down lists, 2 checkboxes and remaining are single line of text)



Past partner has created columns like this:

Furthermore, if a user select Option A and selects a specific database, then that database itself has 30 more columns subsequent configuration about the product.

For e.g.

User select Option A from the Supply Chain Info  section>> Selects few items within form  >> Selects a Database named “ABC” from dropdown >> Nintex form shows 30 more columns for that database.      

Approvals are done by different users across the globe in an approval chain and there are 5 approvals. Each approver has 6 columns (Date time, radio button, 2 People and Groups, 2 multiple line).

They are indicated Part 2 Approvers, Part 3 Approvers etc. within the form for each 7 sections as described above.  

So 30 more columns for approval sections as well

This is how the list is designed by last partner. I need to make the form more manageable so that current customer does face the error with improved performance.

This is my design:

1. Split the lists.
2. Main list with Request Number, Requester etc.
3. I guess splitting the bigger sections such as Supply Chain Info, Project specification (Option A, Option B, Option C)
4. Splitting Project Category and Commercial Info. Use lookups for main list.
5. Separate list for Database as might can reach 90 columns if use selects all the Options A, B, and C.
6. Still considering which form I can use Repeating section.   

Any guidance in the better approach of splitting the lists/repeating section would be highly appreciated.

Those particular controls won't be particularly resource hungry, but lookups and people pickers will be more so.

It does sound like a form that could hit performance issues.

‌ you created a troublesome form didn't you? Anything more to add to this?

‌ ‌  ‌

Can you please advice on the list designs that I have prepared? 

Which is the best approach to handle the kind of form? 

Thanks!

Mike M‌ Ryan Greenaway‌ ‌ ‌ ‌

Is it possible to save Nintex Form data rather than custom list? I will be saving minimum within list such as Requestor Date, Approved by fields etc and store max info inside the Nintex form.  
How it can be done?

Any guidance will be greatly appreciated.