Skip to main content

  Unbound rules are a great feature in K2. This allows you to create a rule and later call the rule when you need it. For instance I can create a single rule to update a Smartobject. If I have 5 or 6 states within the form I can simply call the update rule whenever it is needed. Here is where unbound rules are beneficial. Say you do not use unbound rules and you have to create a rule on each state to update when the form is actioned. If you make a change or add a column to the smartobject then you will have to modify each rule on each state to reflect that change. If you use an unbound rule and simply call the rule on each state when needed you will only have to modify one rule.

 

If you use a naming convention on your unbound rules it makes it really easy to troubleshoot your forms and it looks very clean. We divide our unbound rules by Rules and Sub Rules. A sub rule might be a single action. A main rule might call multiple single actions. And example would be..

 

"Rule Update SmartObjects"

   Execute Sub Rule Update Main Smartobject

   Execute Sub Rule Create Comments

   Execute Sub Rule Create Attachments

 

Another example would be 

 

"Rule Show Message and Navigate"

    Show Message (Form Submitted Successfully. Click OK to Continue)

    Navigate (Back to entry form or maybe a search form)

 

Usually you would have to write each of these rules on an action. But having an unbound rule allows you to create the rule once and call it where you need it. It also looks cleaner in the form rule.

 

13516i5B94EB31440B7C6E.png

 

I can look at the rules and it tells me exactly what each step is doing. If I encounter an issue in the form I can look at this and determine which unbound rule is causing me trouble. It minimizes the risks of making changes that can break the form and I am making a change in a single place and not on every state in the form.

 

 

 

Thanks,

Bryan Peters

 

Hello Bryan,


 


Great way to cut down on some of the issues between states. However, I wanted to add a caveat ot your solution. Using too many Unbound Rules (10+) on one form can become quite the hassle to troubleshoot if an issue occurs. I recommend keeping unbound rules to under 10, and try to keep nested Unbound rules to a minimum. It can simply be too confusing when coming back to the rules and editing them. 

Agreed. Nested unbound rules are too confusing and it makes troubleshooting tough. However with a good naming convention when looking at an action rule such as Initialize or on click I can have a list of actions that take place. This makes it easy for me to troubleshoot because I can go directly to the unbound rule that is causing the issue.  The idea is to keep the unbound rules clean and simple. Name them for the action they are performing. If an error occurs during a certain action such as a smartobject error the unbound rule that is associated with that smartobject can be troubleshooted easily without causing additional errors in the form. An example.

 

On Button Click

 

Execute Rule Update Param

Execute Rule Create Entry

Execute Rule Create Attachments

Execute Rule Create Comments

Execute Rule Show Message and Close

 

As you can see above each rule is a simple rule that completes a specific task. I can look at this rule and see step by step what happens when the button is clicked. If an error occurs I can easily pinpoint which unbound rule is the culprit and fix it. The rule of thumb that we use is an unbound rule has to be simple and complete a specific task. The rule has to be simple enough that the naming convention describes exactly what it does. No nested unbound rules. Generally if we create an unbound rule we do it only because it will be called across more than a single state. Any other reason to create an unbound rule would be pointless. 

 

If those guidelines are followed then unbound rules can be a great thing. Anything more complicated than this can cause a huge headache. 

 

Thanks,

Bryan Peters

 

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings