(Looping) Timer Workflows Using SharePoint

Timer Workflows

It is often a requirement of a Workflow in SharePoint to monitor and respond to various dates such as a start or due date.

If the timer is not the main function of a Workflow, it can be created as a separate Workflow to that both can run in parallel with full functionality.

Looping Timer Workflows

To have a looping timer workflow (eg. send a daily notification/reminder until a specific condition is met), the workflow must start when an item in the list is changed, and when it is created depending on the scenario.

At the start of the workflow, test if the required condition has been met, and stop the workflow if it has. If the condition has not yet been satisfied, the workflow can continue.

As the workflow will initiate after an item is modified, it is possible for multiple instances of the same workflow to be initiated. To prevent this, a custom (boolean) field is added to the list which is used to determine if an instance of the workflow is already running. When the workflow starts, it first tests if the value of a custom field (eg. "timer_waiting") in the current item is set to true/yes. If true, another instance of the workflow is already running and the current can be stopped. If false, the custom"timer_waiting" field can be set to true/yes to stop new instances from starting until the current is complete.

If the workflow is to continue, perform the required date calculations (current date + 1 day), store in a workflow variable, then wait until the date determined. Send the email, or perform other actions after the workflow has finished waiting (next workflow step).

To complete the workflow, set the field in the current item "timer_waiting" back to false/no to allow a new instance of the timer workflow to start.

If the SharePoint (MOSS 2007) Server has no service packs installed or Service Pack 1 only, updating the field in the current item workflow will cause another instance of the workflow to start, creating the looping functionality. If service pack is installed, a separate list must be used to trigger the first again to enable looping workflows.

For more information about looping workflows in general, as well as the changes to looping workflows made when Service Pack 2 is installed, see Service Pack 2 prevents an on-change workflow from starting itself.

Related Articles

SharePoint Looping Workflow - How to: Loop through and process all items in a list

"The OOB workflow actions provided by SharePoint don't allow a loop to be configured explicitly. Instead, a number of workflows can work together to create a looping affect. Another limitation of Workflows in SharePoint using SharePoint Designer (SPD) is the inability to simply test if the user who initiated the workflow is a member of a SharePoint group, or to test if the value of a field in the item which initiated the workflow is equal to the value of a specific field from any item in a separate list."

How to wait for a change in any list, wait for multiple field changes in the current item (SharePoint Workflow)

This article describes techniques which can be used when developing workflows in SharePoint using SharePoint Designer. They allow a workflow to wait for a field change in an item in another list, or to wait for multiple field changes in the current item before continuing.

SPD Workflow - Test if value exists in any item in SharePoint list - create new item if not found
SharePoint Designer Workflow: How to test if a specific value exists in any item in a list without the workflow stopping due to a "List item not found" error if no items exist with the required value.

How to configure a workflow to start at specific time, then loop / repeat periodically (Daily, Weekly)
The following method can be used to start a workflow at a specific time, then repeat periodically (each day). Periodic Workflow Processing: (send daily email notification or reminder)
A useful implementation of this technique allows you to configure workflows to run as background tasks at a specific time instead of being triggered by a user manually, or after creating or modifying a list item.

SharePoint Workflow Errors: Descriptions, resolutions and Workarounds
The following table lists some of the common errors that can occur in a Workflow developed using SharePoint Designer. A short description of some of the likely causes for each error are also provided.

InfoPath Error - Updating Content Type Failed When Publishing to SharePoint

When Publishing an InfoPath Form to a SharePoint site Content Type, the process may fail when trying to Update the Site Content Type if there are a large number of fields being promoted to SharePoint columns/fields in the Content Type with an "Updating Site content Type Failed" message.

One solution for this is to create a separate list with a lookup column/field back to the list which uses the Content Type created by InfoPath. The fields which are removed from the Content Type can be added to the separate list instead.

When the InfoPath Form is submitted, rules can be configured to create or update an item in the separate list which corresponds to the form being submitted, with the additional data.

How to Solve:

1. Make a full backup the InfoPath Form Template and the SharePoint Site (Content Types, Lists, etc.)

2. Choose which fields to add to the separate list instead of promoting/submitting with the form data.

3. Remove the fields from the list of promoted fields (Tools -> Form Options -> Property Promotion - or remove the fields when you next publish the form)

Note: Enough fields need to be removed to allow the form to be published successfully, as well as consistently. At this point, if you can't get the form to publish to a Content Type without receiving an "Error updating Content Type" (or similar) message by reducing the number of promoted fields, then the problem is caused elsewhere and the solution in this article will not apply.

4. Add a CAML XML template Data Connection to store the data required to add or update an item in the separate list. See InfoPath - Update Existing SharePoint List Item Programmatically Using CAML for details.

5. Add event handlers or and a main function to populate the CAML template with the data required to create or update an item in the separate list. See InfoPath - Update Repeating Elements/Nodes in a Secondary Data Source for details.

6. Create a Submit Data Connection which uses the UpdateListItems Web Service and the CAML template (created in Step 4) to create or update an item in the separate list. See InfoPath - Update Existing SharePoint List Item Programmatically Using CAML for details.

7. Configure rules to submit the CAML template using the Data Connection created in Step 6, then submit the form using the main submit data connection when the form is submitted. See InfoPath - Update Existing SharePoint List Item Programmatically Using CAML for details.

InfoPath Tip - Show text field if user selects other

InfoPath Basics - Display text box if user selects Other using conditional formatting

Promote two fields to a single SharePoint or Database column/field.

This article demonstrates how to configure an InfoPath form to display an optional text box for the user to enter a custom value if not available from the list of options. A separate field in the main data source of the InfoPath form will be used to store the value of the selected option, or the custom value if supplied by the user. Rules are set up to set the value of the separate field in the data source when an option is selected or when a custom value is entered into the text box.

When submitting the form, the text field with either the value selected, or the optional text input entered if the user selects other can be promoted to a single SharePoint column, or database table instead of promoting both the option field and the text field containing the "Other" value if selected.

Conditional formatting is also used to hide the text box until the user selects "Other" from the list of options.


Process:

Set up the Initial InfoPath Form

1. Design a new form template using InfoPath 2003 or 2007

2. From the Task Pane (CTRL+F1), open the Controls toolbar

3. Double click, or drag an Option Button control onto the default view of the form template. Enter the number of options required (remember to add an additional option for "Other").

Note: In this example, the Option Button will have 5 options including "Other".

The name of this field in the Main Data Source will be "Options"

4. Right Click the first Option and select "Option Button Properties..."



















5. Enter a Field Name for the field. Note: You only need to set the field name on one of the options for it to be applied to all.

6. Enter the value which will be used when this option is selected for the "Value when selected".

7. Press Ok

















8. Repeat Step 6 for each option. Enter "Other" as the value when selected for the final option.

9. Add a text field control to the form template (main data source) for a user to enter a custom value if required.

Note: In this example this field will be called "Other".

10. Add a separate text field to the form's Data Source only to store the selected value, or the value from the "Other" field by selecting "Add..." from the menu after right clicking the "myFields" group.

Note: For the purpose of this article, this field will be called "OptionSelected". This field does not need to be added to the form template. This field will contain the selected value from either the "Options" field or the custom value from the "Other" text field if required, and is explained further in the article.

Add Conditional Formatting to hide the "Other" text field when it is not required

11. Right Click on the "Other" text field control on the form template.
12. Select Conditional Formatting...
13. Press the "Add..." button to add a condition
14. Select the "Options" field created in step 3, "is not equal to" for the condition, and a text value of "Other" to test against (Select "Type text..." from the options).





15. Tick the "Hide this control" option for the formatting to be applied.









The "Other" text field will now only be visible when the user selects the "Other" option radio button.


Create Rules to set the value of the separate text field to be submitted with the form

15. Right click on any of the Radio Button options and select "Rules..."

16. Click "Add.." to create a new rule for this field.

17. Set the condition to the "Options" field, "is not equal to", Type "Other" as the value to test against.

18. Click the "Add Action..." button.

19. Select "Set a field's value" from the list of Actions

20. Select the "OptionSelected" field from the Main Data Source for the "Field" option

21. Select the "Options" field for the "Value" option.














This rule will now set the OptionSelected field to the value selected by the user if "Other" was not selected.

22. Right Click on the "Other" text field and select "Rules...", Click "Add..." to create a new rule for this field.

23. Set the condition for the rule to the "Options" field, "is equal to", and "Other" for the value.

24. Click the "Add Action..." button.

25. Set the Action to "Set field's value"

26. Set the "Field" option to the "OptionSelected" field

27. Set the "Value" option to the "Other" text field (current).














28. Right click on the OptionSelected field in the Main Data Source and set the default value to the default value of the "Options" field.

This will ensure that the OptionSelected field will always have a value in the case that a user submits the form using all default field values (rules would not have been applied as no changes we made to fields in the form's Data Source). If using the Options field as the default value as apposed to typing a specific default value, you will need to un-check the "Update this value when the result of the formula is recalculated" option to prevent the OptionSelected value being overwritten to equal the selected value of the Options field when an option is selected (rules are used to set the value of the OptionSelected field as explained above).

Conclusion

When a user selects one of the options available, but not the "Other" option, the value selected is set as the value for the separate text field created using rules. When the user selects "Other" from the options, the "Other" text field will become visible for the user to enter a custom value. When the user enters a custom value into the "Other" text box, rules are also used to set the selected value as the value for the separate text field in the main data source.

The separate field will always contain the value selected or manually entered by the user, which when promoted to a SharePoint or database column instead of promoting both the option button control and the "Other" text box. The separate field does not need to be added to the form template, as the value of the field will be set using rules when a user changes a value when completing the form.