Question on Best Practice for multi-form setup

[Travis Goodman]

Hey Alex, looking for your input/opinion on best practices for when I have a setup that would have multiple forms all in one list.

Example: I use SharePoint lists and DFFS very often to create a ticketing system for various teams. The first dropdown in almost every one of these forms is for “Request Type”. A team could have 10+ different choices to choose from for Request Type, and based on the choice, I want to present them with very different fields to fill out. Some of these fields apply to more than one request type, which is a key detail in why I’m making these posts.

Knowing this, what kind of a setup do you recommend as a best practice, because I’m quickly finding out that the way I’m doing it is resulting in a lot of rule conflict logic (I have one list that has over 80 rules on one of the forms!)

Should I separate these forms into Content Types and add the fields that cross over into multiple different request types into each content type?

Should I separate the request types and the fields into tabs in DFFS?

What are your thoughts here? The biggest issue I notice is someone will select a request type, start filling it out, and then realize that’s not the form they wanted, so they’ll change the request type to something else which triggers different rules. Well, now in some cases they are causing rule conflicts, specifically when they set a value of a field and I had a requirement set on another field when that value is set and then when they change request type, those fields aren’t even visible, they have no value, now the person can’t even save. Headache, and it’s all because of my own setup. I need to optimize it.

Interested in your thoughts, ultimately this is a “me” issue for me to resolve. One thing that could help me out is if there is a DFFS function I could leverage in Custom JS that when they change the request type, it clears out every field they might have modified, and basically resets the form, but that might not be the truly best way to go about this.

I could also just set the request type to read-only once they pick something, then they have to refresh if they chose the wrong one. Not the best user experience though, but it’ll stop this issue.

[SteveE]

Hey Travis,

Obviously I’m not Alex but I thought I’d chime in. I’ve done very similar things and I do think clearing the values upon change of request type is probably the best approach. Whether you group the fields in tabs is just a design choice to make, but the building out of the fields to display and require can all be done using one list and one form.

My personal opinion is that writing some custom JS is probably going to help you make some of this easier. Rules are awesome, but sometimes when you start getting fairly complex, writing something custom can be a better way to handle some things. I think of it like SharePoint itself: it’s great on its own doing some basic stuff, but once you get more and more complex, a different approach is necessary. That’s how you got to using Alex’s work!

I would probably think about what you have that is causing the biggest issue and how rules may not be handling it and address those in some custom code. Is it that the request type changes and fields aren’t visible and/or required? Try making a code block that will handle that as a switch statement. If it’s only certain fields maybe only those need to be included. Something like

switch (requesttypecolumn.value){
case “email”:
columnname1.value=””;
columnname2.value=””;
break;
case “network”:
columnname3.value=””;
columnname4.value=””;
break;
};

In addition to setting values you could make things required, visible, or whatever else you want. But that way at least the main issue you are having is handled and you can use rules for the more “basic” things you are doing. Obviously my code there isn’t calling your fields or their values correctly, but I thought it might help you in your design planning.

Just my opinion so feel free to disregard.

– Steve

[Author]

Posts