Skip navigation
All Places > Getting Started > Blog > Authors murphybp2

Getting Started

2 Posts authored by: murphybp2 Champion

The June Mission is your opportunity to show us how you'd build a workflow for the following:

 

Scenario:

A service team has a SharePoint list where users submit requests that they need to fulfill.  There are currently 5 different types of requests that they can receive and each request type has between 20-30 steps that have to be completed in order to fulfill the request.  The team has been having some difficulty keeping track of the status of each request and knowing whether all of the steps have been completed or not.  This has led to some request falling through the cracks and the users are none to happy about it. 

 

The current request types are:

  • Inventory
  • Campaign
  • Collections
  • Statements
  • Audit

 

This is a sample list of steps for an Inventory request.  Each request type will have it's own unique set of steps.

Step #Description
1Create master schedule
2Notify the affected departments
3Purchase supplies
4Clean all areas for counting
5Group like items
6Ensure there are no hazards present
7Mark package quantities
8Count and seal partially packaged items
9Mark items not to be counted
10Label each area to be counted
11Validate all items are identified with part number.
12Update storage area floor plans
13Organize couing teams
14Distribute written instructions
15Conduct physical counting
16Conduct 2nd physical counting
17Compare results for accuracy
18Turn in count sheets
19Reconcile counts with the system
20Turn in final inventory results.

 

Requirements:

The manager of the service team would like there to be an automated way that when they receive a new request, the system would create the correct steps for that request type that need to be completed.  Then as the steps are completed the system would update the overall status of the request so that they could look at any request and know how many steps are remaining.  The manager wants to track all of this in SharePoint.

 

Using SharePoint lists and Nintex workflows, design a process that will create the steps for each request type, and then track the status of each request as the steps are completed.  The solution also needs to account for the fact that a new request type could be created in the future, with it's own set of steps, and the manager would want to be able to add it without having to modify the workflow each time.

 

The team is currently using SharePoint on premise with Nintex Workflow, but they may be moving to O365 in the future.  So you can design a solution either for SharePoint/Nintex on-premise, or for O365. 

 

Your mission:

To receive the points, build your solution and click here to create a document in the Nintex Gallery about your solution, detailing exactly how you would solve this issue.  Post a link to your solution below below to earn 400 points and the June "Request Quest" badge!

We look forward to your solutions!

request quest badge

One of the skills every Nintex workflow designer has to learn is how to debug a workflow.  As Andrew Glasser has pointed out in his post Tips on Debugging Workflows, the most common way to do this is to Log information to the History List.  In addition to this there are also times that I will use the Send Notification action to email myself some information at a certain point in the workflow.  In both cases however, these are typically only actions you want to take when developing/debugging a workflow, and don't need them once it's up and running in production.  So what's the best way to turn off these actions once you're ready to publish your workflow?

 

The Problem

The most straight forward way is to go through your workflow before you publish it and either disable or delete these actions.  However depending on how many actions you have, this could be very time consuming.  Plus, if you ever needed to debug something in the future, you'd need to edit the workflow and turn them all back on again.  If you opted to delete them, that would give you even more work to do. 

 

The Solution

The solution I have found for this problem is to use a list to store an indicator for whether logging is on or off for a particular workflow.  I setup my workflows to do a lookup to that list and determine whether there should be any logging.  All of my logging actions are contained within a Run If action that will only run if the logging indicator is turned on.  This way I can turn logging on or off for any workflow simply by changing the logging value in the list.  (This is the same concept Andrew Glasser has written about in Using Workflow Configuration Lists in O365, but just a different application. I like Andrew's nomenclature of calling it a "Configuration List", so I'm going to stick with that.)

 

The Configuration List

The first step is to create your configuration list to store the logging indicator.  I use the Title field to store the workflow name.  I then create a Choice field to store the logging indicator.  I made my choices "On" and "Off", and set the field as Radio Buttons.  I also make sure to set a default value so I don't run into an issue with the workflow where I find no logging value when I attempt to look it up.

 

Once the list is setup, I can then add entries for my workflows and set the logging value. Make sure that the workflow name you enter matches your workflow names exactly.  If you ever change your workflow name, you'll need to update it here as well.  

 

Workflow Configuration List

Logging Field Setup

Once the list is setup, I can then add entries for my workflows and set the logging value. Make sure that the workflow name you enter matches your workflow names exactly.  If you ever change your workflow name, you'll need to update it here as well.  

 

Configuration List

 

The UDA

Since I'm planning to reuse this solution for all of my workflows, I'm going to create a UDA called "Check Logging Status" to do the lookup of the logging indicator.  I setup my UDA with two parameters.  The input parameter is the Workflow Name, and the output parameter is the Logging Status.  Both are text parameters.  

 

UDA Parameters

The only action in the UDA is a Query List action.  This will lookup the entry with the matching workflow name on the configuration list we created above, and then return the logging status indicator for that entry.   

 

UDA Query List    

 

The Workflow Setup

Once the UDA is created, you can now use it in a workflow.  Whenever I create a new workflow, the first thing I do is insert the Check Logging Status UDA.  

 

Insert UDA

 

UDA Setup

After you add the UDA, you'll need to setup the Input and Output parameters.  For the Input parameters, you will pass the Workflow Title.  Since this is part of the Workflow Context data, you can just select it from that list.  For the Output parameter, I create a single line of text variable to save the returned logging status. 

 

UDA Setup In Workflow

Tip: If you want to save yourself some time in future workflows, you can save this configured UDA as a snippet.  Just add an Action set action and put the UDA within it.  Then save that as a snippet.  This way you can add that snippet to future workflows, and it will already be setup and create your logging variable for you as well. 

 

Run If Setup

The key to this solution is putting your logging actions within a Run If action that only runs if the logging is turned on.  The first time you setup a workflow you'll need to create your Run If action using the UDA output.  Setup the Run If to only run if the Logging variable is equal to "On".  

Run If Setup

 

Now within the Run If action you can add any type of workflow logging that you want to do.  

Create Logging Snippet

You don't want to have to setup a Run If each time you want to log something.  So the first time you setup the Run If, you'll want to save it as a snippet that can be reused.  To do this, add an Action Set action, and put the Run If within it. Within the Run If, I also add an empty Log in history list action.  This way it's already there when I add the snippet.  Click on the Action set menu and save as a snippet.  Name it something that will be easy to remember in the future.  I called mine "Log if Logging On".     

 

Complete Workflow Setup

 

When you need to add a logging action to a workflow in the future, just go to your snippets and insert your saved Logging snippet, and then setup what you want to log. 

Insert Logging Snippet

 

 

 

Conclusion

With this setup in place, you now have a Debug Mode for your workflows that you can turn on or off from a list.  When you create a new workflow, all you have to do is insert two saved snippets and you're ready to go.  Once you have a workflow built and ready for production, all you have to do is go to the configuration list and set the logging status to "Off".  If an issue comes up in the future and you needed to debug it, you can just as easily turn it back on.  No more having edit the workflow and manually turn off or on each workflow logging action.  Try it out and let me know how it works for you.   

 

References

Tips on Debugging Workflows 

Using Workflow Configuration Lists in O365 

Demystifying Workflow History (Part 1) 

User Defined Actions

Filter Blog

By date: By tag: