Introduction

In SharePoint 2013 Designer, SharePoint 2013 workflow now comes with a new feature called Loop where a series of actions are executed repeatedly for as long as the specified conditions are met. However, with the correct set of conditions and actions the same be achieved in SharePoint 2010 workflow as well. In this article I am going to provide a step-by-step detail of how a loop workflow can be built using a custom SharePoint 2010 list, SharePoint 2010 Designer and InfoPath 2010 designer. In this example a Site collection with SharePoint 2010 Enterprise feature has been enabled.

Setting the Scene

A legal department needs a custom list, form and workflow where businesses can submit contracts to be reviewed and approved. The forms and workflow should provide the option to return the contract back to the requester for further information or for negotiation purposes. Below is a diagrammatic view of the workflow

Custom List

I have created a custom list called Contract Requests. I then created a SharePoint group called Attorneys and given them Contribute access. I have added all the attorneys to this group. In the List Settings under General Settings click on Versioning settings as shown below.

Below is a screenshot of the Versioning settings. For this example I have set the limit as 16, however, you can change that to your discretion. This setup is necessary for the cascading comments added by end users to the items throughout the life of the contract workflow.

Below is a screenshot of all the custom columns I have created for this list.

For the Choice columns, I have provided the choices as shown below.

Current Status Choices:

  • New
  • Pending additional information from requester
  • Request submitted
  • Sent to attorney
  • Attorney reviewing in process
  • Negotiating terms
  • Attorney review completed
  • Contract executed
Current WF Status Choices:
  • New
  • In-Progress
  • With Emily
  • With Attorney
  • With Requester
  • Completed
Below are screenshots of Action Required, Attorney and Loopback Control columns

I have also created 9 different views for this list, 8 views match the 8 different choices in the Current Status column and the 9th is In-Progress view. 

Below are screenshots of the filter I have applied for the In-Progress view.

Building the Forms

This section talks about building the web based form built using InfoPath designer 2010. This form is going to have the following 5 views.

New Form view

Requester View

Legal Administrator view

Attorney View &

Completed view.

Specific conditions are going to be applied based on which the forms will displayed. These conditions are met at a specific step of the workflow. Hence the views of the form are dependent on the workflow. Open the list in InfoPath Designer 2010 directly from SharePoint using the Customize Form option from the ribbon. This option is available only in the SharePoint Enterprise feature. The initial view of the form is as shown below. Notice the Action Required field is now a Repeating Section. This is why we turned on the Versioning Settings as shown before.

I am going to add all the controls and title in this default form and then make copies of it to make custom forms. In the forms I am going the delete the titles and controls not needed. Also, the cancel button for all the views have the same action which is to close the form hence I am going to add that action in the default form.

Below is a screenshot of the default view shown both in InfoPath designer and the web form. I have also provided a screenshot of the cancel button action.

InfoPath Designer

Web based form

Now we are going to build the 5 custom views. The key idea I want to describe are the fields viewable and the Manage Rules I have setup on the Submit button for each of the Views. As I stated above all the cancel buttons have the same action hence I made that one time change in the original default form.

New Form View

 Below is the look and feel of the new form view.

 

Click on the Submit button and add an Action Rule. Give it a name that makes sense such as 'SubmitButton'. Do not make any changes to the condition. Add three actions, 1st set Current Status = 'Sent to Attorney', 2nd Submit data and 3rd close this form. Below is a screenshot

Legal Administrator View

Below is the look and feel of the Legal Administrator view. As you can see we have added the 'Current Status' and the 'Attorney' columns.

Click on the Submit button and add an Action Rule. Give it a name that makes sense such as 'SubmitButton'. Do not make any changes to the condition. Add three actions, 1st set Current Status = 'Sent to attorney', 2nd Submit data and 3rd close this form. Below is a screenshot

Requester View

This view is built for the requester when the contract request has been re-turned back for either more information or for negotiation. Below is the look and feel of this view

Click on the Submit button and add an Action Rule. Give it a name that makes sense such as 'SubmitButton'. Do not make any changes to the condition. Add three actions, 1st set Loopback Control = '1', 2nd Submit data and 3rd close this form. Below is a screenshot

Attorney View

Below is the look and feel of the attorney view which is very similar to the legal administrator view. 

Click on the Submit button and add an Action Rule. Give it a name that makes sense such as 'SubmitButton'. Do not make any changes to the condition. Add two actions, 1st Submit data and 2nd close this form. Below is a screenshot

Completed View

This view is meant for viewing contracts that have completed its transaction process. The submit button is purposefully removed since no changes need to be made anymore. Below is the look and feel of the form

Form Load Rule

In this section I will describe the Action rules to display the form which is relevant to the workflow. Below are the conditions setup using Form Load as shown below

New Form View Rule

We always want the new form to be loaded when a new contract is submitted hence the condition is setup such that when the Current Status & Current WF Status = 'new', open the New Form.

Legal Administrator Form View Rule

When the form is opened by the legal administrator, we want the legal administrator view form to be used hence the condition is setup such that when the Current Status = 'Request submitted' OR 'Attorney review completed', open the Legal Administrator form. 

Requester Form View Rule

During the workflow the contract is sent back to the requester, at that point we want the requester to view the requester form hence the condition is setup such that when the Current Status = 'Pending additional information from requester' OR 'Negotiating terms', open the Requester view form. Below is a screenshot

Attorney Form View Rule

When the form is opened by the attorney, we want the attorney view form to be used hence the condition is setup such that when the Current Status = 'Sent to attorney' OR 'Attorney reviewing in process', open the Attorney view form . 

Below is a screenshot 

Completed Form View Rule

Finally, when the Current Status = 'Contract executed' load the Completed view form.

Form Videos

Below is a video I have created which shows you the rules setup for each Submit button and the Form load rules.

(Click Here to view the video in high resolution)

Below is video I have created to test the views of the form.

(Click Here to view the video in high resolution)

Building the Workflow

Below is a screenshot of the entire workflow which provides an overall view of all the conditions and actions which are sequenced to give you the loop effect. I have renamed the steps with titles that make sense. Current Status and Current WF Status are the two control columns. The Current WF Status controls the step of the workflow, the Current Status controls who is currently working on the contract. It is important to understand that the Current WF Status could be with someone, say, 'Daniel', but the Current Status is someone else.

Workflow Videos

I have now provided three videos. The first video is a perfect world scenario where the requester submits the contract, the office administrator reviews the contract, forwards it to the attorney, the attorney reviews the contract,

the attorney sends it to the requester for negotiation, the requester approves it and returns it back to the attorney, the attorney forwards it to the legal administrator and the administrator executes it.

(Click Here to view the video in high resolution)

The second and third video is a realistic world scenario where the requester submits the contract, the office administrator returns it back to the requester for changes, the requester makes the changes and returns it back, 

The office administrator forwards to the attorney, the office administrator sends the contract back to the requester during the reviewing step, in the reviewing the contract step the attorney sends the contract back to the requester a few times, in the negotiating step the attorney sends the contract back to the requester a few times and then forwards it to the office administrator who then executes the contract

(Click Here to view the video in high resolution)

(Click Here to view the video in high resolution)

I am going to break the explanation of the above workflow into 8 separate parts.

Contract submitted

Returned to requester (Loop conditions)

Sent to attorney

Reviewing by attorney

Returned to requester by attorney (Loop conditions)

Negotiating terms (loop conditions)

Attorney review completed

Contract executed.

Contract Submitted

This set of conditions and actions forces the following actions to be run only once at the beginning. This is why the initial choice of the Current WF Status column was New.

Below is the a screenshot of the item that is updated. These updates are very important. Without these updates the workflow will either not run at all or the logic will not match our requirements. The InfoPath form updates the Current Status to 'Request submitted' and this action updates Current WF status to 'With Daniel'. At this point we have to wait for the administrator to decide if he/she is going to return the contract back to the requester or send it to the attorney for Reviewing.

Below is a screenshot of the body of the email which the requester and the legal department's administrator will receive.

Returned to requester (Loop conditions)

This step is where the loop condition is first applied. 

If the administrator has decided to return the contract back to the requester then the below two sets of conditions and actions take effect. As you have seen in the video, the administrator will select the 'Pending additional information from requester' and submit. Also, the default value of the Loopbackcontrol column is 0. Hence all the three conditions match and hence the below workflow runs. The workflow then has to wait until the Loopbackcontrol value is not equal to 0.

When the requester makes the changes and submits the form, the loopback control value is set to 1 and hence the contract is returned back to the administrator. This transaction process between the administrator

And the requester can occur as many times as needed.

Below is a screenshot of the two conditions and actions.

Below is a screenshot of the Update item when the requester has made the change and hits the submit button. I have highlighted that action yellow. As you can see, I have set the value of the loopbackControl back to 0 This way the loop process is ready for a re-use.

Below is a screenshot of the email when the requester received the email, the email sent by the administrator.

Below is a screenshot of the email body when the legal administrator has received the email after the requester has made the change.

Sent to Attorney

Once the administrator has completed his/her task, an attorney is selected and the current status is changed to 'Sent to attorney'. Below is a screenshot of the workflow

Below is a screenshot of the update item action

Below is a screenshot of the email which is sent to the attorney

Attorney Reviewing

The attorney to whom the contract has been sent, has to change the status to Attorney reviewing. The primary reason for his change is to record the timing. No emails are sent out during this step. Below is a screenshot of the step

Returned to Requester by Attorney

This step is very similar to the 'Returned to requester' by administrator. This step is where the loop condition is applied the second time. 

If the attorney has decided to return the contract back to the requester then the below two sets of conditions and actions take effect.

As you have seen in the video, the attorney will select the 'Pending additional information from requester' and submit. The Current WF status is 'With Attorney'

Also, the current value of the Loopbackcontrol column is 0. Hence all the three conditions match and hence the below workflow runs. The workflow then has to wait until the Loopbackcontrol value is not equal to 0.

When the requester makes the changes and submits the form, the loopback control value is set to 1 and hence the contract is returned back to the attorney. This transaction process between the requester and the requester can occur as many times as needed.

Below is a screenshot of the two conditions and actions.

Below is a screenshot of the Update item when the requester has made the change and hit the submit button. I have highlighted that action yellow. As you can see, I have set the value of the loopbackControl back to 0. This way the loop process is ready for a re-use.

Below is a screenshot of the email when the requester received the email, the email sent by the attorney.

Below is a screenshot of the email which is sent to the attorney, the email is sent by the requester.

Negotiating Terms

This step is very similar to the 'Returned to requester by attorney'. This step is where the loop condition is applied the third time. 

The contract is currently in the negotiation step. When the attorney has decided to return the contract back to the requester then the below two sets of conditions and actions take effect. As you have seen in the video, the attorney will select the 'Negotiating terms' and submit. The Current WF status is 'With Attorney'

Also, the current value of the Loopbackcontrol column is 0. Hence all the three conditions match and hence the below workflow runs. The workflow then has to wait until the Loopbackcontrol value is not equal to 0.

When the requester makes the changes and submits the form, the loopback control value is set to 1 and hence the contract is returned back to the attorney. This transaction process between the requester and the requester can occur as many times as needed.

Below is a screenshot of the two conditions and actions.

Below is a screenshot of the Update item when the requester has made the change and hit the submit button. I have highlighted that action yellow. As you can see, I have set the value of the loopbackControl back to 0 this way the loop process is ready for a re-use.

Below is a screenshot of the email when the requester received the email, the email sent by the attorney.

Below is a screenshot of the email which is sent to the attorney, the email is sent by the requester.

Attorney Review Completed

This step is run after the attorney has completed the negotiating process with the requester and sending the contract to the legal administrator.

Below is a screenshot of the step

Below is a screenshot of the update item action

Below is a screenshot of the email sent to legal administrator by the attorney

Contract Executed

This is the step where the legal administrator ends the workflow by executing the contract. In this step, the requester is sent an email and the contract end date is record.

Below is a screenshot of the workflow.

Below is a screenshot of the Update item action

Below is a screenshot of the email sent to the requester

Conclusion

We have kept this example simple to explain the conditions and actions using the Current WF status and Current status control columns. In this example we have kept the versioning settings to 16, however, if you anticipate the three loop process used several times then you might want to consider increasing that number.

This workflow can also be used in SharePoint 2013 if the SharePoint 2010 workflow option is selected. 

See Also