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

We want to hear from you!

 

We have a four-question survey for you. It'll take just moments to answer, and it'll help us make Nintex Connect better.

 

Why do you come to Nintex Connect? How long do you stay? How long does it take to find what you're looking for?  Would you recommend the site?

 

That's it! Four questions. Multiple-choice answers.

 

It's almost as fast and easy as creating a workflow in a Nintex Workflow design canvas.

 

Our First Community Survey! 

 

Thank you!

The "dateDiffDays" function will only return the difference between two dates as a positive integer. It is only designed to return the difference between two dates, not determine if one date falls before or after another.

 

To have the date difference display in this way, you will need to use a combination of some calculated values and a Form variable. Essentially you need to compile a string, which simply adds the "-" symbol in front of any difference value when Date A is less than Date B.

 

Try it doing the following:

 

1 - Add two Date/Time controls to the Form, Date A and Date B

2 - Add a calculated value control and set it to calculate the difference between the above: dateDiffDays(DateA,DateB) - Be sure to give this control a name so it can be referenced later, I simply called mine "Difference."

3 - Add a second calculated value control and set it to the following formula: If(greaterThanOrEqual(DateB,DateA),' ','-') - This will generate a negative symbol when the second date is an earlier date to the first date. Name the control (I named mine "Tag")

4 - Add a Form Variable, set it to type "String" set all recalculate options to "Yes" and then use the following formula: trim(Tag+Difference)

5 - Add a third calculated value control and just set it to log the Form variable.

 

When you preview the Form and enter some dates you should see the third calculated value control log what appears to be a negative number. Note you can hide the other calculated value controls so they aren't visible to the end user.

 

It's important to note that the above will not actually log a negative integer, just give the appearance of one. So if an actual negative integer is needed the conversion would need to be done by a workflow when the user saves the list Item or submits the task (depending on the type of Form.)

 

With some work you may also find you can do this conversion entirely within a variable, however I believe using the calculated value controls is probably a better option as it gives you an opportunity to have a look each step in the process should anything go wrong.

 

Hopefully that's helpful.

jackgelo

Update lookup field

Posted by jackgelo Champion Sep 20, 2016

Hi,

 

sometimes here on the community someone ask how to set through a workflow a lookup field, so I've decided to write here how to do that..it's very simple!

 

In your workflow you need to know what is the ID of the elements in the list that's connected through the lookup column.. if your list has a lookup on the following list:

 

IDTitle
1Item1
2Item2
3Item3

and you want to set on your item a lookup to Item1, then in your workflow you have to set that field to the corresponding ID

 (Lookup is our lookup column)

but..what if you want to update a lookup column with multiple values?

Firstly, check that the lookup column allows multiple values..you have to explicit set it and sometimes simple things may be forgotten..

Then you have to create a string with all the IDs of the corrisponding elements, separated by ;#;#, so if in our case, we want to create a lookup to Item1 and Item3 we have to set the field as in the image

 

That's all..Easy, isn't it?

 

Giacomo

Hi all,

 

today I've discovered a very interesting setting in Global Settings section in Nintex Workflow Central Administration and I want to share it with you

The setting is called Task form properties view 

and "Workflow Task View" is the default value, that you change if you want..

 

This is the name of the view that specify which properties are shown in a default task form, if you don't have a view named like that, then all the properties will be shown (it's the most common scenario I've seen).

 

If you create or edit such view, you can choose what you want to show or hide in task, so that user doesn't see all the "hidden" fields you can have in your list/library that are useful for the workflow but not for him/her..

 

Unfortunately this settings is global for all the farm and if you want to have different view for different tasks that run on the same list/library, you can't  .. if you think this could be an interesting feature, I've also created a request on uservoice: Move Task form properties view setting to the task level – Customer Feedback for Nintex 

 

Giacomo

Recently we had the problem that workflows stuck on iterating state machines, pause for...-actions, etc. The WFE's owstimer.exe ran continously on 25% by occupying about 330 MB and the workflow timerjobs were displayed stuck on 0% on running jobs page in central administration.

By doing the steps in the blogpost https://community.nintex.com/community/build-your-own/blog/2015/08/26/tracking-and-resolving-stuck-workflow-timer-jobs#c…  by Andrew Beals I could find the responsible workflow which was a running instance containing a state machine that had two identical named states as you can see here:

 

 

I have no idea how the workflow designer did that, maybe by renaming and moving the states around at the same time.

If published and running, this workflow seems to produce an infinite loop inside the workflow timerjob.

I could delete the workflow instance on list's Workflows / Remove Workflows-page:

Workflow Designer

Print

 

Zoom to view

 

Reporting and Management

User-based workflow tracking

 

Summary statistics, reports, and charts

 

Individual workflow history & verbose logging

 

Log in the history list

 

User access control

 

Workflow change approval

 

Logic and Flow

Action set

 

Filter, switch action

 

User interaction

Delegate workflow task

 

Approval, review, and multi-outcome tasks

 

Email based natural language approval

 

String operations

 

Site, Libraries and Lists

Create/delete sites and site collections

 

Check In/Check Out/Cancel Check Out on items

 

Create list

 

Set approval status

 

Customization & Re-Use

Content Types, User defined actions

 

Custom context data

 

Export to Visual Studio

 

 

This list is an extract from http://www.nintex.com/workflow-platform/technical-specs-workflow

Home » Nintex » New Task list for Nintex Workflow tasks

New Task list for Nintex Workflow tasks

Some Nintex workflow actions create tasks on the SharePoint site, for example both the Assign Flexi task and Request Approval actions create tasks. These tasks are by default created on the sites ‘Workflow Tasks’ list. If you would like all the tasks for a specific workflow to have it’s own tasks list, you can setup the Nintex Workflow to create it’s own Task list.

Even Lazy Approval Flexi Tasks still create actual tasks on the site, the task list can be a great resource to review active tasks (i.e. tasks that have not been completed) or to review who approved which task and when.

1. Open the existing workflow, click on the Workflow Settings option.
Workflow-New-Task-List-15-1
2. Scroll down to the Task list section, select Create new… from the dropdown. Enter a name for the new task list for this workflows tasks.
Workflow-New-Task-List-15-2
3. Save the workflow settings, publish the workflow.

In the support organization, there are frequently customer requests for how to properly refresh Test / Dev Environments with Production data.  The steps below can be used as an example for how to migrate content.  These steps are some basic guidelines around the process for migrating data from a Production Farm to a Test farm, but as all SharePoint farms are different, you may need to adjust these accordingly to meet your specific business needs. 

 

Production Farm Steps

Backup Your Databases

If you wish to preserve the current workflow history and state, it is recommended that you stop the target Web Application Pool(s) in IIS along with the SharePoint Timer Service in Services.MSC prior to performing backup operations

  • SharePoint
    • SharePoint Content Databases
  • Nintex Forms
    • Unless this is a straight migration where the old farm is no longer being used, it is recommended you generate a new database / new live ID for the farm, meaning that the Live / Mobile forms stored in the Nintex Forms database will need to be republished in your sites on the test Farm
  • Nintex Workflow
    • Workflow content databases
    • Workflow configuration database
      • If you are not using User Defined Actions, Workflow Constants, or Scheduled workflows, and there is no Workflow Progress data in the Nintex Configuration Database that needs to be retained on the target farm, you can create a new Nintex Configuration Database

 

Development Farm Steps 

Install / Verify Nintex Workflow and Forms Builds on Target Environment

 

Disable Jobs / Services on the farm

  • Disable the Nintex Workflow Scheduler Timer Job
    • Find the job under SharePoint Central Administration > Monitoring > Timer Jobs > Review Job Definitions
  • Disable the SharePoint Timer Service on all servers in the Farm
    • This can be found in Services.msc
  • Disable Target Web Application Pool(s) in IIS on all servers in the farm (leave SharePoint Central Administration in a ‘Started State’)

 

Restore and Attach Databases

  • Restore SharePoint and Nintex Databases in SQL Server Management Studio
  • Attach SharePoint Content DB(s) to the farm using Mount-spcontentdatabase PS
  • Execute "_PrepareForNewEnvironment" stored procedure on the Nintex Config Database
    This command will remove all existing connections to Nintex databases along with any Pending Nintex Live requests. This is a key step as this will prevent any connection strings from referencing production servers. 
    • Launch SSMS and expand the config database
    • Find Programmability and Expand the Stored Procedures folder
    • Right-Click on "_PrepareForNewEnvironment" and select the Execute Stored Procedure
  • Connect the Nintex Configuration Database in the Farm  Go to Central Administration > Nintex Workflow Management > Manage Databases
    • Click the Create button(edit button if a config database is already in place)
    • Enter the name of your server and the database
    • Select the "Connect to existing database option"
    • Click "Ok"
  • Connect the Nintex Content Databases to the farm

Additional Configuration Steps

  • Ensure All workflow actions have been enabled
    • In Nintex Workflow Management, go to Manage Allowed Actions
    • Select the check box at the top of the first column (ensure all items have been checked)
    • Click Ok
  • Temporarily disable outgoing email in the farm
    **This is 100% optional, but the workflows will be live when all of the services are brought back online, and the majority of customers we have worked with want to avoid confusion with emails coming from workflows in dev. This is recommended until you can confirm that all workflows have been stopped, or are not sending any further emails  
    • Go to Central Administration > Server Settings > Configure outgoing email settings
      • You can place a test server or a dummy relay in the outbound email
    • Go to Central Administration > Nintex Workflow Management > Global Settings
      • Place a test exchange server or a dummy relay in the outbound email.


Bring the sites and forms back online

  • Reactivate the Web Application Pools, the SharePoint Timer Service and the Nintex Workflow Scheduler timer job that were disabled during the ‘Disable Jobs / Services on the farm’ step
  • Republish any forms using Nintex Mobile / Live (if you did not bring over the live ID / Database)

 

Common Issues / Tips and Tricks

Explicit References

  • If you are using explicit links rather than the {Common:URL} token in your actions, these will need to be cleaned up prior to running your workflows.  The explicit links will still point at the production environment and could potentially alter production data if in use in a 'Call Web Service' or 'Web Request' action.  This could also extend to Workflow Constants if a URL is defined within a constant that is used across actions.
  • If you are using the 'Execute SQL' command to query or alter data within your production farm, you will need to update the connection string to reflect the proper location after moving your data.

I had these notes stored from a couple of years ago - they helped me at the time with a problem I had been banging my head with for ages, but I haven't needed to use them since.  Not sure if any use to anyone, but in the process of getting all my blog posts in one place, and what better place than the Community

 

Believe it or not, this is not straight forward.  For this blog I will paint the picture.  I have a request list which uses Managed Metadata to store Business Units.  I have a list on another site which stores approved and completed items from the original request list.  On this list, the same Business Unit Managed Metadata column is used.  I tried using the "Create item in another site" action in Nintex Workflow but could not just simply map the field from one list to the other.  Instead I had to query the TaxonomyHiddenList of the target site collection to get the ID and GUID for the term.  To find the hidden taxonomy list, simply use "Lists/TaxonomyHiddenList/AllItems.aspx" on the end of your URL after the site collection.

 

There can be multiple terms for the same value in the TaxonomyHiddenList (if it exists in a few of the term stores), so you need to be able to pass the IdForTerm in when querying the list which is achieved by using a regular expression action.

 

Firstly I use the Set Variable action to store the value from the managed metadata field in the original list into a variable.  In this example I called it vTextBusinessUnitMM

Then I used a Regular expression action to find the "IdForTerm".  The configuration below changes the variable value above to the format of the IdForTerm and stores it in the same variable.

 

 Then I use Query list to query the TaxonomyHiddenList of the target site to get the ID and the IdForTerm.  I store the returned values in variables.

Finally I use the Build String action to format the values returned:  ID;#Value|IdForTerm.  This is what needs to be passed to the destination site when inserting or updating an item with Managed Metadata field.

 

Many users use the Lazy Approval Settings when they are designing a workflow.

Many of us don't know that when a user that receives an email that can be answered by replying it, and this user has set as Out of office, a loop of infinite emails begins.

 

To solve this issue is simple. Just go to Sharepoint Central Administration, navigate to the Nintex Workflow Management / Lazy Approval Settings and add a phrase to ignore. Ignore the phrase "Out of office"

 

Filter Blog

By date: By tag: