William Holland

Will Holland is a Principal Software Engineer at ThreeWill. Will has proven to be adept at understanding a client’s needs and matching them with the appropriate solution. Recently he’s developed a passion for working with .NET, MVC, and cloud-based solutions such as Microsoft Azure and Microsoft 365.

Introduction

If you’ve been in the SharePoint community for any considerable amount of time, chances are that you’ve at least heard of Nintex. I think I personally learned of them and their products during some of my earliest migration work. I even met some of their team at last years Cloud Saturday event, where their booth was right next to ours. Still, it’s only been recently that I’ve had an opportunity to actually use their product.

We are currently working with a client to take them from a pen-and-paper set of forms and processes and bringing them into the digital age. Before I was officially brought on to the project, the decision to use Nintex Forms and Workflows for Microsoft 365 had been decided. The project had an aggressive budget and timeline, and Nintex seemed complimentary to both of those prerogatives. Plus, the client required a mobile app version of the forms and, since Nintex has a native app for both Android and iOS as well as supporting Mobile Web, Nintex really was a “no-brainer.”

Both products, Forms and Workflows, are great tools. As a developer, I’m used to “coding” my way through solutions and having complete control over…well pretty much everything on the implementation side. Nintex products seem to be geared more towards “power users,” with more a quasi WYSIWYG designer interface. If you’ve ever created an InfoPath form or SharePoint Designer workflow, you’ll be right at home. For someone who loves the challenges of coding a solution from the ground up, I have to admit, I was a little disappointed that I was going to spend so much time pointing and clicking.

Once I got started, things started to change. For all of the power and simplicity that comes with Nintex forms, it certainly has its challenges. That simplicity, which is probably great for someone wanting to create a basic form, comes at the cost of a somewhat cumbersome designer UI. Through my time with Nintex forms, I’ve learned a handful of lessons that I thought I’d share with the world. If you ever find yourself creating Nintex Forms, these should help you spend more time creating, and less time churning.

Plan Ahead with Mockups

Easily, the most cumbersome part of the Nintex forms UI is the tedium of lining up your controls. You’ll spend an hour or so shifting labels and text fields around to your liking, just to realize that you left out a must-have input that belongs in the fifth row of your 100 input form. You’ll have to make room for it by shifting the other 95 rows down enough to fit in the missing one.

The Nintex UI does allow you to select multiple controls at once but, even if you go through each of those 95 rows, selecting each label and text field as you go, the UI gets a little kludgy when you try to move things that aren’t on screen. Most of the time, things simply can’t move. So you end up moving 5 or 10 rows at a time (or however many you can fit on the screen at once), add your new row, and realize that you either moved things too little or too much, and have to repeat the process until you get it right. It’s very, very time-consuming.

There’s an old carpentry saying that you may have heard: “Measure Twice, Cut Once”. In this case, doing mockups is the equivalent to measuring. Take some time, sketch out what you have in mind and make sure it fits your needs. Review it with those that will be using the form. Finding a mistake in a mockup is much easier and faster to fix than it is in the Nintex form designer. Plus, having that mockup as a reference will make actually implementing the form go much quicker.

There are several tools out there for doing mockups. Balsamic is a pretty popular one around our office. PowerPoint actually has storyboarding features (starting in PowerPoint 2013), which is what I ended up using since it didn’t cost extra.

Group Your Controls Using Panels

Even with all the planning in the world, you may still find yourself needing to shift things around. Hopefully, your form design is broken into logical “sections.” You might have a “Customer Info” section with the customer’s name and phone number or a “Shipping Address” section that contains fields related to their address. Nintex Forms has a “Panel” control that you can add to your form. By default, it’s invisible when rendered to the user, and, once added, any controls you overlay on top of it are associated with the panel.

With panels, if you ever find yourself needing to shift things around, you can select the panel and drag it around, moving all of the associated controls within it at once. It can really speed things up should you need it.

Create a Rule Once and Apply as Needed

With Nintex Forms, you can create two types of rules: formatting and validation. We use formatting rules to hide or show certain sections based on who the user is or their answer to another field on the form, and we use validation rules to make fields required; sometimes conditionally. One mistake I’ve seen made with rules is that people will re-create the same rule for each individual control on the form.

As an example, if you had a “Billing Address” section that you wanted to hide if the user checked a “Same as Shipping Address.” checkbox, what I’ve seen is that the form’s creator will click on each Billing Address control, and define a “Hide if Same as Shipping Address” rule for each, resulting in 5 “Hide if Same as Shipping Address”. What should have been done is that the rule is defined once and, for each control that it is needed on, the already defined rule should have simply been added to it.

Panels can also help out with rules as well. If you have all of your Billing Address controls added to a panel, instead of needing to add your rule to each control, you can simply select the panel itself and add your “Hide if Same as Shipping Address” rule. Each control in a panel will inherit any rules applied to the panel.

Avoid Hiding the Last Control in a Panel

It’s a bit of a nuanced thing with panels that took me a few hours to figure out. I had a panel that was, by default, hidden unless the user selected “Yes” in an earlier field. The panel contained information pertaining to a vehicle (make, model, year, etc..). The last field in the panel was actually hidden unless the user belonged to a particular SharePoint user group.

Once I started rendering the form, I noticed that this section’s height was limited to only show a row or two, when it was maybe 6 rows in total. Instead of seeing it all at once, the section had its own scroll bar. I don’t think it’s what Nintex intended but, nevertheless, that’s what was happening.

If you find yourself like I did, needing the last control to be hidden in a panel, I did find two workarounds. First, you can add an empty label control below your last control, thereby making it not the last control. You can shrink the height of this label down to the minimum, but it does add a bit of space to your form. The other workaround is to add another panel where your last control goes and add your control-to-be-hidden to it. Now, instead of adding the rule to the control, add it to the sub-panel you just created. Problem solved.

Need More?

Hopefully, these tips will help you out. If you find yourself needing guidance, I’d first recommend signing up at https://community.nintex.com. They have a pretty active community, and I’ve certainly made liberal use of their forums. I’d also recommend checking out the Nintex Learning Center (https://learning.nintex.com) and their YouTube channel for training videos and How-Tos. Finally, you can always leave a comment below. Even if I can’t answer your specific question, I’ll do my best to respond.

For more tips visit: Pro Tips For Using Nintex Forms