Nintex – Travel Request Scenario
I wanted to take a stab at a different type of post today. Most of my posts are around how to solve specific problems or how to achieve a particular piece of workflow logic in a reusable fashion. Todays post actually takes a number of my previous posts and puts them together, showing you how it’s possible to build out business logic scenarios using both Nintex Forms and Nintex Workflow. Using Nintex Forms as the user interface/data entry layer and Nintex Workflow as the business logic. There are definitely improvements that can be made to this solution. This was never meant to be 100% completed solution. The aim is to build out enough of this scenario, so that someone else who needs it, can take it upon themselves to improve it and modify it to satisfy their needs.
For those that don’t like to read all that much, I have created a video which you can watch below. It doesn’t go through ever step of the process. Neither does this post. But you’ll be able to download the files in the Downloads section and use them in your environment.
Where to start?
With any business logic scenario that you want to automate in SharePoint, you want to first look at a SharePoint list and what you want to store in it. In our case, I didn’t really do all that much thinking. I wanted everything that I need, to be stored in the Nintex Form. In effect, I’m treating the form as a document, even though it’s linked to an item in a SharePoint list.
Therefore, in this case, I created myself a list called Travel Requests and then I dove straight into creating the Nintex Form.
The form looks like this :
There’s a little more to it, but I only took a screenshot of 70% of it. Pretty cool looking form, right? Ok, maybe it’s not the prettiest form you’ve ever seen. But this form took me about 30mins to put together, that includes putting all the controls on there, aligning them, add CSS and JavaScript. You have to give me some credit for that.
As I started putting this form together, I wanted to touch on a few different things.
- CSS – customizing the UI just a little with CSS will make it easier to modify later on, if I need to. A good example would be that section titles that have a black background. If tomorrow, I need change it to blue, I can simply make the modification in the CSS.
- JavaScript – I have some JavaScript that pulls user information and stores it in controls. It also is used to electronically sign the travel request form for approval. The JS behind the scenes is making a web service call to the SharePoint UserProfile service.
- Rules – I use rules in Nintex Forms to enable/disable parts of the form, depending on where we are in the workflow process.
- Validation – I actually haven’t added that to this form, but it really needs it in many places.
The form above is the design mode of the form. Hence, why you see all the lines and it doesn’t look at neat. Here is what the user experiences when it comes to this form (notice that it is a lot cleaner):
Can I see this form???
Well, actually you can. I’ve published this form to Nintex Live – http://ntx.lv/1pgL6Ew
Follow the link above, and you’ll be able to see the form. What you won’t see, is the Get User Data button. This is because it is trying to make a web service call to the SharePoint User Profile service. By publishing this to Nintex Live, it is now outside my SharePoint environment and as such, doesn’t have access to the User Profile Service.
Do you want to know how I hid the button because we are looking at a Nintex Live published form? You open the settings of the button, go into the Appearance tab and change the Visible property to “Expression”. This allows you to build an expression that will define whether the control is visible or not. In this case, it will look like this :
Using the fn-Not inline function and also the common property “Is Nintex Live”. So this will only show the button, if the current form is being viewed on-premise, rather than through the Nintex Live published form.
What about the workflow?
Well, the workflow is a gem to look at it :
Maybe a gem is stretching it a little. But the aim of this workflow is to keep everything with the single form instance. No tasks are created, but people are notified that they have to fill in (approve) their part of the form.
As a result, we use rules to enable/disable parts of the form, based on which part of the workflow process we are currently at. We could definitely make this smarter. Ideally, as we move to different states, we only give the appropriate person/group permission to the current item. That can be something left for the reader.
We control where the workflow moves by storing the current state into a SharePoint list field. It helps a lot if you need to stop and restart the workflow, as it will know where it’s meant to start from the next time around.
I’ve gone into a little more detail as to how the workflow works in the video above. So make sure you check that out.
