Hello there.  If you're reading this post, I hope that you had the opportunity to read Part 1: Work Flow Purpose.  and Part 2: WWYSYDH​.  In part two of this series, I introduced the concepts of using the right actions to get the right results.  At the end of it I promised to go even deeper and provide an example Training Calendar solution for you with a list and workflow incorporating what I've been covering in this series.  Well, I did it.  I built it all out, typed this long blog, included screenshots and even remembered to attach the files.

I will say this post is rather lengthy, but no solution is good without documentation and I wanted to explain each step so you would learn as you went along.  If you’re as excited as I am…let’s get going!

Part 3: Meet Mr. Wilson.

Scenario: I had a customer, whom I will call Wilson.  Wilson called me one day with an issue using his workflows.   He had been working on a calendar list for training and was wanting to make it automate notifications when training events are created, updated or canceled.  He also wanted to setup a reminder notification to be sent out one day prior to the events start date.

Seems easy enough right? So let’s see why I’m using Wilson as an example for my blog.

Outside of the obvious that he’s a celebrity and has been coveted since his debut in Castaway, Wilson has some things he wants to do better.  What I discovered when I look at his SharePoint site was quite interesting. Not bad, just….well that’s the reason he called me.

So let’s see what Wilson did…

Wilson created three workflows for each scenario listed above.  He had a workflow running when a new event was created, a workflow when the event was changed, and a workflow when the event was cancelled.  Are you seeing what I’m seeing? That’s slight overkill for the events and his process.  Not a bad thing, and he certainly can do that, but that makes things difficult if he’s wanting to be efficient.  Hmm… let’s keep going.

If you remember, Wilson wanted to send a reminder out for the day before the events date to remind attendees.  The problem that he was facing was trying to send the reminder without causing the other workflows to fire which would send additional notifications.  Okay, I can see how this can occur, so how am I going to fix that?  Just for your reading pleasure, there wasn't anything special about his list, it was a standard out-of-the-box Calendar list, and I attached a copy below for you.

So where did I start?

I needed to get him the reminders and as an added benefit, eliminate some redundancy?   I also knew he had a busy schedule with interviews and special appearances and didn't need to spend so much time managing three workflows.  This is too much fun writing about Wilson, but he is enjoying the press as well. So keep reading...

Here’s how I approached it.

Step 1: Assess the purpose and the logic

My first step was to look at his workflows.  After realizing they were all similar I knew I could eliminate one of them easily. The image below shows what actions were in his workflow (nothing spectacular):

So as you can guess, Wilson had three workflows that would run on new item creation and on changes to the item.  I knew that was part of the problem, so I wrote out the logic using the DUCERIM Process worksheet to be sure I didn't redo his looping affect:

1. Notify a group of people when a new event was created
2. Notify a group of people when the event was changed/updated
3. Notify a group of people when the event was canceled

Step 2: Reconfigure the logic to ensure efficiency (2 workflows instead of three)

My next step involved two separate things.  The first part of step 2 was to reconfigure the New Event Workflow settings to ONLY run for new events.  This is important because by doing this I could then isolate the logic of what happens when the event is new.  See the workflow setting below:

How are you doing so far? I hope you’re following my logic; at least it made sense to me and Wilson at that time :-).

My rationale is that I know when a new event is created in SharePoint, it can only be a “New Item” once.  This means I do not need any additional conditions to be checked or validated against. I also added in a status column so that when things are changed, the workflow running on modified would know what to do with that information as well.  This possibly could be eliminated, but I left it in here for my own sanity. 

The results of the reconfiguration produced the following workflow that only runs once when the event is first created. 

New Event Workflow Explanation

The workflow runs on new > sends a notification to the appropriate group > updates the item’s status > calculates the pause date, pauses until the pause date > sends the reminder notification.

Wow!!! So why did I build it this way?

As I mentioned this workflow is solely meant to run once, and if nothing else happens to this event, such as an update or change, this is the only workflow that will run.  Therefore adding the pause until made sense because I can pause the workflow until the day before the event’s date and then have it run again to send out the reminder.

So I got this one done, now what?  Well, I had to test it to make sure I had it built correctly.  After running through two events, Wilson was quite thrilled to see the reminder working as well.

The second part of step 2 was to get the Changes and Cancellation Workflow built out correctly.  My challenge here was to fix the logic of one workflow, and if possible eliminate the other workflow.

Let’s see how I did that…

Ideally I wanted this workflow to ONLY be triggered when the event is modified.  This is important because this isolates my logic to a certain action that I know and can plan for and wont cause this one to run when the event is new.  To achieve this I modified the Workflow Settings and ensured that it only ran on event was modified.

The next thing was to keep the actual workflow process simple.  I decided to use the run parallel actions. This gave me the chance to run both conditional test simultaneously and only complete the correct action each time. I know some people would try to use the run if action and you could do that, but I like to try and keep process as simple as possible and keep my workflow as short as possible.

After I figured that part, I used the set a condition action because I wanted it to do a single task; check the status field for either “Change” or “Canceled”. Based on the status it would then perform the remaining actions accordingly. For a modified event to be considered a change, the user could update the event item, and change the status to reflect that it was changed.  The logic I was aiming for was to have the workflow process that change.  See the image below.

The next part was processing for Cancellations. Hmm... I already had the actions that I wanted to use for changes, and technically the cancellation is very similar to the change so I did this:

Hidden below is a BIG TIP and one reason I absolutely love Nintex.

I know that set a condition is similar to an action set in that it groups all the actions underneath it.  So I simply clicked on the little down arrow to the right of the set a condition action and selected copy.  I then went over to the branch on the right, click on the little node and selected paste.  I hope you caught that tip (you can copy and paste actions).  Literally within 2 seconds I had the same actions in both branches and all I needed to do was to configure the right side branch to process for Cancellations.

I want to see you do that with a SharePoint Designer Workflow. Oh wait…you can’t .

Wilson was also impressed by how quickly I had this logic built out.  So lets keep going, we’re almost finish with this workflow.

I removed the first send notification, the calculate date and the pause until actions as I didn't need those for a cancellation.  Since an item was canceled, I wanted to show the users that it was canceled.  This would help them identify the canceled events from the current ones.  I decided that to achieve this I would update the title of the event by appending “- canceled by Initiators Name” to the end of it.  That was it, and I was able to achieve that by using the update item action.  After that action, it would send the notification to all attendees and end.  Think that’s cool, see below:

I now how all the information and logic correct, both branches are filled out and it seemed to be legitimate; however, a workflow that is not tested is not a good workflow.

Testing the Change and Cancellation Workflow:

To test this one accurately, I took an event previously created for the New Event test and I modified the event dates, added a different description just for fun, and set the status to “change”.  I knew I could do this because the logic of this workflow would only run when an event was modified. I also knew that the New Event workflow would not run again so this event was a safe test.

The results of this was as expected.  I received the first notification that the event was changed, then it paused until the notification date.  Because I ran the pause for the same day, I received the reminder 5 minutes later which told me that it worked as it should.  If nothing else changed on this event, that would be the only time it would run and complete.

The next test was to take another event that I had created and process it for canceled.  For this I simply edited the event and changed the status to cancel. Seems simple right.  The results again were successful.  That means I had a good workflow and I can now reveal it to you.  Here is the complete workflow altogether.

Conclusion:

Well that’s it, I had two workflows running and notification being sent to the attendees at the right times, but my job wasn't quite done.  While I did leave Wilson quite speechless with how nice it turned out, and how fast I built it, I couldn't leave his site in that manner.

What I mean is that I had test data out there and it needed to be cleaned up.  So in following the DUCERIM process, I went through and purged the workflow history along with the items in the events calendar that I had created.  This allowed Wilson to start with a clean slate and get back to whatever he was doing before he called me.

I hope you enjoyed this fun but real life example of using Nintex to achieve an automation process with a Training Calendar.  There is a lot more that I could have done from adding a registration component, ensuring only active events are showing and so much more; but this was long enough. If you want to know more about the DUCERIM process or have questions, ask me and happy #nintexing.

Thanks,

Eric

P.S.  I may have a Part 4 but who knows...