Skip navigation
All Places > Getting Started > Blog > 2017 > January
2017

In my scenario, I have two lists. The first list is called „Car marks and Product locations“, where I store car marks and the locations where they are produced.

image

The second list is called „Car marks“, there I can create entries and choose between different car marks via a lookup column on my first list. The corresponding locations for the chosen car marks should automatically be stored in an additional column called „Product locations“.

image

The workflow that identifies the corresponding values looks like this:

First I use a „Set variable“ action to get the ID’s of the values that have been chosen in the lookup column „Car marks“ and store them in a variable called „varCarMarksLookupIDs“.

image

At this point it’s important to mention that I choose „Lookup IDs, Comma Delimited“ as the format for the values I store in the variable.

image

Then I use a „Regular expression“ action to split the single IDs and put them into a collection variable called „vCarMarksLookupIDsCollection“.

image

Now I’m using a „For each“ action to iterate through all ID’s that have been stored in the collection. The current ID always gets stored in a variable called „vCarMarkSingleLookupID“.

image

In the first step of the „For each“ action I get the product locations for the current car mark ID and store them in a variable called „vCarMarkProductLocations“ with the help of a „Set variable“ action.

image

In the second step of the „For each“ action I build a continuous string of all product locations with the help of the „Build string“ action.

The variable „vCarMarksProductLocationsAll“ contains all product locations. For every loop, I add the corresponding product locations for the current ID to that string.

clip_image016

At the end of the „For each“ action I have all corresponding product locations for every car mark in my string variable and can now update the item with it.

image

This is how the whole workflow looks at the end:

clip_image019

And this is the result after the run of the workflow:

image

You can find the workflow in the attachments ;-)

The "Document Generation" action offers the opportunity to create documents based on a definable template with all the information that is gathered while the workflow is running.

After the release I’ve asked myself whether it is the possible to get the information of a repeating section (created with Nintex Forms for Office 365) into a document via the “Document generation” action. The answer is yes and in this blog post I’m going to show you how this can be achieved.

The focus of this blog post will be the workflow including the „Document Generation“ action, but for a better understanding I will also describe the other aspects of my scenario. There’s a custom SharePoint list with a Nintex form which offers the opportunity to order products in the desired quantity. Afterwards a workflow will automatically create a PDF document with all relevant information concerning the specific order. The PDF document is created based on a predefined Word template.

SharePoint List and Nintex Form

First, I create a custom SharePoint list called „Orders“ with a choice column „Product“ that includes different products and a multiple text column called „OrderedProductsandQuantity“. I modify the form of this list via Nintex Forms and add a repeating section that includes the „Product“ column as well as a new single line textbox control called „Quantity“. The information of the repeating section (the XML) will be stored in the column „OrderedProductsandQuantity“.

image

This is the XML that is stored in the column „OrderedProductsandQuantity” for the example shown in the previous screenshot:

<?xml version=“1.0″ encoding=“utf-8″?><RepeaterData><Version /><Items><Item><Product type=“System.String“>SharePoint 2013</Product><_x0037_9a74352-f26f-4f5e-a1d7-32c39f64ddfa type=“System.Int32″>2</_x0037_9a74352-f26f-4f5e-a1d7-32c39f64ddfa></Item><Item><Product type=“System.String“>Nintex Workflow 2013</Product><_x0037_9a74352-f26f-4f5e-a1d7-32c39f64ddfa type=“System.Int32″>1</_x0037_9a74352-f26f-4f5e-a1d7-32c39f64ddfa></Item><Item><Product type=“System.String“>Nintex Forms 2013</Product><_x0037_9a74352-f26f-4f5e-a1d7-32c39f64ddfa type=“System.Int32″>1</_x0037_9a74352-f26f-4f5e-a1d7-32c39f64ddfa></Item></Items></RepeaterData>

Document template

Before I start with the creation of the workflow, I create a word document named “Order template” in a document library called “Documents”. This document will serve as my template for the “Document Generation” action later on.  

image

Nintex Workflow

As I’ve already mentioned the workflow creates a PDF document with all relevant information concerning the specific order based on the Word template I just described. Every information that is supposed to appear in the document needs to be saved in a variable, so the workflow consists of more than one action.

imageimage

First of all I use two “Query XML” actions to get the information about the particular order positions out of the XML in the column „OrderedProductsandQuantity”. The products are stored in a collection variable called “ProductsCollection” and the quantities are stored in a collection variable called “ProductsQuantityCollection”. This is how the configuration of the action looks like for the gathering of the quantities.

image

Then I create three variables: OrderNumber (Current Item:ID), Requester (Current Item:Created By) and OrderDate (Current Item:Created). Afterwards I use a “For Each” action to iterate through all elements in the collections variables.

 

image

With the help of the “For each” action I get all the products of the order. As I also need the corresponding quantity for the particular product I use the “Get Item from Collection” action.

image

So for each loop I get two values, the product and the corresponding quantity. These two values will temporarily be stored in a dictionary variable called “ProductQuantityDictionary” that I create via the “Create Dictionary” action. The dictionary variable has two keys, “Product” and “Quantity” both text by type.

image

The values in the dictionary are added to a new collection variable called “AllProductsQuantityCollection”. Therefore I use the “Add Item To Collection” action.

image

After the last loop I have a collection variable with complex values that includes all products with the corresponding quantity. The content of the collection variable looks like this:

image

After all the desired information has been stored into variables, I start to configure the “Document Generation” action, which in the end looks like this:

image

In the “Template document library” column I define the document library where the template for the generated documents is saved, in my case “Documents”.

In the “Template” column I select the already existing template called “Order template”. You also have the choice to create a new template if you like to, whereby you can choose between an Excel, a PowerPoint and a Word template.

Then I edit the template by clicking on “Edit in Word”. When the template is opened for the initial creation or for changes, the so called “Nintex Document Generation Tagger” panel can be found on the right side.

image

This panel is used to insert the desired variables into the document template. Therefore the cursor has to be placed where the value of the variable should appear, then the desired variable must be selected and added by clicking in “Insert Tag”.

image

For my variable “OrderNumber” the result looks like this:

image

To display the information of a repeating section in the document I have to create a table. In my case I create a table with two columns and two rows. I use the first row as a header and the second row for the necessary tags.

When I then use the “Nintex Document Generation Tagger” again and chose a collection variable, there’s one additional column, a column named “Tag type” with three different parameters (“Start collection table”, “Key” and “Simple”).

In the first step I place the collection variable with the tag type “Start collection table” in the first column of the table. In the same column I place the collection variable with the tag type “Key” and enter “Product” as the key. In the second column I place the collection variable with the tag type “Key” and enter “Quantity” as the key.

imageimage

The result looks like this:

image

The tag type “Start collection table” specifies the start of a collection variable table, a column will be created for each entry in the collection. This is how my final template with all desired variables looks like:

image

As I like to have the order as a PDF document I select “PDF” in the “Output file type” column. Furthermore I have to define, where the generated documents will be stored. In my case they’ll be stored in the document library “Documents”, which I define  in the column “Output document library”.

In the last step I define the “Output file name”, which in my case consists of “Order –“ as the prefix and the ID of the list element as the suffix.

I configure the workflow to start when a new element has been created and this is how the PDF looks like after the workflow has finished successfully.

image

More information about the “Document Generation” capabilities can be found in the official Nintex Help!

If you have any questions please feel free to ask! office365 repeating sections documentgeneration

Why doesn't my InfoPath form export with my Workflow?

 

From time to time we get the question why a Nintex Workflow that contains an Infopath form wont copy the InfoPath form along with the workflow when the workflow is exported. This makes deploying and/or migrating the workflow that contains an InfoPath form a pain point for administrators. The reason for this is due to the InfoPath form being stored in SharePoint content and not inside the workflow .xoml. Therefore when you export the workflow the Infopath form does not get exported along with the workflow. This behavior occurs in both Nintex Workflows and SharePoint Designer workflows.

 

Where are these Forms located in SharePoint?

The InfoPath from is located in two locations in SharePoint both of which you can navigate to using SharePoint Designer.

 

Location #1 The hidden 'NintexWorkflows' Library:

The .xsn file located here is used in the Nintex Workflow Designer to render your form for editing and saving if you do not wish to publish the form immediately.

 

----------------------------------------------------------------------------------------------------------------------------

 

Location #2 The hidden 'Workflows' Library:

The .xsn file located here is what SharePoint uses to render the form when you view the task in SharePoint. The form needs to be here so SharePoint will know where to locate the form when executing the workflow. The form is required to be here due to the the 'ows_FormURN' property in the XML of the workflow task item that is associated with the workflow task. This property is what SharePoint uses to find the .xsn file to load the form on the WrkTaskIP.aspx page. Below is an example of the 'ows_FormURN' property in a workflow task that contains a InfoPath Form:

 

 

Publish the workflow to the new location using Powershell.

 

Now that we know where the InfoPath form is located and how SharePoint loads the form on the WrkTaskIP.aspx page we can download copies of this form using SharePoint Designer. Once you have the export of the workflow, the export of the .xsn from the 'NintexWorkflows' library and the export of the .xsn from the 'Workflows' library you can use Powershell to publish the workflow and copy the .xsn files to their correct locations.

 

You can find a Powershell script I have written to accomplish this attached below. Let me know if you have any issues with the script or if this has helped you out in some way. Who doesn't love a little positive feedback?!

 

Cheers,

Andrew Beals

In one of our projects, we needed to implement a solution to track the visits of sales representatives in form of a visit report. Most of the times there are multiple visit reports for one visit, because multiple representatives attend a visit.

In those visit reports the sales representatives should say if they were the driver at the visit or only a passenger. It’s of course possible that not all representatives drive with the same car, for example because of different starting points or follow-up visits. But if they have the same starting point, the same destination and overall there’s no reason why they should not drive together, it probably doesn’t make sense, that they do not drive all together in one car.

In these cases, there’s a chance for optimization and we needed a workflow that can discover these optimization possibilities. This workflow needs to be able to identify specific duplicates (visit reports) in a list.

In this blog post I’d like to show you how I set up this workflow (I simplified the implementation to focus only on the relevant parts).

For the collection of the visit reports there’s a list called “Visit reports”. The following columns can be found in the list:

Visit-ID (Number)*
Starting Point (Single line of text)*
Destination (Single line of text)*
Date (Date and Time)*
Follow-up visit (Yes/No)*
Driver (Yes/No)*

The unique ID for the visit gets stored in the column Visit-ID (ID for the whole visit, not a single visit report, multiple visit reports can exist for a one visit).

In the “Follow-up visit” column the representatives can define if they had another visit after the current visit and in the “Driver” column they can define whether they have been the driver or not. If there are two visit reports of two representatives that are completely identical except of the point that one was the driver and the other one was not, this totally makes sense and of course is the desired scenario.

image

This is how the list looks like with four visit reports for two visits:

image

The goal of the workflow is the identification of the visit with the Visit-ID 1, because the single visit reports of this visit are completely identical and in both visit reports the “Driver” column is set to “Yes”. Identical visit reports with the “Driver” column set to “No” aren’t relevant, because that’s the way it should be.

I worked out the following idea for the workflow. The workflow should process every single visit (Visit-ID) and for every single visit all single visit reports (only if “Driver” column is set to “Yes”) should be stored in a complex collection.

Then the workflow should count the entries (visit reports) in the complex collection and afterwards remove duplicates out of the complex collection. At the end, the workflow should compare the count of the entries (visit reports) before and after the removal of the duplicates. If the count is the same, everything is fine, if the count is not the same, there’s a visit (like the visit with Visit-ID 1) with multiple drivers, so there’s an optimization possibility.

So far so good, let’s start to build the workflow!

As the workflow is not related to a single element (visit report) and should run every day at a defined time, I decided to set up a site workflow.

In the first step, the workflow collects all “Visit-IDs” with a “Query list” action and stores them in a collection variable called “Collection_VisitIDs”. Afterwards the workflow removes the duplicates by using a “Collection operation” action.

image

In the next step the workflow iterates through all Visit-IDs to check the single visit reports. The Visit-ID gets stored in a variable called “Text_SingleVisit-ID”. In the first step of this action the workflow collects all necessary elements (visit reports) and corresponding properties of the single visit reports and stores them in different collections.

image

In the “Query list” action there’s a filter on the actual Visit-ID and on the “Driver” column, as only visit reports with “Driver” column set to “Yes” are relevant.

image

Now the workflow iterates through the  collected elements (visit reports) and the corresponding properties to get all the properties of the single visit reports that need to be added to the complex collection. Therefore, I added another “For each” action and three “Collection operation” actions afterwards, to get all needed properties.

image

Then the workflow uses the “Build string” action to create the single entries (visit report with needed properties) for the complex collection and afterwards uses the “Collection operation” to add the entry to the complex collection “Collection_ComplexCollection”.

image

The “Build string” action looks like this:

image

That’s it for this “For Each” action. At the end of the other “For Each” action the workflow now counts the entries (visit reports) of the complex collection. Afterwards it removes the duplicates and then counts the entries (visit reports) again.

If the number of entries isn’t the same no more it’s a visit where we have two drivers, which is probably one too much, so there’s an optimization possibility. For this blog post the workflow just logs the result into the history list.

image

This is how the workflow history looks like, after a successful run:

image

As you can see, the workflow successfully detects the visit with the Visit-ID 1!

This topic describes the concept of assigned use in the context of workflow-based subscription licensing.

 

If your tenant uses a workflow-based subscription license, then you must specify assigned use when publishing workflows and forms in accordance with subscription licensing terms.

 

Examples of assigned use options presented when publishing workflows and forms: 

 

 

Assigned use options are as follows.

  • Development: Intended for the development phase; the workflow or form does not operate on or affect any business outcome or data outside testing and development. Watermarks appear on development workflows and forms as well as on email messages sent by workflows. (Form preview omits the watermark.)

    Example: Running an expenditure approval workflow generates a request for purchase of a notebook computer and that request is approved, but no purchase occurs because the workflow is being tested.

  • Production: Intended for the production phase; the workflow or form operates on or affects live business data.

    Example: Running an expenditure approval workflow generates a request for purchase of a notebook computer and that request is approved such that the notebook computer can be purchased.

For information on how to track your Workflows please see: How to Track Your Workflows in O365 For Consumption and User Based Subscriptions 

Sometimes I needed to cancel all workflow on a specific list.
The following powershell script will help you to do this.


#Site URL
$web = Get-SPWeb "http://urlforsite.com";
$web.AllowUnsafeUpdates = $true;
#List Name
$list = $web.Lists["ListName"];
# Iterate through all Items in List and all Workflows on Items.        
foreach ($item in $list.Items)
{
foreach ($wf in $item.Workflows)
{
#Cancel Workflows       
[Microsoft.SharePoint.Workflow.SPWorkflowManager]::CancelWorkflow($wf);     
}
}
$web.Dispose();

Web Service Reference

The following section provides an overview, and describes the service operations and data types, of the Workflow web service included with Nintex Workflow 2013.

The Workflow web service provides administrative functionality for Nintex Workflow 2013. You can perform many of the functions normally managed for NintexWorkflow 2013 through SharePoint Central Administration and the Workflow designer, including:

  • Exporting, saving, and publishing workflows

  • Starting and terminating workflows

  • Scheduling workflows

  • Retrieving information about running workflow tasks

  • Processing and delegating task responses for workflow tasks, including Flexi task tasks.

  • Retrieving workflow history for workflows

Service endpoint

The following URL represents the service endpoint for the Workflow web service, where <site> represents the SharePoint site used to establish context for the service operations provided by the endpoint.

http://<site>/_vti_bin/NintexWorkflow/Workflow.asmx

The value specified for <site> is important, in that it both defines and limits the execution context of the service operations for the Workflow web service. For example, if you want to export a site workflow associated with the SharePoint site collection, you must specify the root URL of the site collection in <site>.

Invoking service operations

You can use any invocation method supported by Simple Object Access Protocol (SOAP) 1.2 to invoke the service operations provided by the Workflow web service. For example, you can generate a Windows Communication Foundation (WCF) client in Visual Studio, which in turn can be used to create a WCF client channel and communicate with the service operations provided by the Workflow web service, or you can add a service reference to the service endpoint for the Workflow web service in a Visual Studio project, which automatically generates a WCF client that you can use to access the Workflow web service.

A detailed discussion of SOAP invocation and WCF client implementation is beyond the scope of this document. However you can find a code sample and basic implementation of a WCF client that communicates with the Nintex Workflow endpoints, at Export and publish a workflow with the Nintex Workflow SOAP Web Service.

For more information about WCF client implementation in Visual Studio, see Windows Communication Foundation Services and WCF Data Services in Visual Studio, on Microsoft Developer Network.

Service operation examples

The examples provided for each service operation represent the SOAP envelope for each request and response, in its native XML structure, for the purposes of readability.

Service operations

AddLongTermDelegationRule

AddWorkflowSchedule

AddWorkflowScheduleOnListItem

CheckGlobalReuseStatus

CheckInForms

DelegateAllTasks

DelegateTask

DeleteLongTermDelegationRule

DeleteSnippet

DeleteWorkflow

ExportWorkflow

FixWorkflowsInSiteFromTemplate

GetFolders

GetItemsPendingMyApproval

GetListContentTypes

GetOutcomesForFlexiTask

GetRunningWorkflowTasks

GetRunningWorkflowTasksCollection

GetRunningWorkflowTasksForCurrentUser

GetRunningWorkflowTasksForCurrentUserForListItem

GetRunningWorkflowTasksForListItem

GetTaskDetailsUsingStub

GetTaskStubsForCurrentUser

GetWorkflowHistory

GetWorkflowHistoryForListItem

GetWorkflowXoml

HideTaskForApprover

HideWorkflow

ProcessFlexiTaskResponse

ProcessFlexiTaskResponse2

ProcessTaskResponse

ProcessTaskResponse2

ProcessTaskResponse3

ProcessTaskResponseUsingToken

PublishFromNWF

PublishFromNWFNoOverwrite

PublishFromNWFSkipValidation

PublishFromNWFSkipValidationNoOverwrite

PublishFromNWFXml

PublishFromNWFXmlNoOverwrite

PublishFromNWFXmlSkipValidation

PublishFromNWFXmlSkipValidationNoOverwrite

PublishWorkflow

QueryForMessages

RemoveWorkflowSchedule

RemoveWorkflowScheduleOnListItem

SaveFromNWF

SaveFromNWFNoOverwrite

SaveFromNWFXml

SaveFromNWFNoOverwrite

SaveSnippet

SaveTemplate

SaveTemplate2

SaveWorkflow

SnippetExists

StartSiteWorkflow

StartWorkflow

StartWorkflowOnListItem

TemplateExists

TerminateWorkflow

TerminateWorkflowByName

TerminateWorkflowByNameForListItem

WorkflowExists

WorkflowFormProductSelected

Data types

ContentType

Folder

ItemsPendingApproval

ProcessTaskResponseResult

WorkflowTaskDetail

 

cazza162

Managing Workflow Tasks

Posted by cazza162 Champion Jan 5, 2017

I recently put together a slide deck to present to the team I am part of to offer understanding of the different ways to manage workflow tasks when offering support to users in the business.  The main driver for this is that we always get calls from users "never receiving" the email notifications sent from Nintex.  My thoughts on whether they are "not received" or more simply "deleted" shall be kept quiet here...  users eh!  Anyway, prompted by a question recently posted on the community I thought it might be a good idea to put the information in one place on here too.

 

Nintex Workflow Web Part - My Workflow Tasks

This web part can be added to a page in any site and can be scoped to look at tasks assigned to the logged on user as the site, site collection or farm* level.  This will include tasks assigned to SharePoint groups the user is a member of (only when individual tasks are assigned in the task config in the workflow action).

Nintex Workflow Web  Parts – Workflows I’ve Started

This web part can be added to a page in any site and can be scoped to look at workflows started by the logged on user in the current site, site collection or farm*.

Nintex Workflow Task Delegation

Task delegation can be set to site owner only (i.e. checkbox not selected on action to allow delegation), or delegation can be set to assignee and site owner (i.e. checkbox selected on action to allow delegation).

This is particularly useful for support staff to know when a call is raised that a process is held up by the wrong approver being selected, or the approver being unable to respond in a timely manner.  The fact that even when delegation is not selected on the configuration in the workflow the site owner can still do it is a little nugget of information that not all workflow designers know about.  I wrote a whole blog post on delegation so I won't go into it too heavily here - All things Delegation.

Also for support team awareness I mentioned the availability of long term delegation for approvers to turn on themselves before periods of absence where someone can be delegated to respond to tasks for a set period.  Of course if this period of absence if unforeseen, there is also the ability for support staff to set long term delegation for specified users.  This is also covered in the above blog post.

Task Aggregation in My Sites

As standard there is a link on my sites called "Tasks" which displays all tasks assigned to the user across all site collections.  This has to be direct assignment (i.e. not to a group you are a member of).  This is another way users can find all of their tasks in one place (similar to the nintex workflow web parts).

 

* Requires Nintex Workflow Enterprise version.

 

 

Further Reading / References

My Workflow Tasks

Workflows I've Started

SharePoint 2013: Task Management in My Sites

This topic came up in a question asked by Sean Docherty (Ability to cancel a workflow) and I wanted to share some of the solutions that were discussed within in a bit more detail. More specifically, I want to highlight that there are multiple ways of doing the same thing, as pointed out by our own Cassy Freeman.

 

The Ask

Provide users the ability to cancel a request and in-turn, terminate the workflow and any outstanding tasks.

 

Solutions

Approach #1: Create a list level workflow that can be triggered and terminate the workflows and then delete the item.

Approach #2: Create a site level workflow that can be called to terminate the workflows and delete the item in any list.

Already we can see the differences, but each will provide us with the same end result. So let’s step through them both.

 

Approach #1: List Workflow

For this approach we can simply create a new workflow on the list (we will call it Delete Me). Within the workflow there are two actions; Terminate workflow and Delete item.

 

In the Terminate workflow action we want to stop "All except current workflow". This will terminate any other workflow(s) that are currently in flight for that specific item and in turn, any tasks that are associated to it will be removed as well.

 

Next we want to delete the item. This can be done using a Delete item action, and you guessed it, we want to delete the "Current item".

 

Simple, right? So how do we let the user kick it off? We Enable workflow to start from the item menu. This option can be found in the Workflow settings and is a check box. You can even provide a specific name, icon, and reorder it in the menu is desired.

 

Now that the workflow is setup, users can click on the item and select the workflow:

 

Once selected, it will take the user to the Start workflow page. I recommend editing the Start Form (under Workflow settings) to provide some context to the user. This can also be used as a last warning to them that they are about to delete the item! 

 

 

Approach #2: Site Workflow

For this approach we will be creating a site level workflow (we will call it Terminate and Delete). Within this workflow there three actions; Call web service, Build string, Call web service. We want to terminate any workflow, build the XML to delete the item, and then delete the item.

First we want to call the TerminateWorkflowByNameForListItem (if you are looking for it check out {yourURL/_vti_bin/NintexWorkflow/Workflow.asmx). Now we will need to feed it the information about the list, item, and workflow in question. You can also terminate any previous instances, but is not required. So how do we feed in the variables? We can use workflow variables but make them Show on start form and Required for those that are required.

 

Once these are setup, simply plug them into the web service fields!

With every web service call, I highly recommend testing it with the Run now action with predictable outcomes. This will ensure that your web service is setup properly and the workflow will run properly once triggered.

 

Next we will want to use the Build string action to create our XML to target the specific item and delete it. There are plenty of reference materials out there on the UpdateListItems method, so I will not go into too much detail here. For now, this is the XML that we want to create:

Once created, save it in our XML variable.

Lastly, we want to call one more web service to perform the deletion of the item. Since we have all the pieces in place (list name and XML) all that is left is to plug them in!

Again, do your testing so that you know it will work!

 

Once you are satisfied that it is setup and works properly, all that is left is to call it!

 

But how, you ask!?!?

 

At this point, you can call it however you want. From any workflow within the site, or even run it manually; the choice is yours! For this example, I have it in a state machine and can be called if the status is changed to "Cancelled". 

 

When an item is created,  it goes down both branches; one is for the "main" workflow while the other is to monitor for a "Cancelled" status change. This allows the user to simply change the status to "Cancelled" at any time, even if the workflow is awaiting a response from a task!

 

Final Thoughts

As always, there is never one way of doing something. There are different approaches and each have their own benefits and drawbacks. For Approach #1, it requires the developer to create the workflow on each list that could possibly need this functionality. On top of that, if there is a larger need to use this across multiple lists, you will soon have many of the same workflows out there... and isn't the main reason we use workflows is to reduce repetitive work? It is, however, extremely simplistic and does not take long to setup. Approach #2 on the other hand, requires some understanding of web services and how to call and construct them; something that a typical user probably does not have. It also requires some forethought on how you are planning on calling it. However, it reduces clutter by allowing any user, from any list within the site to call it; creating re-usability.

 

I would love to hear your thoughts on how you would approach this and if you had similar experiences and how you decided to approach the issue.

 

Until Next Time!

chris.ben

What's in a name?

Posted by chris.ben Champion Jan 4, 2017

A person’s name is the sweetest sound to them in any language.  Even in a crowded noisy room, you’ll probably hear your name called out over all the din.

 

Can you relate to when you share a name with someone?  Someone calls out your name “Hey Chris” and you and a different Chris look over at that person and wave?  A little bit embarrassing if it’s not you and a little bit inefficient.  The world would be more efficient if we had unique names but conversations would be difficult:

 

“Hi fingerprint ID 0010010101”
“Oh how’s it going fingerprint ID 1001010110?”
“Good man.  Good.  Happy New Year to you and your wife fingerprint ID 010111010111”

 

It’s much better when we can use terms such as Cassy, Andrew and Fernando* right?


The development world is a bit like this.  Beneath the scenes, everything is referred to using a unique code but we as humans can’t handle this so we’ve made life easier for ourselves by giving items names that make sense to us.

 

Where am I going with this post?  How should we name these things?  What makes sense?

 

In the Nintex world, we have Nintex variables, JavaScript variables, form controls, list and site columns and workflow constants.  You can name these however you want.  You can even give each one the same name but you’ll be asking for trouble!

 

Some may recall this mission where we had to fix a workflow.  One of the issues with the workflow was a list column had the same name as a variable and there is no way to differentiate between the two when you’re looking at your workflow or form.  If you do the same, you’ll make your workflows and forms harder to maintain and probably introduce a few more bugs than usual.

 

I’d suggest there is no single correct answer to how you should name things other than identifying/naming each of the aforementioned elements differently using a convention that works for you.  Here’s how I do it:

 

ElementDescriptionExample
List and site columnsPlain English with spaces.  I don’t have a convention about proper case or mixed case.  Whatever seems appropriate.Person Name
VariablesPrefixed with the notation var and I don’t use spaces.varPersonName
Workflow constantsIn all caps with words separated by an underscore.  I don’t differentiate between constant types (site collection, site, data types etc) or should I?PERSON_NAME
Form controlsAccept the Nintex default which is to take the column name and remove spaces.Personname


I’m very interested to hear what naming conventions work for you.  Do you use lowerCamelCase?  Do you use Hungarian notation/include the data type in the name?  Do you override the Nintex Forms default?  Do you use spaces in your column names?  Do you differentiate your constant types?  Let us know in the comments below.

 

Cheers,
Chris


* Names bear no resemblance to popular members of this community.  Whatsoever.  Honest!

One of the skills every Nintex workflow designer has to learn is how to debug a workflow.  As Andrew Glasser has pointed out in his post Tips on Debugging Workflows, the most common way to do this is to Log information to the History List.  In addition to this there are also times that I will use the Send Notification action to email myself some information at a certain point in the workflow.  In both cases however, these are typically only actions you want to take when developing/debugging a workflow, and don't need them once it's up and running in production.  So what's the best way to turn off these actions once you're ready to publish your workflow?

 

The Problem

The most straight forward way is to go through your workflow before you publish it and either disable or delete these actions.  However depending on how many actions you have, this could be very time consuming.  Plus, if you ever needed to debug something in the future, you'd need to edit the workflow and turn them all back on again.  If you opted to delete them, that would give you even more work to do. 

 

The Solution

The solution I have found for this problem is to use a list to store an indicator for whether logging is on or off for a particular workflow.  I setup my workflows to do a lookup to that list and determine whether there should be any logging.  All of my logging actions are contained within a Run If action that will only run if the logging indicator is turned on.  This way I can turn logging on or off for any workflow simply by changing the logging value in the list.  (This is the same concept Andrew Glasser has written about in Using Workflow Configuration Lists in O365, but just a different application. I like Andrew's nomenclature of calling it a "Configuration List", so I'm going to stick with that.)

 

The Configuration List

The first step is to create your configuration list to store the logging indicator.  I use the Title field to store the workflow name.  I then create a Choice field to store the logging indicator.  I made my choices "On" and "Off", and set the field as Radio Buttons.  I also make sure to set a default value so I don't run into an issue with the workflow where I find no logging value when I attempt to look it up.

 

Once the list is setup, I can then add entries for my workflows and set the logging value. Make sure that the workflow name you enter matches your workflow names exactly.  If you ever change your workflow name, you'll need to update it here as well.  

 

Workflow Configuration List

Logging Field Setup

Once the list is setup, I can then add entries for my workflows and set the logging value. Make sure that the workflow name you enter matches your workflow names exactly.  If you ever change your workflow name, you'll need to update it here as well.  

 

Configuration List

 

The UDA

Since I'm planning to reuse this solution for all of my workflows, I'm going to create a UDA called "Check Logging Status" to do the lookup of the logging indicator.  I setup my UDA with two parameters.  The input parameter is the Workflow Name, and the output parameter is the Logging Status.  Both are text parameters.  

 

UDA Parameters

The only action in the UDA is a Query List action.  This will lookup the entry with the matching workflow name on the configuration list we created above, and then return the logging status indicator for that entry.   

 

UDA Query List    

 

The Workflow Setup

Once the UDA is created, you can now use it in a workflow.  Whenever I create a new workflow, the first thing I do is insert the Check Logging Status UDA.  

 

Insert UDA

 

UDA Setup

After you add the UDA, you'll need to setup the Input and Output parameters.  For the Input parameters, you will pass the Workflow Title.  Since this is part of the Workflow Context data, you can just select it from that list.  For the Output parameter, I create a single line of text variable to save the returned logging status. 

 

UDA Setup In Workflow

Tip: If you want to save yourself some time in future workflows, you can save this configured UDA as a snippet.  Just add an Action set action and put the UDA within it.  Then save that as a snippet.  This way you can add that snippet to future workflows, and it will already be setup and create your logging variable for you as well. 

 

Run If Setup

The key to this solution is putting your logging actions within a Run If action that only runs if the logging is turned on.  The first time you setup a workflow you'll need to create your Run If action using the UDA output.  Setup the Run If to only run if the Logging variable is equal to "On".  

Run If Setup

 

Now within the Run If action you can add any type of workflow logging that you want to do.  

Create Logging Snippet

You don't want to have to setup a Run If each time you want to log something.  So the first time you setup the Run If, you'll want to save it as a snippet that can be reused.  To do this, add an Action Set action, and put the Run If within it. Within the Run If, I also add an empty Log in history list action.  This way it's already there when I add the snippet.  Click on the Action set menu and save as a snippet.  Name it something that will be easy to remember in the future.  I called mine "Log if Logging On".     

 

Complete Workflow Setup

 

When you need to add a logging action to a workflow in the future, just go to your snippets and insert your saved Logging snippet, and then setup what you want to log. 

Insert Logging Snippet

 

 

 

Conclusion

With this setup in place, you now have a Debug Mode for your workflows that you can turn on or off from a list.  When you create a new workflow, all you have to do is insert two saved snippets and you're ready to go.  Once you have a workflow built and ready for production, all you have to do is go to the configuration list and set the logging status to "Off".  If an issue comes up in the future and you needed to debug it, you can just as easily turn it back on.  No more having edit the workflow and manually turn off or on each workflow logging action.  Try it out and let me know how it works for you.   

 

References

Tips on Debugging Workflows 

Using Workflow Configuration Lists in O365 

Demystifying Workflow History (Part 1) 

User Defined Actions

hnyHappy 2017 and congratulations to the people who worked their way to the top of our leaderboard in 2016!

The points in '16 soared to levels not seen in the previous two years of this community's existence! I think that says a lot about the level of commitment of our community leaders, whose images you'll see below. THANK YOU!

 

 

This year's top point earner, Cassy Freeman, started getting really active a couple of months into the year and then came on strong to claim the top spot.  Cassy got there by sharing her knowledge about Nintex products. Thank you, Cassy! You help a ton of people!

 

If you're looking at this, and thinking you want one too, that's great!  Get crackin'!  Anybody who really wants to, can earn their way up the leaderboard.  Get an early start by completing the first monthly mission: January 2017 Mission 

 

Here's a look at the leaderboard for 2016:

 2016 leaders

 

 

 

 

 

 

 

 

 

 

 

The top 20 non-employees will receive a Nintex Connect Champion badge (the gold coin below), so you can easily identify them.*  

winner.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Points are already being accumulated for this year. We're playing to become rock stars! Find out all about the new reputation levels here: Be a Community Rock Star!

 

 

 

 

*Some people, such as Nintex vTE's, or virtual Technical Evangelist, prefer to have that badge next to their name, and those will stay.

Workflows are a way to get repetitive tasks done on SharePoint in the background.  Examples are Approval Workflows for a document, Task Completion Workflows where different steps require different processing, and Scheduled Reminders for work actions or events.

 

Over my nine years of SharePoint, the most common workflows have been a few standard SharePoint Out-of-the-Box Workflows, SharePoint Designer Workflows, Visual Studio Workflows and of late, Nintex Workflows.

 

Out-of-the-Box Workflows have never been flexible enough to adjust for even minor changes. Invariably, you need additional fields or a slightly altered logic flow to accommodate a business circumstance.  They are for the most part immutable.

 

One of the major drawbacks of SharePoint Designer Workflows has been accessing to SharePoint Designer itself. Most installations have very restricted access to SharePoint Designer because the installation, itself, can be damaged in SharePoint Designer.

 

The SharePoint Designer Workflow is text-based with no looping mechanism (there may be one in the SharePoint 2013 Workflow Engine), and consists of a number of steps painstakingly entered; then, compiled to XAML (a workflow markup language).  Until recently all workflows applied only to the list or library for which they were written. Reusability has gotten slightly better (still not great). One advantage to SharePoint Designer Workflows, like Nintex Workflows, is that they require no separate installation and once the workflow is compiled, it is ready to go.

 

Visual Studio Workflows can do a larger range of tasks than SharePoint Designer Workflows--it's a true developer's tool. The downside is that they require an experienced developer and can typically take a week to two to develop; then, have to be installed through a SharePoint Solution package. This requires downtime in the form of a maintenance window. If they have problems, they must be debugged, re-coded and rescheduled.

 

My experience with Nintex is close to two years.  Nintex is GUI-based drag-and-drop designer. All the user needs are permissions on the site and a browser. The drag-and-drop feature allows workflows to be constructed quickly.  The user grabs a specific action icon from a tool box of Actions and adds it to the flow. Then, they configure the action with various parameters.  Once compiled, they are ready to respond.

 

Nintex Workflows can also be exported and imported into another site for reuse--assuming list names match. Repetitive Logic can also be saved in what is called a UDA (User Defined Action) or saved locally as a Snippet. This can be reused in the site or site collection depending on the scope with which it was saved.

 

 

What I like about Nintex is the ability to perform tasks without having to submit a solution request that requires management approval and a maintenance window. Here are some examples of things I’ve built with Nintex: 

 

  1. Configured Emails scheduled for Various Dates with attachments.

 

  1. Rebuild Summary Lists and tied this action to a button click.

      (Especially useful on Summary Lists awaiting actions from other lists.)

  1. Performed Complex Edits on items on being Added or Updated.

      (Also send warning and notifications under certain conditions and rollback changes.)

  1. Update specific fields in large lists.

  2. Sent notifications and escalations at various stages of document processing.

  3. Changed permission on items after initial entry or simply move items to another list.

  4. Use multiple lists in workflows to display information in emails to the user. (Querying other lists for lookup is very common.)
  5. Split Group Fields into individual users to build approval list items and individual emails.

 

The strength of Nintex is that most SharePoint Users with some knowledge of lists and libraries can perform many of these actions.

In short, my reasons for liking Nintex are:

 

  • Browser GUI Interface
  • Immediately Available Code 
  • Reusable and Packageable Complex Logic
  • Ability to run Timed Workflows 
  • Extensive Community, Support, and Training

 

My next blog will suggest features and enhancements that would upgrade the Nintex W###orkflow to world class.

 

Stephan A. Onisick

SharePoint Developer

 

 

 

If you are looking to disable the Nintex Mobile App option from the drop down as shown below, you can

 

 


example.jpg

    do the following:
    • Navigate to your SharePoint CA
    • Click on Nintex Forms Management
    • Select Manage Live Mobile Access
    • From this page disable "Disable Live Mobile Access" option
    • Press OK

    This will remove Nintex Mobile Apps option from the menu.

    Filter Blog

    By date: By tag: