Skip navigation
All Places > Getting Started > Blog > 2015 > September

How to break a workflow - Breaking Bad with Nintex Workflows



Sometimes a customer asks for help telling that the workflow "suddenly" is not working, and on a couple of cases I realized that some user made a change on the list/library or another stuff that affected the workflow.


Some basics to review are the following:


  • A column was deleted
  • A column was changed
  • The list was deleted
  • Group Name changed


Case 1

A column was deleted


When a column is deleted from the SharePoint list/library, it happens different things depending on where you were using that field.  In some cases the workflow ends with an error, on other cases you just view missing information

Let's see 2 samples:

  • The deleted column was used on a "Send Notification" action
  • The deleted column was used on a "Update Item" action




Send Notification

On a workflow sample when I used a column to be shown on an email, the workflow goes on and I just see some missing information on my email where I should see the information of the column.





Update Item

On a workflow sample when I used a column to be updated with that action, the workflow ends with some errors, but with any clue that the column was deleted.


In my case I received 2 emails. The first one just says that an error has ocurred.




Then I receive another email with more information and the following message.


"The workflow could not update the item, possibly because one or more columns for the item require a different type of information."





It says that the workflow could not update the item, and a possible cause of the problem







Unfortunately there is no way to know, easily, what was the field you used on your original configuration.


In that case if you are updating another fields just save the action and all will become normally.



On other post I'll show another cases.




Related products: Nintex Workflow 2016, Nintex Forms 2016, Nintex Workflow 2013, Nintex Forms 2013, Nintex Workflow 2010, Nintex Forms 2010, Nintex Live


Typically when an error comes up around a missing Feature or a duplicate Content Type or Field within SharePoint, it can be difficult to diagnose what exactly is being referenced.  In order to assist with troubleshooting the issues specifically related to Nintex Products, below are Nintex Features, Content Types, and Fields along with their associated IDs. 

**Please note that some of the Features, Content Types, and Fields are hidden.  Hidden items are not going to be visible within the SharePoint UI.


Nintex Features

**Note: The feature NintexWorkflowClaimsMigration is only included in SharePoint 2013 environments


FeatureFeature ID


Nintex Content Types


Content TypeID
Nintex Biztalk Task0x010801005CC0A86910A24687A76ECAC954D3E3F3
Nintex Workflow Multi Outcome Task0x0108010064E42B14ADA442C78E98D686760A8493
Nintex Workflow Multi Outcome Task using InfoPath0x0108010064E42B14ADA442C78E98D686760A8493006EBD0FA4731041D9804386A7FEA568DC
Nintex Workflow Multi Outcome Task using Nintex Forms0x0108010064E42B14ADA442C78E98D686760A8493000568DBB766D0491684897A230753AAF9
Nintex Workflow Task0x0108010079DBDE612F7B46928C6A2516BA2CAE37
Nintex Workflow Task using InfoPath0x0108010079DBDE612F7B46928C6A2516BA2CAE3700E0B65C5281234030AA8CA4D8F8910E72
Nintex Workflow Task using Nintex Forms0x0108010079DBDE612F7B46928C6A2516BA2CAE3700D4A837248A47E040ABD1A569613E898B
Workflow Snippet0x010100F815D979DC2B4F48A9DBCA64AED3C636
Workflow Template0x010100F8376F5313D041EF85718B229F4FBFA8


Nintex Fields (Site Columns)


Internal   NameIDGroup
ApproverComments819e6cf2-36c3-4013-8aef-c99712c26036Nintex Workflow
AssociatedContentType4a07d815-9c92-4b43-a527-29c3b76a65bfNintex Workflow
NintexWorkflowDescriptiond97c0a58-77fd-48cf-8a7a-9ffdfdd11a6eNintex Workflow
TemplateCategory6abeaa08-87c5-4385-9c81-39cbb72f99a6Nintex Workflow
TemplateLcid837c2b97-e338-446d-a993-c96fd0c4b5d7Nintex Workflow
WorkflowCategoryd0d7bbf9-95cb-4661-b7a0-9bec8e968c3eNintex Workflow
WorkflowPartDescription607ec2f6-48eb-4a14-9e1e-bc48043e157eNintex Workflow
WorkflowPartID7f3814a0-6ef1-4856-bf1d-1a06f8437dc4Nintex Workflow

This is just a quick tip. I was working on several forms that all had Nintex Mobile layouts. For several of these forms I used Preview mode so I could test the form, but not publish the changes to the user.


To preview a form, select the Preview button on the Nintex Forms Design Ribbon. The preview settings dialog will appear before the preview is displayed. Then choose the device type of Nintex Mobile App. Forms designed for the Nintex Mobile App are not available for preview directly within the Nintex Forms Designer as it cannot render an accurate preview. When a mobile layout is specified as the device layout to preview, the platform and mode are not longer relevant.


This worked great without issue until I realized later that I had a couple of previews left over and wondered why they didn't go away after I published the form. I couldn't find anything in the designer to remove the Mobile App previews. I forgot this simple note in the Forms User Guide:

Once the Generate Preview button is clicked the form will be made available on Nintex Mobile only for the user who has designed the form. The form will be removed from the forms list once it has been submitted. An existing preview form will be overwritten if a new preview is generated.


So I submitted the preview form, and it was gone just like it said. Silly of me to look around for 20 minutes for a delete button.


Hope this helps someone else!


Applies to the following products: Nintex Workflow 2010, Nintex Workflow 2013


How to purge items in a large Nintex Workflow History list.

If you have more than 5,000+ records in your Nintex workflow history list, you may need to review other options to purge these items as the GUI may fail its purge operation.


History List Purge Method 1


Using NWAdmin.exe -o PurgeHistoryListData

NWAdmin.exe is included as a part of your Nintex install. Here is an example using the PurgeHistoryListData:

SharePoint 2013 Management Shell:

NWAdmin.exe –o PurgeHistoryListData -siteUrl -lastActivityBefore 2014-07-01 00:00 -state SELECT STATE


Specify to remove history list items for workflows that have a state of Running, Completed, Cancelled, Error or All state. The default is Completed if -State is left off.

Don't use "-state All" in production. Only purge completed workflows that you don't need to review the history of. If you purge running instance data, it will not be able to continue.


To get the correct format for the -lastActivityBefore and -lastActivityBeforeUTC switches use this command in Power-Shell:

SharePoint 2013 Management Shell:

Get-Date -Format -s


Please note: PurgeHistoryListData needs to be run for each Site in your Site Collection that uses Nintex Workflow. You can identify sites that have large history lists in your SharePoint farm by using the following script: How to quickly identify large lists in SharePoint


More information on NWAdmin.exe commands and switches can be found here:


If the NWAdmin.exe PurgeHistoryListData approach fails to clear out items you can then try the PowerShell script bellow.


History List Purge Method 2


Using PowerShell to purge items

You can find the script here: How to purge items from a large history list safely via PowerShell

This script utilizes paging and indexing to specifically target each item and delete it. Paging helps throttle the traffic to your SQL server down by only deleting x number of items at a time before it rests and starts again. Indexing enables the targeting of items without the performance overhead of enumerating and/or querying a large collection of items.


How to purge large dbo.WorkflowProgress table data.

If you find you have 5,000,000 or more rows in your Nintex dbo.WorkflowProgress table then you will need to consider trimming some records. You can do this using the below options.




Only preform a dbo.WorkflowProgress clean up AFTER you have purged data from your Nintex workflow history lists. Not doing so will prevent you from purging items from the history list using the "PurgeHistoryListData" command unless the "-clearall" switch is used.



dbo.WorkflowProgress table purge Method 1


Using NWAdmin.exe -o PurgeWorkflowData

The first step we recommend is using our NWAdmin.exe command. Here is an example using the PurgeWorkflowData operation:

SharePoint 2013 Management Shell:

NWAdmin.exe -o PurgeWorkflowData -state SELECT STATE -url -lastActivityBeforeLocal 2014-07-01T00:00:00


Specify to remove history list items for workflows that have a state of Running, Completed, Cancelled, Error or All state. The default is Completed if -State is left off.

Don't use "-state All" in production. Only purge completed workflows that you don't need to review the history of. If you purge running instance data, it will not be able to continue.

Again, you can find more information on the NWAdmin.exe command here:


dbo.WorkflowProgress table purge Method 2

Using a SQL Script to purge records

If NWAdmin.exe -o PurgeWorkflowData fails to purge the records out of your dbo.WorkflowProgress table, our next recommendation is to use the following SQL script:


First you will need to gather the SiteID's for the site collection's you would like to purge data from. To do this run the following power-shell command:

SharePoint 2013 Management Shell:

Get-SPSite -limit all | SELECT URL, ID, RootWeb


Afterword run the following query to retrieve the number of remaining records per site collection:


SELECT COUNT (*)as RecordsPerSiteCollection,I.SiteID
FROM WorkflowInstance I
inner join WorkflowProgress P
ON I.InstanceID = P.InstanceID
--WHERE siteid = 'YOUR SITE COLLECTION GUID' --Update to your Site Collection ID


Here is an example of the output of this script:



To clear records for a specific site collection with a last activity date less than 2014-07-01 (See additional filters at the bottom including doing purge per site):


DECLARE @return_value int
EXEC @return_value = [dbo].[PurgeWorkflowData]
@SiteID='YOUR SITE COLLECTION GUID', --Update to your Site Collection ID
@LastActivityDate = '2014-07-01' --Setting lastworkflowactivity time, this is actions executed older than the date specified
SELECT 'Return Value' = @return_value


You can also use one or more of the following parameters to fine-tune the query to limit the information that is removed:


@workflowname <Exact Name of workflow>
@listid <GUID>
@state <##>--Running = 2, Completed = 4, Cancelled = 8, Error = 64
@instanceid <GUID>
@webid <GUID> --Site/Sub Site
@siteid <GUID> --Site Collection
@itemid <GUID>
@lastActivityDate <Date of last activity execution>
@initiator <UserName>

This is just a reminder for me (if I need it in the future) or whoever need it so as to lose time I lost trying to do it.


I tryied to customize a task form with Nintex Forms and I received this message.


     Please update to the current version of Nintex Forms for Office 365


  • You are using an older version of Nintex Forms for Office 365
  • Update to the most recent version to customize task forms




And I asked myself how could I update it. Because I didn't remember a Sharepoint feature to update installed apps.


And after some time I solved it with the next steps:


In order to add the app to your Office 365 tenancy, you will need to add the app. This tutorial will take you through the process of adding the app.

In your Office 365 site, click on the Settings icon and click on Add an app.




When updating your database mappings on sites with the Nintex Workflow Site collection feature already activated you may find that your database mappings do not reflect the changes you made.


For example I created the new database named "Test_Database" and went to change my existing mapping to my new content database. Here is the mapping for my old content database:


I then changed the mapping to my new content database "Test_Database:


Upon reviewing my database mappings under the "View database mappings" sub menu I find that this change hasn't gone through:




This is due to what is stored in our Nintex Configuration Database and how those records get updated. I've gathered the tables in the database that connect our content databases and their site mappings in the Nintex configuration database:


The dbo.Database table

This table stores the Nintex database information and where they are stored. It also assigned them an ID so they can be mapped to sharepoint content databases.


The dbo.ContentDBMapping table

This table stores the mappings between the Sharepoint content databases and the Nintex content databases.


The dbo.Storage table

This table stores the mappings between site collections and Nintex Content databases.



These tables all interconnect with each other and help direct where Nintex Workflow data gets stored. As you can see above my database mappings are successfully pushed to the Nintex Config database. However, upon reviewing the dbo.Storage table the site mappings still reflect the old database.




To resolve this issue simply deactivate and reactivate the "Nintex Workflow 20XX" feature at the site collection level. This will update the database mappings in SQL as it will query your Nintex Workflow Config database to find out what Nintex Content database is mapped to the Sharepoint content database the site collection is using and update that record (or create it if it doesn't exist) in the dbo.Storage table.

Upon opening the Nintex Workflow designer for O365 you receive the following error in the ribbon:

This issue generally indicates that the Nintex Workflow app cannot communicate with the SharePoint tenant. The sharepoint app will make a request to your site from the following URL:

This call is being made from the SharePoint app itself. If this call fails you either do not have appropriate permissions or you do not have the required domains added to trusted sites.


By default you do not need to add any domains to your trusted sites however when a group policy is being applied to increase browser security you may need to add sites to your trusted sites to allow otherwise "unsafe calls" to pass successfully. Browser settings that are modified by a local group policy are pushed down to your machine by your domain's activate directory. To verify that the browser is not being restricted by domain policy try logging in to your tenant from another device outside your organization.


If you do find that your machine is restricting these requests please add the following domains to your trusted sites.

To do this, follow these steps: In Internet Explorer, click Tools, click Internet Options, and then click the Security tab. In the Select a Web content zone to specify its current security settings box, click Trusted Sites, and then click Sites. Add the following sites to this dialogue:



Lastly, this issue could also be occurring due to workflow manager not being installed to your team site. This feature can be added by reviewing the following blog post:

Error connecting to the workflow manager: Operation is not valid due to the current state of the object


Please contact support if you have any additional issues.



Andrew Beals

Filter Blog

By date: By tag: