Skip to main content

Configurations lists within a workflow process can make any workflow more dynamic in nature. It allows workflows to always have the latest information to make correct decisions. They can also effect workflow that are in-flight, or already started. We have been using this practice for many years and have continued to use them in O365. I came across a scenario while using configuration lists to gather the current person who should approve a task. Over time, this approver can change for various reasons. In order to prevent continual updates being made to a workflow to simply change who to assign a task to, a config list was put in place. In this article, I will show how to create a config list for a workflow, and how to gather a person value using two methods. 

 

Configuration List

Most config lists are simple custom lists. From Site Contents you can select new to create a list if in Modern UI, use the gear menu and click "Add an app" then choose custom list, or in classic view go to Site Contents, click add an app, then choose Custom List.

Now that the list exists, set it up as a Key/Value pair. So the key, or the identifier of the record will be the Title field of the list. Create additional columns of what ever type you need, such as additional single line of text fields, person group fields, dates, etc. In my case, I created a person field and called it Approver. I then filled in a few items

Title Approver
Type A Jim Smith
Type B Sam Snead
Type C Jimmie Johnson

 

Workflow

On my SharePoint list for Work Orders, I have a workflow that eventually will have an Assign a Task action. The Participant will be filled by the value determined by the configuration list, and not "hard coded". My first step is to create a Person variable I named pgApprover. 

 

Assign using Set Workflow Variable

The quickest way to get a person variable set is to use the action Set Workflow Variable. NOTE: This method only works in Office 365. This action allows for List Lookup that we don't have access to on-prem. So let's use this to our advantage.

196144_pastedImage_8.png

I then configure the action to assign my variable the value found when I look in the config list for the approver WHEN the current item's type is equal to a field in my form - work order type.

196145_pastedImage_9.png

This will give me approver Jimmie Johnson when my SharePoint list item form had the WorkOrder Type dropdown set to Type C. 

 

And that's it! Now I can change the approver any time I want and current running workflows that have yet to get to this action will pick up the current setting, and of course so will any future workflows.

 

Assign approver using Query List

Now I found myself naturally going to the Query List action to get the value from the config list. I would if I was using Nintex 2013 or 2016. And in O365 it would be OK to use if I wasn't fetching a person value. But because I need a person field type to assign to a variable, I found a unique case I wasn't prepared for.

 

Query List action returns values in Collections, and you would normally set the column to return and move on expecting your values in the filter to be provided. If I choose a date type field, this is the action configuration

196146_pastedImage_13.png

But when you choose a Person field type, you get an additional option to select the property to return. This is important to do because a Person field has 30 property types that can be in the result. I chose User name because I need to assign a Person variable and that type works best.

196148_pastedImage_15.png

196149_pastedImage_16.png

At this point you will have a collection "colApprover" set to the person that matches the type on the current item "WorkOrder Type".

 

But it's not a person data type!!

It turns out that the output for a person field using the Query List is a dictionary within a dictionary saved into a collection! This is highly confusing and I will break it down for us. 

 

The value returned is e{"Approver":{"UserName":"jimme.johnson@7time.com"}} ]

  • The collection is noted with the o]
  • The outer dictionary key is Approver who's value is the dictionary {"UserName":"jimme.johnson@7time.com"}
  • The inner dictionary key UserName who's value is jimme.johnson@7time.com

 

So how do we get the value jimme.johnson@7time.com into our person variable? We use three more actions!!

 

  1. Get Item from Collection
    1. To Output to a variable dictApprover from Target Collection colApprover 
    2. This gives us the outer dictionary from above
  2. Get an Item from a Dictionary
    1. To Output to a variable dictUserName from Dictionary dictApprover
    2. This gives us the inner dictionary from above
  3. Get an Item from a Dictionary
    1. To Output to variable pgApprover from the Dictionary dictUserName

196150_pastedImage_18.png

 

Conclusion

Configuration lists used for workflow manipulation are key to strong, dynamic workflows. Hopefully this article helps outline how to use actions to get the data you need from them. But also if you are in a scenario where you have to use a Query List action, use the above techniques to get the value out of the collections. But maybe seeing that you can use the Set Workflow Variable action will save you some time!

 

Leave a comment if you have any questions. Hope this helps somebody! Thanks for reading!

 

 

I'm a huge fan (as many of our fellow workflow builders are as well!) of using lists to store WF context data (approvers, costs, etc, etc.) so this is a fantastic write up, ‌.

Thanks for sharing with the community! 


I've always taken this approach for my workflows. I call them Managed Lists. It allows me to hand over admin of the application to a product owner who needs no technical expertise in workflow, they can just change the lists as required to manage configurations within the application. Gives the finished product much more of an "application" feel as well. Tie those lists down so only the admin can alter them and away you go. Can use it for all sorts of things as well, so in an app I wrote for Personal expenses, I used this same approach to allow the admin to update the thresholds for approval, meaning, if the company changed it's policy on how much could be claimed before a certain level of authorization was required, then they could just change this list, no need to contact IT.

Good blog detailing this. 


I'm hoping this can also be as a reference to using the Set Workflow Variable method to get the data. Since the approach is different in O365, you can find yourself trying to match it to on premise and see that it is much simpler. I wonder if I need to copy this into another discussion so as to call the process out separately from the managed list idea? Like a process best practice


Brilliant write-up Andrew.  This is an often overlooked method of dynamically "modifying" the course of a workflow.  ‌ - I wonder if we can make a category/forum called "best practice" and put articles like this in there?


Yes, please do. Even better would be to demonstrate selecting a list of approves to be assigned as participants in a "Start Task Process" action.


amazing article ...thanks for sharing!! 


Reply