Skip navigation
All Places > Getting Started > Blog > Authors sonisick

Getting Started

2 Posts authored by: sonisick

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

 

 

 

Better to use a "for each" loop when Possible.

 

You might be thinking that you need to use a Loop because you're not certain of the number of executions.  You may have a better idea than you think of the number of executions something will take . I will present an example of a Parent/Child Process that utilizes a State Machine to illustrate this in another article.

 

After some bad examples of Safe Looping Executions times, I determined there had to be a better way.  In a large facility, I wouldn't want to disable Safe Looping because Nintex will be used by a large range of users with different skill levels.  In short, I want the safety provision provided by Safe Looping for the general user population. Infinite Loops can bring a machine to its knees.

 

I began playing with the "for each" loop for a particular application that I had of creating 30 list records. Since I knew I needed to loop 30 times, I added 30 Numbers to a dummy list.  (The list contained nothing but a number column.)

 

I, then, used a "Query List" to extract that number items from the dummy list based on the number of iterations I needed. (e.g., if I only needed 20, I would set a condition for the number being less than 21.)  The creation of that same 30 item for a custom list took under a minute. (With 5 minutes a loop in the "Loop" control, the first list took an hour and a half to create 30 items.)

 

A colleague of mine, Jody Brooks, enhanced this idea by using collections created from the "Regular expression" control seeded by a string.

 

Jody noticed that in the Nintex "Regular expression" control a string could be split into multiple collection variables.  Take the following string to get the idea "1,2,3,4,5,6,7,8,9,10".  Splitting this using the "," would yield ten collection variables--each containing a number.

 

A heavenly marriage since the Nintex "for each" loop is designed for collection variables. With the above collection variables, I can iterate through a loop ten times. Also not you can set a Boolean variable to exit the loop early if needed.

 

Then Jody designed a UDA, User Defined Action, that created a collection of a thousand from with the numbers to 1000 in a single-line text variable punctuated with a comma between each.  This was kind of a pipe wrench approach. I didn't need that many loops and wanted some input as to the length of the collection.

 

I wanted to create five variable collections for looping: 100, 200, 300, 400, and 500.

 

The following is my approach for the creation of a UDA called "How Many For Each":

 

 

UDA Settings.png

 

Essentially, a user of UDA enters the FinalCount Parameter. It is not required, so if a value of 200, 300, 400, or 500 is not found the other branch is executed and an array of 100 is returned.

 

The workflows is essentially a setting a variable, a switch statement with a build string, and a regular expression evaluation.

 

 

Workflow.png

 

The build string is essentially a concatenation of the StringtoSplitVariable, which is set in the first step to:


1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,

 

Essentially, the build strings are concatenations of the variable to itself.

 

Here is the one in the 500 branch, I had to adjust slightly to make it come out to 500 with concatenating 1,1,1,1.  The initial string is only 198 characters long--if I made it 200--this loop ended up being 501--gremlins anyone!

 

  Build String.png

Let me know if you find a use for this UDA. I'm attaching the code.

Filter Blog

By date: By tag: