Skip navigation
All Places > Getting Started > Blog
1 2 3 Previous Next

Getting Started

449 posts


( developed for SP2013 on-prem, Nintex forms 2.10 )


This code was inspired by nmarples whose amazing blog post can be found here. He lifts the curtain on the Nintex rules engine and shows the power of combining Javascript with rules, providing clues to this realtime validation concept.

You can implement this solution right away on any form control without any additional configuration, cut and paste as shown below using these 4 simple steps;

 

1) make sure each form field control is named and the label is associated with the control:

 

2) paste this CSS in the form's Custom CSS setting:

 

.lp-border-red {
  background-color : rgba( 255,0,0,.2 );
}
.lp-border-yell {
  background-color : rgba(255,255,0,0.3);
}
.lp-border-grn {
  background-color:rgba(0,255,0,0.3);
}

 

 

3) paste this Javascript in the form's Custom JavaScript setting:

lpForm = {

 Validate: function( formControlCall, sourceContext, required, isValid ) {
  // Obtain the internal element input name.
  var formControlID = formControlCall.split( "'" )[1] || "";
  var internalElement = sourceContext.find( "[name^='ctl'][formcontrolid='" + formControlID + "']" );
  // During initial load, people control is a placeholder, no internalElement exists yet, so bail, validation will succeed later
  if ( internalElement.length == 0 ) return;
  var internalElement_name = internalElement.attr( 'name' );
  // Scrub the name.

  var intext = internalElement_name;
  var outtext = intext.split( '$' ).join( '_' );
  // Obtain the label associated for-name of internal element.
  var labelBorder = NWF$( "[for^='" + outtext + "']" )
    .closest( '.nf-filler-control-border' )
    .parent();
  // Required missing.
  if( required && isValid ) labelBorder
    .addClass( 'lp-border-red' ).removeClass( 'lp-border-yell' ).removeClass( 'lp-border-grn' );
  // Optional missing.
  if( !required && isValid ) labelBorder
    .addClass( 'lp-border-yell' ).removeClass( 'lp-border-red' ).removeClass( 'lp-border-grn' );
  // Not missing.
  if( !isValid ) labelBorder
    .addClass( 'lp-border-grn' ).removeClass( 'lp-border-yell' ).removeClass( 'lp-border-red' );
  return isValid;
 },
};

 

4) paste this expression into a new rule for each form field you wish to validate

 

( function( formControlCall, isValid ) { lpForm.Validate( formControlCall, sourceContext, true, isValid ) }( "{Control:Self}", {Control:Self} == '' ) );

optional : inside the expression, change true to false to change the field from required to optional

note : in the Condition window {Control:Self} will format itself to appear as {Self} once saved 

 

Done - Enjoy!


 

TL;DR Explanation

 

The above code is a prototype created in an afternoon. There are probably some edge cases that may require additional coding, but this appears to be suitable for all basic form controls.

 

The 3 important concepts from nmarples that he shares in his blog post are:

  • The Rule's Condition expression is evaluated as Javascript. ( This means you can point to any Javascript function in the Condition window and it will be executed )
  • You can pass to your function, both, a reference to the current control as a string parameter
    "{Control:Self}"
    and pass the resulting expression as a boolean parameter
    {Control:Self} == ''
    Nintex Runtime Functions this expression is the same as isNullOrEmpty({Control:Self})
  • During the OnChange event the function and parameters be executed in an IIFE ( what's an IIFE? Google it, it's useful… )

 

CSS

3 classes are used to set the associated control back-grounds to red, yellow or green.

 

Form JavaScript

lpForm : creates a unique namespace where I can safely use any name for my function.

Validate : takes 4 parameters.

formControlCall : a reference to the currently active control
sourceContext : a reference to the context of the DOM
required : true or false ( whether this form field is required or optional )
isValid : true or false ( the result of the provided validation expression - already evaluated )

 

The process of the function

  1. Navigate the DOM to locate the current control's internal element name, it usually looks like: 
    ctl00$PlaceHolderMain$formFiller$FormView$ctl26$ctl16$ac5d43fc_51e7_4d06_b3e8_150731c4bac9
  2. Scrub this name to replace "$" with underscores.
  3. Use the name to locate the associated label control - the label uses an attribute named for.
  4. Locate the parent-border control of the labels.
  5. Use .addClass.removeClass to set the label parent-borders to the appropriate CSS class ( background-color )

IIFE

The immediately-invoked function expression gathers the following run-time provided parameters:

a reference to the current control : "{Control:Self}"

and a the validation expression : {Control:Self} == ''

So the IIFE evaluates these two parameters and passes results into the interior function, were all four parameters get passed to the base Validation function.  Then the base function Validation ultimately returns back the isValid boolean, which could be consumed by the Rule too.

My requirement is to get all o365 users.

I tried two approches:

1) I followed the approach calling service through 'call http service' action but i got an empty results.

(Reference : https://community.nintex.com/message/25149)


2) I used 'o365 search query' action to get all users.

But couldnot get all the users in the response and not able to parse the XML response.

can you please help me out getting all the Users...?

Hi there, folks!

 

You may recall this blog post from a while back by Sean Fiene -- it's a great write-up on how to approach cascading look-ups in Nintex Forms using lookup columns in SharePoint. A summary is: for each set of data you want to create - you need to make a new SharePoint list. It makes sense!

 

But, I, personally, don't like having so many lists. I'd rather just have one place for myself and my clients to update. I wanted to find a new way - and, I have. I'd like to share that with you today so you can poke holes in it, or try it for yourselves. 

 

Let's look at a 1-list set-up for 4 different cascaded sets of metadata.

 

AnimalVegetable

Tier 1Unique 1Tier 2Unique 2Tier 3Unique 3Tier 4
AnimalYMammalYCatYCalico
AnimalMammalCatManx
AnimalMammalDogYPug
AnimalMammalDogBeagle
AnimalAmphibianYTree Frog
AnimalAmbhibianSalamander
VegetableYLeafyYLight GreenYIceburg
VegetableLeafyLight GreenRomaine
VegetableLeafyDark GreenYKale
VegetableLeafyDark GreenSpinach
VegetableLeafyPurpleYCabbage
VegetableRootYBrownYPotato
VegetableRootOrangeYCarrot
VegetableMarrowYOrangeYPumpkin
VegetableMarrowYellowYSpaghetti Squash
VegetableMarrowYellowButternut Squash

 

Let me explain:

 

An issue we have right now is that if we simply use a List Lookup and pull back Tier 1, we will get hella duplication of Animal and Vegetable. Perhaps some day we will have a "remove duplicates" functionality, but right now - we don't.

 

This is where views save the day.

 

  1. For each unique value in Tier 1, I put a "Y" in my Unique 1 column. For consistency, I always tag the first unique item as unique. 
  2. Then, I create a view: Tier 1 - Unique. Filter when Unique 1 = Y. 
  3. Now, when I set-up my List Lookup control in my Nintex Form, I tell it to look at the list called AnimalVegetable and return column Tier 1 using view Tier 1 - Unique. Perhaps I've named that List Lookup something crazy like "Tier 1".
  4. This is repeated for each column, as you'll see above, in terms of setting up views. So I'll end up with a Tier 2 - Unique, and Tier 3 - Unique. And, I can have as many tiers as I like. 
  5. When I want to filter my Tier 2 values based on Tier 1, I set my Lookup List to look at list AnimalVegetable, column name Tier 2, using view Tier 2 - Unique, filtered by control Tier 1. 

 

 

For me, this works really well. How about you? What are your thoughts?

 

Cheers!

 

Rhia

Introduction -

 

I have been wanting to make this blog post for a little while, and even though (due to time constraints) it probably will not be as thorough as I had originally planned, it will ultimately serve the purpose of introducing the community to a few advanced approaches to using the Nintex Form rule system. Though you will need a comfortable understanding of javascript to get the most benefit from this, but if you're curious and aren't keen on programming, don't let that stop you from learning! 

 

The Rule system, as it stands, is a good tool to validate control inputs and to alter the appearance of controls based on the Form's state. However, as I found myself enjoying their usefulness, I also found myself wishing that I could do other simple and useful things with them such as populating a field based on the amount of choices, normalizing the inputs of a field, or doing some type of advanced validation based on wild requirements. 

 

Though I cannot account for all of the ways that you might want to use the rule system, I can at least teach the fundamentals of how to use them in a more explicit / specific way, that will hopefully provide you more opportunity to develop form logic that would otherwise be tedious. 

 

On The Surface -

 

The Basics

 

The Rule system is broken up into several types of rules but the two that are presented via the Rules button inside of the Form Editor are Validation and Formatting [1].

 

Note [1]: If you are using the Responsive Form, there is a new type of Rule that is sometimes called an 'Action' rule, but is listed as a 'Set Value' rule. For all intents and purposes, this rule behaves in the same way that a Formatting rule does, but then goes on to evaluate whatever value is listed inside of the 'Value' formula dialog.

 

Validation Rules - are rules that will run, typically, whenever the control they are placed on has been changed or updated in some capacity, and also create a <span> element in the html of the form that is nested under the control in question. That span element can be thought of as the "physical" manifestation of the rule and contains references to the target control along with information about how the rule should be evaluated and the randomly generated rule name that is created each time you create a new rule. 

 

Formatting Rules - are rules that will run, typically, whenever a control that they have referenced has been changed or updated in some capacity. They do not create an element in the html tree. 

 

The Rule Editor - is the interface that allows you to Create, Delete, Setup, and otherwise Manipulate all of the Rules for the Form and its Controls. In Classic Form Mode it looks like: 

 

While in Responsive Form Mode it looks like: 

 

On The Differences Between Editors: The biggest changes between the two visually are the terms used to label each section, and the fact that the Responsive Forms Rule Editor has removed the Rule Type and replaced it with the ability to choose a single direct outcome (which can be selected in the 'Then' drop-down

 

Rule Conditions are the logical circumstances that will dictate whether or not the Rule Outcome is applied. Rule Conditions are set up inside of the Condition dialog box in the Classic Form Rule Editor:


And inside of the When dialog box in the Responsive Form Rule Editor: 

 

Rule Outcome, while not an actual term that is used in the Rule Editor, this is the 'result' of what will happen in the event that your evaluated Rule Conditions resolve to true. In the Responsive Form Rule Editor, this could be thought of as whatever you have selected inside of the 'Then' drop-down. 

 

 

On Rule Outcomes and Conditions: Whatever you'd like the outcome to be, whether it is invalidation, formatting, disablement, or hiding, the conditions that you write for the rule to evaluate must resolve to a Boolean true.

 

 

The Beyond

 

Referenced Named Controls - (the red link-like references [2] that you see inside of the formula dialog ) are replaced when the form is 'live' (as in being Previewed, Viewed, Edited, or invoked as a New form) with the following example code: 

NWF.FormFiller.Functions.GetValue('ad065df4-c555-44f7-aebe-5491cabcbd2c', sourceContext);

 

(Note [2]: While it is true that referencing other controls inside of the rule condition builder dialog will often result in the red link-like reference being inserted, when referencing the current control, you can type out the plain-text equivalent {Control:Self} (yes - with the curly brackets), and it will be replaced just the same. In many of my own examples, you will see me use the long-form version {Control:Self} as it can be easily copy / pasted without needing to insert it manually as you do for each of the other Named Controls)

 

 

Referenced Runtime Functions - are replaced when the form is 'live' with the full calls to their location inside of the NWF namespace as shown by the following example:

NWF.RuntimeFunctions.isNumeric.call(nullOrContext, someValue)

 

 

On Reference Replacement: The way that replacement works for both Control References, RunTime Functions, etc. is that it looks for a particular expression and attempts to 'remap' it if it recognizes it. For Referenced Controls it is looking for {SomeProperty:SomeValue}, whereas for Runtime Functions it is looking for FunctionName(). 

 

The RunTime Function replacements can be incredibly confusing and frustrating if you are trying to use a Native or jQuery (NWF$) function with an identical name, as it will be replaced with a call to the function that is native to the NWF object. 

 

If you write out: 

NWF$.isNumeric("444");

 

During run time it will be replaced like:

NWF$.NWF.RuntimeFunctions.isNumeric.call(someContext, "444");

 

Which will result in an error. You can sidestep this 'correction' by making your code a little sloppier. Putting a space between the function name (in this case 'isNumeric') and the open parenthesis for the arguments, it will fail to meet the conditions for a function that should be evaluated / replaced, and will be left alone. 

 

NWF$.isNumeric ("444");

// Yay! No error!

 

whew...

 

 

The Helpers

 

There are several Nintex created variables and functions that can help with the manipulation and utilization of the Rule System. Though I will not be covering them all, I do feel like these are the most useful for the majority of users

 

 

Variables

 

  1. Rules: All rules can be found using the 'Rules' variable, which returns an array of Objects.

  2. Page_Validators: All Validation rules can be found using the 'Page_Validators' variable, which returns an array of <span> elements. 

 

Functions

 

  1. NWF.FormFiller.Functions.ProcessOnChange(someControl): This function should receive a Form Control as the argument:
    NWF$("#" + someValue).val("Hello World");

    NWF.FormFiller.Functions.ProcessOnChange(NWF$("#" + someValue));

    and will evaluate any 'on change' rules that have yet to fire on the target control. Because you can change the value of a control without triggering the events that would normally be triggered to evaluate the rules, this is a handy way of getting that done. It should be noted though that most of the time you can accomplish the same thing by triggering the "change" or "blur" event manually using jQuery: 
    NWF$("#" + someValue).val("Hello World").trigger("blur");
    // Same results as above!

     

  2. Page_ClientValidate(): This function takes no arguments but will force the entire form to evaluate all of the Validation Rules upon execution. This is incredibly helpful in the event that you'd like some type of two stage process (for instance, a button that creates a confirmation "Are you sure you wanna submit this?" dialog which must be interacted with before submission) to test the page validity before submitting it to SharePoint. 

    This does however come with a few quirks. Firstly, it doesn't actually apply any of the invalidation styles that would normally get applied had the form been submitted proper. Secondly, it does create the top warning dialog that lists all of the current invalidation messages. 

    That being said, Caroline Jung created a handy little function that can apply those invalidation css classes to your controls right over here: https://community.nintex.com/thread/11554#comment-75684 

  3. NWF.FormFiller.Functions.GetParentContext(someControl): So... This function doesn't exactly do anything in terms of Validation, however it is incredibly useful for getting what is often called the 'sourceContext'. While the sourceContext is always passed into a Rule of any type, knowing how to get a correct context to any control can be helpful in developing your own functions and system that work with or sit on top of the existing Nintex Forms Rule system in the future.

    All a 'Context' is, is simply the closest 'containing' control that the target control is inside of. The context of a control that is inside of a Repeating Section is the row of the repeating section that particular control is inside of. However the context of a control that is just on the form proper, would be the form proper! 

Down The Rabbit Hole -

 

The Evaluated Conditions

 

While it is easy to suspect that things being evaluated inside of form Rules are special functions and value references, in reality, what's being evaluated is nothing more than plain ol' JavaScript [3][4]. As shown above, all of the references to named controls and functions are replaced at run time and evaluate accordingly. Because of that, we can actually do some really interesting things. This is especially true when we start to consider the usage of Immediately Invoking Function Expressions (simply known as IIFE. More info about those can be found here: An Introduction to IIFEs - Immediately Invoked Function Expressions - A Drip of JavaScript). 

 

Note [3]: Rules aren't the only things that evaluate javascript. The formulas for the Calculated Control can also evaluate JS.

 

Note [4]: So long as the return value of whatever it is you are evaluating as the Rule Conditions returns either a true or false boolean value, it will 'drive' the rule. This could be as simple as writing: 

 

true

 

Yes. It's just one word, but that would make the Rule apply either its formatting, invalidation, or action (in the case of responsive forms) from the very beginning and stay that way throughout the form session.

 

Why might this knowledge be useful? Well, to most people who aren't comfortable with javascript, it isn't! However, for people who find it easier to think using the functions that are either exposed via the DOM's api or jQuery, it can be a lot faster to prototype in a text editor (Sublime Text, Brackets, VS Code, Notepad++, etc. etc.) and then copy paste that into a Rule's condition area rather than to sit there and type it all out inside of a html rendered <textarea> element which is a terrible place to type code. 

 

Consider the following (terrible) Rule. Let's say that we want a specific Single Line Text control to always normalize the value inside of it to "0.00" if it's blank, or to the second decimal point if it isn't (so - 1.00, or 4.31, but never ever 4.311): 

 

(function(controlValue, myControlID) {
  "use strict";

  // Using our passed in control's ID in a variable
  // we'll set the variable internalElement to
  // our control.
  var internalElement = NWF$("#" + myControlID);

  // If the value of the control isn't empty...
  if (internalElement.val()) {

    // Then we'll need to test if it's Numeric
    // Notice that I am using the Nintex Forms function
    // of isNumeric rather than the jQuery function.
    if (isNumeric(internalElement.val())) {

      // If it is Numeric, then we can split at the decimal point delimiter
      var splitValue = String(internalElement.val()).split(".");

      // Test to see if there is anything in the integer portion
      // *that is, the value on the left side of the decimal point*
      // If there is a value. Keep it.
      // If there isn't. Set it to 0.
      var intPart = (splitValue[0]) ? splitValue[0] : "0";

      // Then we'll take the value to the right of the decimal point
      // If it exists...
      //
      //    Then we'll check the length of that value.
      //
      //      If it's under 2 then we'll add a 0 to the end of it.
      //
      //      If it's above or equal to 2 then we'll truncate off the numbers
      //      beyond the second decimal place.
      //
      // If it doesn't exist we'll just set it to "00"
      var fractionPart = ((splitValue[1]) ? ((splitValue[1].length < 2) ? splitValue[1] + "0" : splitValue[1].slice(0, 2)) : "00");

      // Then we'll put both halfs back together
      var joinedValue = intPart + "." + fractionPart;

      // And we will set the control to that value
      internalElement.val(joinedValue);
    } else {
      internalElement.val("0.00");
    }
  } else {
    // But if it is empty, we'll set the value to "0.00"
    internalElement.val("0.00");
  }

  // We're not actually doing anything with this rule other than
  // what is the equivalent of an event handler, so we don't
  // even need the rule to apply anything to the control.
  // Because of that, we can always return false.
  return false;

}({Control:Self}, myControlID));

// We'll pass in the Value of the Control
// and the javaScript ID of the Control

 

Alright. That does what we want... but as mentioned in the code comments. It's not really any more flexible than just setting up and using a standard Event Handler. 

 

Currently the only advantage over using an event handler is that you don't have to target your controls... and speaking of which... wouldn't it be awesome if you could reference the target control of a rule from within the rule itself? 

 

Self Referencing Part 1 - A New Hope

 

Being able to reference the control that the rule is currently evaluating on is what would ultimately make the rule system a wonderful tool to use... But there is no immediately obvious way to do this from the onset. 

 

While the above example code will only work for the control that has the javascript ID exposed (through the control properties) as the variable 'myControlID', we could make a 'universal' rule if we were only able to capture the control that was being referenced by the rule that was executing our code. 

 

Luckily the rule system provides a few bits of information that can help us achieve a self-reference, however, before we get into what those are, it is important to know how Rules are represented as javascript. 

 

Every rule, which is named dynamically upon the building of the Form essentially looks like this: 

function fnSomeVeryLongGUIDThingHere(sourceContext, rowIndex){
  return //(your code);
}

 

Whatever you have typed into the Condition / When are of the Rule will be evaluated (and subsequently returned) just beyond the return statement as indicated by the 'your code' comment in the example above. 

 

If your Rule's condition looked along the lines of: 

isNullOrEmpty({Control:Self}) || {Control:Self} < 100

 

Then the resulting Rule that is generated by the Form loading would look like: 

function fnSomeVeryLongGUIDThingHere(sourceContext, rowIndex){
  return NWF.RuntimeFunctions.isNullOrEmpty(NWF.FormFiller.Functions.GetValue('some-guid-forthe-formcontrolid-attribute', sourceContext)) || NWF.FormFiller.Functions.GetValue('some-guid-forthe-formcontrolid-attribute', sourceContext) < 100;
}

 

Though that may mean nothing to anyone immediately, you might wonder what those two arguments are (sourceContext and rowIndex) that get passed into the wrapping Rule Function.

 

As mentioned above, the sourceContext represents the 'context' (IE: The 'container') of the current control that the rule is running on. So that's already covered. However, the rowIndex is something different. rowIndex actually holds the id attribute of the control that is being evaluated! 

 

That means that you can essentially forgo the need of going into the Properties of a Control and setting up a javascript variable name for the id, because it can now be grabbed using that argument. 

 

Using that numeric 'normalizing' Rule we made above, it can now be rewritten in a more generic / dynamic way: 

(function(controlValue, sourceContext, rowIndex) {
  "use strict";

  var internalElement = sourceContext.find("#" + rowIndex);

  if (internalElement.val()) {
    if (isNumeric(internalElement.val())) {

      var splitValue = String(internalElement.val()).split(".");
      var intPart = (splitValue[0]) ? splitValue[0] : "0";
      var fractionPart = ((splitValue[1]) ? ((splitValue[1].length < 2) ? splitValue[1] + "0" : splitValue[1].slice(0, 2)) : "00");
      var joinedValue = intPart + "." + fractionPart;

      internalElement.val(joinedValue);
    } else {
      internalElement.val("0.00");
    }
  } else {
    internalElement.val("0.00");
  }

  return false;

}({Control:Self}, sourceContext, rowIndex));

 

And so now we can all live happily after ever. Right? 

 

Self Referencing Part 2 - Reference With A Vengeance

 

Sadly, that is not the end of the story. The variable rowIndex, while incredibly awesome and useful is only populated for Validation Rules... And because Validation Rules are only evaluated after they have been changed, if you want a rule to fire immediately after the form has loaded then you'll need to use a Formatting Rule. So how in the heck can we get the reference to the current control via a Formatting Rule? 

 

You may have noticed that a few code examples up, I showed what a Rule actually ends up being once it has been generated during the building of the Form. Inside of that Rule Wrapper, the references to the current control ({Control:Self}) were converted into a call to a Nintex Form function along with two arguments. The second argument was just the sourceContext, but the first argument was a string which I wrote out as 'some-guid-forthe-formcontrolid-attribute'. In reality that string would look more along the lines of '8381e2de-c48d-4f02-9e32-d26bb106af44'

 

What is that? Well. It's actually the attribute called formcontrolid, which every form control has, and is used as a link between those red colored Named Control references (like {Self}), and the controls that they represent as html elements on the page. This means that so long as we pass in the self reference and capture it as a string (otherwise it would be evaluated down into whatever value that Function call with those arguments should return), along with the sourceContext we can figure out which control the Rule is running on. 

Consider the following code: 

(function(formControlCall) {
  "use strict";

  // If you look at the {Control:Self} refernece we have passed
  // into this function as an argument (named: formControlCall), you'll
  // see that it's surrounded by quotes. Because of the way that
  // the Form 'transforms' references that it sees into the code to be evaluated
  // and doesn't care about the surrounding mark-up, it actually just
  // puts the fully transformed call right in between those quotes
  // resulting in a String being passed in.

  // The final result is that the variable formControlCall actually equals:
  // "NWF.FormFiller.Functions.GetValue('8381e2de-c48d-4f02-9e32-d26bb106af44', sourceContext)"


  // If you split the formControlCall at the single quotes, you end up with
  // an array with (3) items.

  // "NWF.FormFiller.Functions.GetValue(",
  // "8381e2de-c48d-4f02-9e32-d26bb106af44"
  // ", sourceContext)"

  // By Taking the value at Index 1 (the formcontrolid of the Current Control)
  // we can use it to grab the actual control as it is on the form.
  // If the reference to that Array Index is empty, then we'll get a blank string instead.
  var formControlID = formControlCall.split("'")[1] || "";

  // Assuming that the Array Index wasn't empty
  // formControlID now equals: "8381e2de-c48d-4f02-9e32-d26bb106af44"

  // Using the sourceContext, we can search for any control with a matching formcontrolid attribute.
  // Putting the class '.nf-filler-control' will allow us to identify the topmost Control Container <div>
  var targetControl = sourceContext.find("[formcontrolid='" + formControlID + "'].nf-filler-control");

  // This will vary between Control Types. In the case of Single Line Text controls, we can grab
  // the element that is under the parent container (stored in targetControl), and shares a
  // formcontrolid attribute and has a class of '.nf-assocated-control'.
  var internalElement = targetControl.find("[formcontrolid='" + formControlID + "'].nf-associated-control");

  // Please be aware that NOT ALL INTERNAL CONTROLS CAN BE OBTAINED USING THE METHODS SHOWN FOR
  // THE internalElement VARIABLE!

  // *I may come back later and write something that will absolutely always obtain the correct control
  // but don't hold your breath 

  return false;
}("{Control:Self}"));

 

Without Comments that's:

(function(formControlCall) {
  "use strict";

  var formControlID = formControlCall.split("'")[1] || "";
  var targetControl = sourceContext.find("[formcontrolid='" + formControlID + "'].nf-filler-control");
  var internalElement = targetControl.find("[formcontrolid='" + formControlID + "'].nf-associated-control");

  return false;
}("{Control:Self}"));

 

If we wanted to change that formatting rule above so that runs immediately when the form loads, and subsequently every time that the value of the control has been changed, instead of using a Validation Rules, we could use a Formatting Rule with the following code: 

(function(formControlCall) {
  "use strict";
  var formControlID = formControlCall.split("'")[1] || "";
  var targetControl = sourceContext.find("[formcontrolid='" + formControlID + "'].nf-filler-control");
  var internalElement = targetControl.find("[formcontrolid='" + formControlID + "'].nf-associated-control");
  if (internalElement.val()) {
    if (isNumeric(internalElement.val())) {
      var splitValue = String(internalElement.val()).split(".");
      var intPart = (splitValue[0]) ? splitValue[0] : "0";
      var fractionPart = ((splitValue[1]) ? ((splitValue[1].length < 2) ? splitValue[1] + "0" : splitValue[1].slice(0, 2)) : "00");
      var joinedValue = intPart + "." + fractionPart;
      internalElement.val(joinedValue);
    } else {
      internalElement.val("0.00");
    }
  } else {
    internalElement.val("0.00");
  }
  return false;
}("{Control:Self}"));

 

This is great for when you want something to be formatted in a particular way, but don't care to validate on it. On the other-hand, if you wanted to validate on it, you could just as easily use the Validation variant as shown above, and instead of returning false, return the condition result of how you would like it to be evaluated.

 

 

Self Referencing Part 3 - Attack Of the Review

 

To Recap, there are two ways to obtain a reference to the control that a Rule is currently running on. They are as follows.

 

Self Referencing For Validation Rules

(function(rowIndex) {
  "use strict";

  var internalElement = sourceContext.find("#" + rowIndex);

  return false;
}(rowIndex));

 

Self Referencing For Formatting Rules:

(new version (Updated: 2018-03-27)): 

(function(formControlCall) {
  "use strict";

  var formControlID = formControlCall.split("'")[1] || "";
  var targetControl = sourceContext.find("[formcontrolid='" + formControlID + "'].nf-filler-control");

 
  if (!(targetControl.data("DisableCounter") === undefined && targetControl.data("HideCounter") === undefined)) {
    if (targetControl.attr("data-formcontroltypeid") === "c0a89c70-0781-4bd4-8623-f73675005e15" && (!event || (event.type !== "readystatechange" || (event.srcElement && event.srcElement.text && event.srcElement.text.toLowerCase() === "add new row")))) {
      return false;
    }
  }
 
  /* return the condition  you actually are checking on */
  return true;

}("{Control:Self}"));

 

(old version - Do Not Use... unless the above code does strange things to you) 

/* !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! */
/* PLEASE SEE THE REVISION CODE EXAMPLE BELOW THIS ONE! DO NOT USE THIS EXAMPLE! */
/* !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! */

(function(formControlCall) {
  "use strict";

  var formControlID = formControlCall.split("'")[1] || "";
  var targetControl = sourceContext.find("[formcontrolid='" + formControlID + "'].nf-filler-control");

  // This will need to change based on the 'type' of control
  // but this works for Single Line Text which is probably the most used control.
  var internalElement = targetControl.find("[formcontrolid='" + formControlID + "'].nf-associated-control");

  return false;
}("{Control:Self}"));

/* !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! */
/* PLEASE SEE THE REVISION CODE EXAMPLE BELOW THIS ONE! DO NOT USE THIS EXAMPLE! */
/* !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! */

- Examples -

 

Because it may not be obvious how any of this stuff can be used, I've put together a few examples of how one might utilize the above knowledge to do things that would otherwise be difficult. 

 

Self Locking Control - This Formatting Rule (which should have the Disable box / action selected) that will check if the current control is set to any of the values as specified in the Array of values which is passed into the function's argument 'ignoredValues'. If the Control is not any of the values inside of the array, then it will be given a class of '.lockMe', and will return a true to the Rule Processor, resulting in the Disabling of the control. Otherwise the control is left untouched, and will remain Enabled for the remainder of the Form session unless there are other Rules that can Disable the control for other reasons: 

(function(formControlCall, ignoredValues) {
  "use strict";
  var formControlID = formControlCall.split("'")[1] || "";
  var targetControl = sourceContext.find("[formcontrolid='" + formControlID + "'].nf-filler-control");
  var controlValue = eval(formControlCall);
  if (!targetControl.hasClass("ignoreMe") && !targetControl.hasClass("lockMe")) {
    var canIgnore = false;
    if (!NWF$.isArray(ignoredValues)) {
      if (typeof ignoredValues === "number" || typeof ignoredValues === "string") {
        ignoredValues = [ignoredValues];
      } else {
        ignoredValues = [""];
      }
    }
    NWF$.each(ignoredValues, function(index, value) {
      if (!canIgnore && value === controlValue) {
        canIgnore = true;
        return false;
      }
    });
    if (canIgnore) {
      targetControl.addClass("ignoreMe");
    } else {
      targetControl.addClass("lockMe");
    }
  }
  return targetControl.hasClass("lockMe");
}("{Control:Self}", ["", "Some Other Value"]))

 

The Self Locking Control Rule can be useful if you have forms that contain controls which once filled out, should not be editable again. Or as in my case where I have a selection control with (3) values ("In Process", "Won", "Lost"), (1) of which ("In Process") can be changed from but (2) of which ("Won", "Lost") can never be changed out of once they have been selected and the Form has been Submitted. 

 

 

Automatic Option Selection - This is a Formatting Rule that will automatically select an Option from a drop-down control if there is only one option to select. This is useful for Lookups that are being filtered by other choices and have many different option counts based on said filters. While the code below doesn't reset the control once you have selected a filtering value that would result in more choices being available, it wouldn't be too difficult to set that up: 

(function(formControlCall) {
  "use strict";

  var formControlID = formControlCall.split("'")[1] || "";
  var targetControl = sourceContext.find("[formcontrolid='" + formControlID + "'].nf-filler-control");
  var targetSelect = targetControl.find("select.nf-client-control").get(0);

  if (targetSelect !== undefined) {
    if (targetSelect.options.length < 3) {
      if (!targetSelect.options[targetSelect.options.length - 1].selected) {
        targetSelect.options[targetSelect.options.length - 1].selected = true;
        NWF$(targetSelect).trigger("change");
      }
    }   
  }
  return false;
}("{Control:Self}"))

 

- Outro -

 

So there you have it. A whole lot of text and you have arrived at the end of this post (hopefully) with a new understanding of how you can utilize the Rule system in new and interesting ways. Armed with this knowledge you should be able to create "Action Rules" (aka: rules that can update a target control's value or influence the form in some meaningful way) in the Classic Forms (because why should the Responsive Forms have all fun?), and different approaches to validating complex combinations of things. 

 

For my own work I have developed a Validation System which sits on top of the existing one found in the Nintex Forms environment so that I not only have 'Invalid' controls, but also 'Valid' controls, and 'Warning' (also known as Optional) controls - all of which have their own styling that is applied when they reach one of those states, or as in the case of an Optional state, will start off showing that it's something that isn't needed all of the time, but might be needed *sometimes*.

 

 

Once that is refined a bit more, I may release it to the public so that people can add on to it, but it needs some more revisions (as the code base has changed), and I simply do not have the time to prepare those. 

 

I look forward to seeing what you all come up in your journey. 

 

Thank you for reading! 

 

 

 

 

PS: If you have any examples that you'd like me to add, or have any questions or corrections, please shoot me a direct message, or better yet, ask in the comment section below! 

 

- Edits -

 

Edit 1: So it would seem that I forgot a critical part of handling Rules for a Repeating Section. As far as I know there still is a rather glaring bug that prevents the event triggers that should be associated to the control / rule from being attached once a new row has been added (as seen here: Custom validation function not fired on repeating section). This is problematic as, ideally, you'd like all of the controls in every row of your repeating section to act the same regardless of when they were created (and without having to submit / reload the form). 

 

This can be accomplished by adding the following code, or by modifying your existing RegisterRepeaterRowAdded function with the code shown in this example: 

NWF.FormFiller.Events.RegisterRepeaterRowAdded(function () {  
  ValidatorOnLoad();
});

 

Now your rules should behave as you would expect them to inside of a Repeating Section, and life should once again be great! 

 

Edit 2: It would seem that Repeating Sections do silly things with Formatting Rules which requires us to manually prevent them from occurring. Because of the way that Formatting Rules process the Disable / Hide side of things (by using a ticker numeric value hidden in the data() jquery object on the main control div), we need to make sure that we do not arbitrarily increment or decremented that value in such a way that it would break how Disabling and Hiding work. 

 

We can do this specifically by including the following conditional checks before the main return statement of our rule that would actually check against the conditions that we wanted to check against (for the rule proper):

if (!(targetControl.data("DisableCounter") === undefined && targetControl.data("HideCounter") === undefined)) {
  if (targetControl.attr("data-formcontroltypeid") === "c0a89c70-0781-4bd4-8623-f73675005e15" && (!event || (event.type !== "readystatechange" || (event.srcElement && event.srcElement.text && event.srcElement.text.toLowerCase() === "add new row")))) {
    return false;
  }
}

 

Essentially, what the above code does is to first check and see if the hidden 'ticker' values (DisableCounter and HideCounter) exist on the data() object. If they do not then the rule will evaluate as we can assume that this is the first time that the rule is being ran. 

 

If they do exist, then we move into the next phase where we check the Control's Type (see: Form Control Property complex element). If it's a Lookup Control ("c0a89c70-0781-4bd4-8623-f73675005e15"), then we need to do some additional checking to make sure that the Control is in a state in which we actually would like to evaluate it.

 

While this really only effects Lookup Controls, it should be written in a way that you can plonk it into any Rule and it'll work regardless. 

 

 

Because of this I have revised the above 'Review' example for Formatting Rules. 

So, you want to save more than one field from a database query but you don't want to have multiple SQL Request controls in your form?  You can achieve this with a customized SQL query and JavaScript.

 

In the query, concatenate the fields you want to use.  In this example, a pipe character ( | ) is used as a delimiter.  Set the Value field to your concatenated fields ("Details") and the Display field to a reader-friendly field for your users to select.

SQL Request action

Set the JavaScript variable name for your SQL Request control as well as the other fields you want to populate:

JavaScript Variable Name

Use the Custom JavaScript area in the Form Settings to retrieve the fields.  In this example, the SQL Request control is displayed as a Drop Down List, so the JavaScript uses the Change event to get the values and then populates the textboxes with the fields from the database query.

Form Settings Custom JavaScript

What is Nintex Workflow Cloud (NWC)?



It’s a state-of-the-art cloud workflow capability that lets you easily extend and connect your forms, applications, content, and systems of record, with the people who make the decisions your business relies upon to succeed

Nintex Workflow Cloud empowers anyone in your organization to unlock the transformational business benefits of humancentric workflow automation.

 

Why Nintex Workflow Cloud?

Four main key factors that determine why should be used NWC:

  • EASY

    Hit the ground running fast with a cloud-based solution that removes 
    upfront setup and costs. 

    Drag-and-drop to design and build workflows the way you think – in a few

clicks, not code.

       Connect structured and unstructured content sources, from legacy systems to modern SaaS apps.

  • HUMAN-CENTRIC

    Empower the people closest to lines of business to automate the processes

that are your business.

         Bring the right content, at the right time, to the right people. Share the workflow innovations your people create, to benefit your entire business.

  • INTELLIGENT

    Measure the business impact of your workflows, immediately and in the future.

    Make data-driven decisions that identify the best opportunities for business impact.

    Benefit from the virtuous cycle: the more you automate, the more you learn, enabling you to automate more.


  • VENDOR NEUTRAL

    Nintex Workflow cloud is completely vendor neutral. Nintex was essentially tied to SharePoint Infrastructure both for On-Premises and SharePoint Online. However, with every increasing service such as Google Drive, Box, Salesforce, Zendesk etc. Nintex has made their own Nintex cloud Infrastructure and all the services including SharePoint can be connected.

 

 

How to use Nintex Workflow Cloud?


There are many business scenarios where you can leverage. In a sample scenario, you make an Online Registration Form and users can fill their details. Users may not in SharePoint Online or SharePoint On-Premises account and your form will be ANONYMOUS.

These are the steps:

 

  1. Request a Nintex Workflow Cloud.
    You can request a Nintex Workflow Cloud by clicking here.

  2. Nintex Workflow Cloud Dashboard

    Once you have logged into Nintex Workflow cloud, you can view all your workflows.
    When you start with NWC, you may not have any workflows in the Dashboard.



  3.  Brief Overview of Nintex Workflow Cloud Configurations

     In Connections option, you can add multiple services. For an instance, you can add an “Add Link” to connect OneDrive for business. 



    User Management: You can add users and assign specific roles such as Administrator, Designer, Participant, and Developer.


    Default Storage: Once you have configured One Drive for business and you can navigate to each folder within your service as shown:




    Connector availability: You can configure the availability on this page:




  4. Create Workflow

     Create a new workflow for “Event Registration” by clicking on the “Create Workflow” button:


  5. Workflow Designer


    You are presented with two Workflow Actions
    Start event and Workflow complete.  

  6. Configure Start Event 

    On Connection drop-down, select Nintex and for the event select Form as shown





    The Nintex form will be available both web and also on mobile.   


  7. Design the Form 

     
    In above step, click on Design Form. You will be presented with plain Nintex form. You can drag-drop the control from the left panel such as Date/time, Email, File upload, Short text etc.   

    You can specify your own styles and Rules which are very similar in SharePoint Online.



    Nintex Workflow Cloud forms are responsive. You simply drag and drop form controls as shown:


    Each control is associated with a variable. For e.g. Name control is associated with name variable. You can turn off the “Auto Generate” option.    


    Click on the Done button.

    You can view all variables and their associated data type in our event registration form. 



    Click on Save button on the top left of the Nintex Form and give a meaningful description. You can also add users who can use this form and workflow.



  8. Design the Nintex Workflow 

    As it’s a basic workflow, you drag and drop two simple actions.
    Express Approval and Send Email.



    Right click on Express Approval and select Configure Option.
    In message box, you choose variables that you have defined in Nintex Form in previous steps





    and our name is captured from a variable. 



    Configure the similar actions.

  9. Publish the Form 

    Next, choose the environment and publish the form.




  10. Use the Form and Workflow 

    Now, our form is ready. You can use this form in your any website and put a code snippet any blog as shown:

 

There are a couple of excellent resources that you can access the references links below.

 

References 

If you can spare about four minutes to take a survey, you can have an impact on our community.

As you have probably read, we're preparing to move our community to a new platform. I'd like to know what you want to see in that new community.

So here's a survey where you can chime in. 

It's only six questions. It takes about four minutes to complete. But the more people who do it, the better an idea I'll have about the features you want to see.

Thank you!

 

Miss the link? Nintex Community Features Survey 

Coming Soon: Nintex Customer Central

 

We have some exciting news to share with you all about the forthcoming launch of our Nintex Customer Central portal.

 

Nintex is proud to announce the upcoming release, in March 2018, of the next generation of customer self-help web portal. In conjunction with our customers we have developed an innovative and intuitive self-help web portal.  

 

Tell me more!

These are some of the features that will be available in the portal:

  • Gain instant visibility to your usage summary of Nintex products
  • Ability to manage your Nintex licenses, renewing, upgrading or adding.
  • Ability to create and fully manage support cases
  • Omni-channel user experience between Nintex products
  • Access to Learning Central, enabling you to manage your consumption of Nintex training modules
  • Dynamic Knowledge Central tool enabling you to search for content across all Nintex assets
  • Access to product downloads, both current and previous versions
  • Ability to manage your own company and contact details
  • Unified dashboard leveraging all your Nintex touch points, including notifications

 

Sneak peek?

This is a sneak peek of the Dashboard (Design not final)

 

 Customer Central Sneak Peak

 

 

 Want to know more?

Over the coming weeks we will be launching a communication campaign with all our customers with further details and how to access the site.

 

We look forward to welcoming all of our customers to join us and experience the next generation of customer self-help portal.

 

We are yet to purchase Document Generation and forever finding ways to produce documents from list items.  We also don't have Print to PDF for Nintex Forms as we are on standard license, so it all requires rather a lot of work.  Some of the options we have considered in the past are, but not limited to:

  • Document library with columns and quick parts - passing the information from the list into the document library columns and using quick parts inside the document library to populate the document.  The workflow simply uses "create item" and adds the associated columns
  • Document library with content controls - use create item from the list to create a document in a library, and then use "update document" action in the workflow to update the content controls
  • SSRS reports - use reports to look at the list item data that can then be exported to word, pdf as required

 

I recently tried both document library approaches to create a document using a template from workflow and both kept giving me this error when opening in Word:

 

"We're sorry.  We can't open test because we found a problem with its contents"

Details:  No error detail available

 

I thought it was the order in which the document was being created and updated.  Or the information that was being passed in.  I raised a support ticket and we decided it was the table of contents causing the issue. This issue has recently been fixed so we upgraded workflow to no avail.  I wasted days and days and grew a few (more) grey hairs.  Then my lovely colleague and friend, Tosin, noticed that my document template attached to the document library was dotx format (word template).  This seems perfectly reasonable right?  Apparently not with this type of work.  I re-created my templates; one with quick parts and the other with content controls to be docx format.  And voila - they both work!  I haven't seen anyone mention anything like this on the community so I thought I should blog about it so that I can hopefully save others the stress I have had for the past couple of weeks (and also so that I don't forget next time I have a requirement like this).

Roll on the purchase of Document Generation!!

I have some details to share about big changes coming to the Nintex Connect community!

 

You may have seen my previous announcement about it: New Year, Renewed Community. The quick version of that post is that since the software underpinning our community is facing the end of its useful life, we're moving to a new platform -- very soon. In fact, we plan to launch the new community in the next few weeks.  First, we'll show the plans to attendees at the Nintex xchange conference, Feb. 26-28 in San Diego. You're registered, right?  We'd hoped to launch by then, but in trying to deliver the best experience, we thought it best not to rush things.

 

Here's a preview of what to expect.

 

What's happening when?

In order to launch the new community by our target date, we need to shut down this site and fire up the other one.  We'll put up a notification here in the community to let people know when that's happening, but now you know.

 

Between now and then, expect to see some areas of the community blocked to new content. I'll try not to do that until the last minute, as I don't want to prevent you from getting answers. However, we have to decide at some point that we're moving what's here to the new location, and we need to pick a stopping point so we don't leave stuff behind.

 

What will our new community be like?

 

For starters, It's going to be organized a little differently. 

 

Instead of somewhat vague titles like "Getting Started," with a few product areas thrown in, we're planning to organize the Q&A categories by what you're trying to do.  So, when you log in, you will see areas like "Workflow," "Forms," "Document Generation," "Analytics," etc.  Beneath those categories, you'll find a list of platforms you are likely using. 

 

So, if you have a question about building a workflow in Nintex Workflow Cloud, you'll go to "workflow" and then Nintex Workflow Cloud.  We haven't built the interface yet, but this picture gives you an idea how we're approaching it:

lithiumstructurepic

Some of our members report having a hard time figuring out where to put their questions, and with the new structure, they should be able to find things more easily. Sure, there might be some overlap, but this should cut down on confusion. Plus, at Nintex, we look at our array of capabilities as a platform, not individual products. This is a step in moving the community in that direction, too.

 

What this means for your existing content:

 

Q&A: We're bringing our questions and answers over to the new platform.  If you asked it here, you should see it there.

 

Blogs: I'm still working on where, or even whether, we will permit members to share blog posts. I'll give you an update when I have one.

 

The Nintex Product Blog content is going to merge with our corporate blog.  So, look for a product channel in the corporate blog in the very near future. Same writers, same content about the value of our platform and its new features and capabilities. Just a new location.

 

Documents/Downloads:  To streamline processes for our customers, we'll no longer have duplicate links to product downloads, Release Notes, or knowledge base content which are in the Customer Portal.  Support cases will still be opened at the Support site. Areas that don't get much traffic (like the Nintex Gallery) will be archived.

 

How points and badges will work:

 

Some of you love earning badges and points and showing up on our leaderboard. Truth is, I love how much you love it, so we will have what's called "gamification" in the new community, too. It will work a little differently there, and I'll post a blog on that later. But the main thing to know is that in our new community, you'll have an opportunity to earn a "rank," not just a bunch of points. You earn rank by providing content of value, not just doing a lot of activity that may or may not be of value.  Here's a look at how rank, badges and the like appear in my profile on the Lithium community for community managers:

lithiumprofile

 

The community score is a number that represents influence based on feedback to the content you post.  You rank up when other members value your contributions.  The more value you provide, the higher you'll rank.  And it's not a game with only one winner.  Many people can be "valued contributors," or even "experts."  Just like real life.  This allows newcomers to raise their rank without worrying that they can never "catch up" to people who are seasoned Nintex veterans just because they've earned more points. But there will also be more and more ways to raise your community score, so highly-active users will always have something to strive for. See those badges above? More on those later, but those are earned, and can be put together to earn "trophies."  It's going to be much more involving and interesting than our current leaderboard.

 

Some things to know as we get closer to launch:

 

  • I'm going to start closing off areas of our community to new content to simplify the move.  For example, the Dev Talk is closed to new questions so I can move them to a better place in this community before we move the lot to the new platform.

 

  • Your inbox messages won't be transferred to the new platform. Nor will status updates. If there's something in your inbox you want to keep, copy/paste it somewhere now. I can't access your inbox now, and won't be able to after the move, either.

 

I want to thank you for taking the time to read this update. There's more to come. Be sure to "follow" me (hover over my name above and click "follow" on the pop-up card) so you can get notifications when I create new content. And follow me on Twitter, where I'll post updates like this.

 

I'm looking forward to the new community rolling out, and your participation in it!

So I made a rooky mistake and thought I would share so that you can all see that I am only human too, and sometimes, no matter what experience you have working with certain technologies, oversights can be made...

I had a very old solution (not mine) that used an InfoPath form and a workflow that run on all updates with a Run if action at the very beginning checking if the email flag was checked.  This had been working fine for a long time but the customer reported that they wanted the form slightly changed.

In good old fashioned InfoPath style, it informed me changes had been made in the list that needed to be reflected in the form (and rather unhelpfully didn't elaborate on the changes).  I needed to add this change for the customer so I accepted and published.  User was happy for a day or so until they realised that one of the dropdown controls had become unbound...!

I won't bore you with the details, but here is what I did.

  • the column was missing for whatever reason in InfoPath
  • time was limited so I created an additional column in my list, and used that in the InfoPath form
  • Using quick edit, copied the data from old column to new column

 

All perfectly reasonable right?  But what did I forget...?  Oh yeah, that workflow that run on modify of every single item.  That particular workflow emailed about 50 important people in my organisation...  and I sent 65 of them!  (shudder).

So after 24 hours of sobbing and panic, I calmed down and realised that this mistake was a simple one; one anyone could have made.  No process in place would have prevented it as I simply overlooked it.

 

Feel free to make me feel better with your rooky mistakes in the comments below... 

Many thanks to the people who hit the top 25 on our community leaderboard in 2017!

 

The top members of the leaderboard get there because of their contributions to the community. We reset the points to zero every year and see who bubbles up to the top.  Every few thousand points, you earn a new reputation level, the top one being "Rock Star."

 

Well, we had FOUR Rock Stars this year!  Congratulations to Marian Hatala, Cassy Freeman, Tomasz Poszytek and Rhia Wieclawek!

 

The contributions of all our members are valuable because they contribute to what makes this community so great: people coming together to ask questions, find answers and share knowledge. Here are the rest of the top 25:

Fernando HunthChris Ben, Jesse McHargue, Mike Matsako, Enrico Knapp, Andrew Glasser, Ryan Greenaway, Paul Crawford, Brendan Murphy, Giacomo Gelosi, Courtney Vargo, Lachlan Ainley, Eric Harris, Dan Barker, Sam Sysum, Aaron Labiosa, Chris Ellis, Manfred Lauer, Joshua Tan, Lakshmi C, and Brad Orluk.  Their point totals are in the images below.

 

Following our annual reset of points last January, I set our highest reputation level at a lower level - 20,000 points. It used to be a virtually impossible 80,000 points. My rationale was that I wanted to see how many members would reach the highest level in our community if we only made it a teensy bit more attainable.

 

Nobody had ever accumulated even 20,000 points, so I thought perhaps we'd have one person. Winding up with four is pretty amazing.

 

Points are accumulated for the contributions made in the community. From a couple of points for receiving a "like" to a couple dozen or so for receiving an answer marked correct.  The top contributors provided a great deal of value to the community, not to mention personal time, to help mark hundreds of answers in 2017.

 

It's worth noting that the mix of people says a lot about Nintex Connect. A lot of communities are dominated by one type of member. We have a nice mix of customers, Nintex Partners and Nintex employees in Connect.  And they all contribute to a helpful atmosphere that makes this place great. 

 

xchange banner

 

I hope you'll take the opportunity to make our connections personal by registering for our Nintex xchange conference.

 

 

 

As you may have already noticed, we have reset our points scheme for 2018. You can read about that annual event here.  I'm not going to set a new ladder for 2018 because we're going to have a new way to earn community cred in a new community! You can read more about that here: New Year, Renewed Community.

 

I wish you all a great 2018!

 

leadersleaders2

As we prepare to embark on a new year, I'm spending a lot more time looking forward than I am looking back.  That's because there are big changes in store for the Nintex Connect community, and I'm very excited about them!

 

Here's what's happening, why, what that will mean to the community, and when you can expect things to change. 

 

The biggest news is that we're moving our community to a new platform!  I thought it might be helpful to provide a little timeline about our community to explain what that means.

 

Long-time members may recall that this will actually be the second time we've announced a move for our community.  Nintex once had a set of forums for several years before moving to community software (called Jive) in the summer of 2014.  We spent three years growing from a few thousand members to about 20,000 today. This past spring, we learned that Jive was purchased by an enterprise software company called Aurea...

 

timeline

 

Aurea decided this past summer that it wasn't going to pursue the external community business any longer.  That's a community like Connect, which is for a company's customers and partners, not just their employees.  Aurea sold that part of the business to another company, Lithium.  Lithium is a long-time leader in the social business software space.  After careful exploration, Nintex decided to move forward with a migration to the Lithium platform. In part, that's because Lithium has committed to folding the best of Jive into it's own platform, which has some great features of it's own, as I'll get into in a bit.  We'll be joining some successful communities that use the same platform, such as Bose and StubHub.

 

We'll also be one of the first Jive customers to move, so Lithium has committed to moving us quickly, with minimum disruption to you, our members.  Lithium has put the wheels in motion by assigning us a team experienced in making these transitions.  And Nintex has already corralled the resources needed, too. I've met with people across several departments, and we're ready to get to work.

 

We're not just "changing the drapes" in our community with this move, we're making it better experience! In addition to being on a platform that will have fewer bugs and more regular updates than we have now, we'll have other features. One big one is that we're working on providing a single sign-on experience, so that if you log into the community or the customer portal or the new Learning Central, or Partner Central, you can move seamlessly among them without having to use a separate registration.

 

It's also going to be easier to find what you're looking for,  interact with and help your fellow community members, and there'll even be a new way to earn your community reputation.

 

Perhaps best of all for some of you, after this last time, we will stop doing the annual resetting of points!

 

I'll provide more details in regular updates as we start building the new community.  But if you want to be one of the first to see the new community, I recommend attending Nintex xchange, because we plan to unveil it in a session at the conference in February.

 

Thanks for being with us, and for coming along as we move.  I am confident it's going to be a great experience!

You can download the Nintex Form, Workflow and List template here.   

Introduction  

Why Document Generation?

Consider this scenario where departments wants to create a Human Resources NDA for external vendor, Sales department requires sales quotes, Management requires report etc in various Office formats such as Word, Excel, PowerPoint etc.

 

 

These processes are extremely manual and tedious as follows:

  • Ad-Hoc documents
  • Take too long to create
  • Opportunity for errors
  • And most importantly, no integration with other systems.

 

 Therefore, hampers the productivity of an organization. 

What is Document Generation (DocGen)?        

Nintex Workflow helps to generate documents by connecting relevant department, leverage your business process and content in your digital workplace. You also have opportunity to integrate other systems such as Office 365, Box, Salesforce and you can also utilize Adobe Sign or DocuSign for electronic signatures.

 

 

With DocGen you can connect to ANY DATA and not just Office 365 but you can get from Microsoft Dynamics, SQL Data. ANY DOCUMENT (Office Documents) and it could be NDA, Contract, Supplier Information etc.  ANY DELIVERY which could any platform such as Dropbox, Box, Microsoft Dynamics, Adobe sign.

 

 

 

Below are some samples for Generating documents across teams and functions.

 

 

 

Document Generation Benefits

 

  • Productivity - Automate the generation of standardized documents.
  • Configurability – Assemble documents using data from business application, all inside Office 365
  • Accuracy – Ensures consistency and accuracy in business-critical documents.         

 


Prerequisites

 



Step by Step

 

  • Create and configure the custom list

    You create a custom list named Supplier Contract Form.





  • Nintex Form

    Make a simple Responsive Nintex Form 





  • Nintex Workflow  

    Part 1: Section Document Generation Action
     
    For Document Generation, you a couple of Workflow variables. These Nintex Workflow variables will be used in our WORD document dynamically. You need to fill all the variables that you used in your Nintex Form as shown. 


    Drag and drop Set Workflow Variable action and configure as shown:





    You need to get ALL the Nintex Form into Workflow variables.

    Drag and drop Document Generation action and configure as shown:







    In the Document templates section, click on the Add document template.

    a)
    You need locate a SharePoint Document Library in the Template document library section. In this example, you can create a sample document library called “ContractTemplates”.

    b) Upload any WORD document in this document library. You can name it ContractTemplates.docx. This is an ordinary word document.

    c)
    Click on the Insert button.

    d)
    Once you have chosen the template, click on “Tag Document



    e) A word document will open as shown below. It has to be noted that all Workflow variables are referenced here within the Nintex Document Tagger which makes the magic. You can drag drop Supplier Name from the Nintex document tagger and drop to Word document. You can do the same for other workflow variables. Once you are down, you can close off the word document. 
       
       

    Part 2: Section E-signatures with Adobe Sign

    Drag and drop Adobe Sign action and configure as shown:






    a) Initiator MUST have an Adobe account, otherwise your workflow be suspended.

    b) You can configure when the agreement will be expired. In this example, we set to 2 days.   




    c) In the SharePoint relative URL, you need to supply the relative path of document library. Please note that you have to use PDF extension. Otherwise you will get File not found error. 



    Remaining part of workflow is straightforward.




  • Walk through the solution 


    Assume, your organization (Contoso INC) wants to send the Supplier agreement to a service provider/vendor who does not have Office 365 account. Let name the service provider InfoSys India and the person how in charge for this contract is John Smith who has Gmail Account. He does NOT require Adobe Sign account either.   

    You fill the form and Submit




    After few seconds, the workflow status show “Generating Supplier Agreement”



    In few seconds, a PDF document (Powered by Nintex Document Generation) will be generated



    and you can see the all the agreement details for the Supplier agreement as shown:



    Now, something you have to take note. Adobe requires Nintex to authorize this “Supplier Account” document as shown:


    You as Contoso admin have to click on the “Authorize 'Supplier Agreement' Nintex workflow to use your Adobe Sign account

    You as Contoso Admin needs to login:

    Nintex workflow will subsequently use your Adobe account for subsequent workflows.  



    Now, let’s switch and check how John Smith will receive this Supplier Agreement document in his email. He will receive a “Supplier Agreement – InfoSys Indialink to review the document.

    Also note that you have 2 days expiry. Therefore, the document will be active only till 15 Dec 2017. 

      




    He reads the Supplier document and at the end he has option put his digital Signature as shown:



    Later he signs digitally with many options such as by Typing, Drawing, image or Mobile. 



    John decided to Draw his signature and click on Apply button.



    At the end, he signs with date and time:



    Next, screen asks if John wants to sign for free trial. He can just download the agreement.







    Contoso INC will receive an email with digitized copy in PDF format with John’s digital signature.

    You can download the Nintex Form, Workflow and List template here

    I hope it will help the community.

(UPDATE for January 4th at the bottom of the post!)

 

It's time for our annual reminder that we're going to zero-out the points in the community and re-start "the game!"

 

It has been our habit to erase points at the end of each year, declare the top people on the leaderboard our champions, and start over.  Champions typically have an icon like this next to their names: champion badge

 

resetWhy reset?

 

Well, given the way gamification is set up on our community platform, a new member has no way of racking up enough points to show up on the leaderboard, no matter how great their contributions might be.  Resetting the points provides an incentive for everyone to see what their contributions will do.

 

Has it worked?  It seems to.  We've had a new champion atop the leaderboard all three years of this community. 

 

And, we're doing it again.  Sometime around Dec 31, our platform provider will delete the points for us and we'll start over in 2018.  And here's a little teaser: Our reputation game is going to change dramatically next year. I'll say more in future blog posts, so follow me and keep your eyes on our homepage and Twitter feed.

 

Is this annual move a disincentive to long-time members who've made grate contributions to the community? It might feel that way, but existing content is really a sort of head start on earning points in the new year because any interactions with it are easy ways to accumulate status points. And even though a new person has landed at the very top, a lot of familiar names wind up in the top 25 annually.

 

As a reminder, we've done this every hear, and here are two examples:

It's Time to Reset the Points Again! 

Points to Reset for New Year! 

 

For fun, here's a look at the list of winners from the first year the community launched: Nintex Connect 2014 Winners  I'll publish another list at the end of 2017.

 

You still have time to accumulate points and badges. Here's how: Badges and Earning Points on the Site 

 

Enjoy these last few weeks of 2017!

 

NEW:  Our platform provider encountered a problem resetting our points. So, you get to live with them a few more days. Before they disappear.  But I expect the reset to happen any time now. I'll follow up when the reset is complete.

Filter Blog

By date: By tag: