Skip navigation
All Places > Getting Started > Blog > 2014 > October
2014

Thanks to Sean Fiene for assistance.

 

Below is an example of how to perform Validation on specific controls based on their dates.

 

The goal: If start date is less than or equal to 11 days from today and\or If start data is more than 7 days before end date than prevent the form from being submitted.

 

Step 1:

Create a list with a “Start Date” and “End Date” column of data type “Date and time”.

 

Step 2:

  • Open Nintex Forms and choose “Forms Variables” from the ribbon bar.
  • I named my variable ‘varStartDate”
    • Type: Integer
    • Connected To: Not Connected
    • Recalculate formula on view mode: No
    • Recalculate formula on new mode: Yes
    • Recalculate formula on edit mode: Yes
    • Formula: dateDiffDays(Current Date, StartDate)

1.png

 

Under the Formula Builder we choose “dateDiffDays” under the Runtime Functions tab and “Current Date” under the Common Tab. The “StartDate” is located under Named Controls tab and will vary depending on what column you are referencing in your list.

2.png

Step 3:

Select the “End Date” control and click “Add Rule”

3.png

Step 4:

Under the Rules window create a Validation Rule:

  • Name: DateValidationRule
  • Rule Type: Validation
  • Condition: (varStartDate <= 11) || (dateDiffDays(StartDate, EndDate) >= 7)
  • Message: The Start Date is less than 11 days from today or the end date is less than 7 days from the start date, please update the appropriate date.

4.png

Under the Formula Builder for the Condition we choose to add the “varStartDate” from the Forms Variable Tab, and stated if the varStartDate is less than or equal to 11 days show the message.

We than state OR if the differences between the start date and end date controls is greater than or equal to 7 days to show the message.

 

Results:

The Results will be that this Validation rule will show the Message to the user when the hit save and these conditions are not met.

From here you can add additional validation or add additional validation rules and have the form show multiple messages specific to the failed validation.

5.png

Thanks to Sean Fiene for assistance.

 

Question: I would like to input a number into a “Single Line Textbox” and have the results show only two decimal places on the View mode of the form.

 

Step 1:

Create a Nintex Form and add a ‘Single Line Textbox’ configured with a Data type of ‘Decimal’ and name of “RoundNumber”

1.png

Step 2:

Add a rule of type “Formatting” with a condition of “Is display Mode” and “Hide”

2.png

Formula builder for condition:

3.png

Step 3:

Under Nintex Forms Ribbon bar choose “Form Variables”

4.png

Click ‘Add’ and create a new variable that includes a formula of ‘Round’ referencing the single line text column of “RoundNumber” and the number of decimal places needed.

Example: Round(roundNumber, 2)

5.png

6.png

Step 4:

Add a calculated Value control to the form with formula referencing the Forms Variable you created in step 3, in my example it is named “Rounding”.

7.png

Step 5:

Create a rule on the Calculated Value Control with formatting condition of “not(Is Display Mode” and choose ‘Hide’

8.png

Step 6:

Align the Single Line Textbox and Calculated value controls on top of each other and publish the form.

 

Results:

Edit Mode:

9.png

View Mode:

10.png

Products: Nintex Workflow 2013

 

 

A common request we see is "How do I cancel/terminate a group of list item workflows that are in a state of 'Error Occurred'?" This article provides instructions on how to accomplish this.

 

 

Run the below (attached as well as a *.txt file for your convenience) PowerShell script (PowerShell ISE works well) from a SharePoint Server:

 

 

PowerShell Script

 

Add-PSSnapin Microsoft.SharePoint.Powershell -ErrorAction SilentlyContinue

function Cancel-SPWorkflow(){
PARAM
(
[Parameter(ValueFromPipeline=$true)] [Microsoft.SharePoint.Workflow.SPWorkflow] $SPWorkflow
)

BEGIN {
  }

END {
}

PROCESS {
        [Microsoft.SharePoint.Workflow.SPWorkflowManager]::CancelWorkflow($SPworkflow)
    }

}

function Get-SPWorkflow(){
PARAM
(
[Parameter(ValueFromPipeline=$true)] [Microsoft.SharePoint.SPListItem] $SPListItem
)

BEGIN {
  }

END {
}

PROCESS {
        $SPListItem.Workflows
    }

}

$(Get-SPWeb http://contoso.com).Lists["DocumentLibrary"].Items | Get-SPWorkflow | where {[String]$_.StatusText -match [String]"Error"} | Cancel-SPWorkflow

 

To use the script, replace http://contoso.com and DocumentLibrary with the URL of the site and list title you wish to execute the script against.

 

For the Site Workflow version of this article go here: How to bulk cancel site workflows with a status of "Error Occurred"

Products: Nintex Workflow 2013, Nintex Workflow 2010

 

A common request we see is "How do I cancel/terminate a group of site workflows that are in a state of 'Error Occurred'?" This article provides instructions on how to accomplish this.

 

Run the below (attached as well as a *.txt file for your convenience) PowerShell script (PowerShell ISE works well) from a SharePoint Server:

 

PowerShell Script

Add-PSSnapin Microsoft.SharePoint.Powershell -ErrorAction SilentlyContinue

function Cancel-SPWorkflow(){
PARAM
(
[Parameter(ValueFromPipeline=$true)] [Microsoft.SharePoint.Workflow.SPWorkflow] $SPWorkflow
)

BEGIN {
  }

END {
}

PROCESS {
        [Microsoft.SharePoint.Workflow.SPWorkflowManager]::CancelWorkflow($SPworkflow)
    }

}

$(Get-SPWeb http://contoso.com).Workflows | where {[String]$_.StatusText -match [String]"Error"} | Cancel-SPWorkflow

 

To use the script, replace http://contoso.com with the URL of the site you wish to execute the script against.

 

For the List Item Workflow version of this article go here: How to bulk cancel list item workflows with a status of "Error Occurred"

In SharePoint 2007 it was fairly easy to obtain the id for a list (the end of a URL when browsing to a list). In SharePoint 2010/2013 this trick no longer works. Below are several methods to quickly obtain the list id:

 

Method A

 

  1. Navigate to the list and click Workflow Settings dropdown.

  2. Select Manage Workflows With Nintex Workflow.

  3. In the browser address bar at the end of the URL you will find the list id (Guid Format).

    Example: http://contoso.com/_layouts/15/NintexWorkflow/WorkflowGallery.aspx?ListId={00000000-0000-0000-0000-000000000000}

Method B

 

  1. Navigate to the list and click List Settings.

  2. In the browser address bar at the end of the URL you will find the list id (Guid Format with URL encoding).

    Example: http://contoso.com/_layouts/15/listedit.aspx?List=%7B00000000%2D0000%2D0000%2D0000%2D000000000000%7D

  3. Replace the following characters as follows:

    1. %7B to {

    2. %2D to –

    3. %7D to }

Method C

 

  1. Open Microsoft SharePoint Management Shell on a SharePoint server in the farm.

  2. Run this cmdlet replacing the URL with the URL of the site containing the list: $(Get-SPWeb http://contoso.com).lists | FT Title, ID

  3. Locate your list and corresponding ID in the results.

 

Planning ahead

 

In addition to creating one to one mappings of Nintex and SharePoint content databases (Covered here: https://community.nintex.com/docs/DOC-1092). Workflow history lists can be created on a one to one basis for each workflow in the environment using the below steps:

 

  1. Navigate to Site Settings \ Nintex Workflow \ Manage workflow history lists. Click New from the ribbon and name the new History List something meaningful like the workflow name and history list. Example: ‘My Approval Workflow History List’
  2. Open the Nintex Workflow Designer and click Workflow Settings. Select the new history list from Workflow Options and click save.
    When you publish/re-publish your workflow all new instances of that workflow will use the newly provisioned workflow history list.

 

Performance

 

Typically we start to see performance degradation when a Workflow History list reaches 2,000 – 4,000~ list items. Even if performance is not noticeably impacted by Workflow History list size, better performance can be achieved by keeping this list size minimal.


When a list has grown too large two approaches can be taken to address the situation:

 

 

  • A new history list can be provisioned and the workflows utilizing the history list can be republished using the newly provisioned history list. Note: Existing workflow instances will complete using the old history list.
    To locate existing workflow history lists in a SharePoint farm, this PowerShell script can be utilized:  How to quickly identify large lists in SharePoint

 

Design Considerations

 

  • Not all workflows may require a separate history list. If a workflow is seldom ran, or if it does not contain actions that log heavily to the history list, they can likely be left to use a shared history list.
  • If a workflow contains any loop logic (loop/for-each/state machines) consider leaving out actions such as ‘Log to History List’ as they can quickly fill a workflow history list if left unchecked.
  • Utilize the History list during the development and testing stages of your workflow and remove or disable them prior to production release.

 

More Information

 

Demystifying Workflow History (Part 1)

How to purge items from a large history list safely via PowerShell

How to quickly identify large lists in SharePoint

Defensive Workflow Design Part 2 - SharePoint Topology

Defensive Workflow Design Part 3 - Separation of Concerns

Defensive Workflow Design Part 4 - Slow Down and Speed Up

Defensive Workflow Design Part 5 - Batching

Products: Nintex Workflow 2016, Nintex Workflow 2013, Nintex Workflow 2010

 

A common cause of workflow failure is large lists, document libraries, task lists and workflow history lists. This article provides instructions on how to locating these large lists.

 

Run the below (attached as well as a *.txt file for your convenience) PowerShell script (PowerShell ISE works well) from a SharePoint Server:

 

The lists returned can be filtered by setting the $threshold variable (default is 200). Additionally, the properties returned can be changed by appending properties to the end of the script (default is ParentWeb, Title, ItemCount).

 

# This will target all Nintex Workflow History lists, you can change the threshold to filter down.
# This is used to find where the lists are and if they are larger than the threshold.
# This will target the entire farm, you may want to scope it down to site collection.

Add-PSSnapin Microsoft.SharePoint.Powershell -ErrorAction SilentlyContinue
#Lists with values higher than threshold will be returned
[int]$threshold = 200
function Get-SPListCollection {
PARAM
(
[Parameter(ValueFromPipeline=$true)] [Microsoft.SharePoint.SPWeb] $SPWeb
)
BEGIN {
  }
END {
}
PROCESS {
  $SPWeb.Lists
  $SPWeb = $null
  [GC]::Collect()
}
}
$(Get-SPWebApplication) | Get-SPSite -Limit ALL | Get-SPWeb -Limit ALL | Get-SPListCollection | WHERE {$_.BaseTemplate -eq "WorkflowHistory"} | where {$_.ItemCount -ge $threshold} | FL ParentWeb, Title, ItemCount

Products: Nintex Workflow 2013, Nintex Workflow 2010, Nintex Workflow for Office 365

 

For community members who want to take their approval workflows to the next level, allow me to introduce you to the Nintex Connector for DocuSign, now available in the Nintex Live catalogue and the Nintex Store.

 

The Nintex Connector for DocuSign allows you to build workflows that include web service calls to DocuSign to automate signing processes. This is done by configuring and dragging DocuSign connector actions onto their workflow canvas, like you would out-of-the-box actions or other cloud service connectors in the Nintex Live catalogue or Nintex Store.

 

A few scenarios where this connector will be super-useful: employee on-boarding, purchase requests, product approvals, audit sign-offs, code reviews, and all manner of contracts.

 

Technical prerequisites for the Nintex Connector for DocuSign are as follows:

  • Either Nintex Workflow for SharePoint (2010 or 2013) with current Software Assurance contract and Nintex Live activated,
  • Or Nintex Workflow for Office 365,
  • AND a DocuSign subscription

 

(Note that, because Nintex for Office 365 is a subscription service, it includes software assurance. Therefore, Nintex for O365 customers can access the connector in the Nintex Store.)

 

Contact your partners for more information on how to buy DocuSign – they know what to do. Alternatively, you can email docusign@nintex.com, and we will point you in the right direction.

 

We are currently working on a way to co-provision trials of the connector with some DocuSign included. In the meantime, however, you can request a 14-day trial of DocuSign here.

 

We’ve also included links to helpful content below:

In support we field a lot of questions revolving around workflow history such as; where it is kept, how it grows over time, how to maintain it and what are some of the limits that you will run into. Today, I would like to show you where it is created, kept and how to plan for the future.

 

General Information:

 

There are 2 places where the workflow history is kept and accessed.

 

     1. SharePoint Workflow History – This is kept inside of the site collection in a hidden list typically

          called NintexWorkflowHistory.

     2. Nintex Workflow History– This is kept inside of the Nintex Workflow database.

 

Because there are two places the workflow history resides, this also means that there are two places you can view it.

 

SharePoint Workflow History

 

The SharePoint workflow history can be accessed a couple of different ways, but the most common is by clicking on the link inside of the workflow history column added to a list when a workflow is first run. (see below):

 

spwfhistory1.png

This information is pulled directly from the SharePoint workflow history list and isn’t referencing the Nintex database at all.

 

SharePoint Workflow History Example:

spwfhexample1.png

 

It’s also worth noting that there is at least one workflow history list that exists for each site collection and that multiple history lists can be configured, but more on that in a little bit!

 

Nintex Workflow History

 

The Nintex Workflow history is stored throughout several tables inside of the Nintex database. To access the Nintex workflow history, you can go to one of two places depending on the type of workflow.

 

  • List Item by opening the list item menu and clicking on “View Workflow History”:

spwfhistory2.png

  • Site Workflow by going to the Site menu (Site Actions in SharePoint 2010) > Nintex Workflow 20xx > View Workflow History :

 

spwfhistory3.png

 

 

Nintex Workflow History Example:


ninwfhex1.png

 

Clicking on the “Click here to show detailed view” will give you the detailed view like what is shown below:

 

ninwfhdetail.png

 

 

     Workflow History Limits:

 

There are several considerations with regards to workflow history,both what is being stored within SharePoint (history list) and what is in the Nintex database.

 

The workflow history list can be managed by going to the Site Menu > Site Settings > and find “Manage Workflow History Lists” under Nintex Workflow:


wfhlistsettings.png

Here you can see how many items are contained within the history list:

 

hislistsettings.png

The Nintex workflow history list is bound by the same rules that applied to other lists in the web application (list view threshold for example). It is
important to keep this in mind because as this list grows it will effect performance of workflows and viewing workflow history. It is recommended to keep this list below 10,000 items (5000 if you are using the default list view threshold) to keep things running smoothly.

 

As for the Nintex database, there are 2 main tables that you need to keep an eye on:

 

  • dbo.workflowlog - Only in use when verbose logging is enabled inside of Central Admin > Nintex Workflow Management > General Settings
  • dbo.workflowprogress - This table keeps a history of every action that is executed within a workflow.

 

These tables typically grow in a linear fashion, but can spike rather quickly depending on the workflow usage in your environment.

 

To validate how many records exist inside of the tables, you can pull the SQL Server disk usage report with the following steps:

 

  1. Open SQL Management Studio.
  2. Expand the Database node.
  3. Find the Nintex Workflow database(s).
  4. Right-click on the Nintex Workflowdatabase and select Reports> Standard Reports > Disk Usage by Top Table.

 

SQLusagereport1.png

 

The report will look like:

SQLusagereport2.png

 

In Part 2, I will be going over some best practices around maintenance and improving performance. Stay Tuned!

 

 

Part 2is here! Demystifying Workflow History (Part 2)

Filter Blog

By date: By tag: