cancel
Showing results for 
Search instead for 
Did you mean: 

January 2017 Mission

Not applicable
9 85 7,177

What is Your New Year Nintex Resolution?

Over time we all develop certain habits of doing things; right, wrong, or indifferent. I challenge everyone to reflect on some of the things that they do with Nintex that they know they should not, but have simply fallen into a habit and keep doing. What are those habits and how can you correct them?

 

For this mission, simply share some “bad” habits that you want to change for the better. Then a quick tip or advice for new Nintex Users on how not to fall into the same habits.

 

Let’s kick off this New Year making ourselves and others better!

What you get

badhabitsbadge

Get 50 points for leaving a "bad habit" and 100 points for a tip or piece of advice for avoiding the bad habit(s)!  Total available this month: 150 points!*

Many thanks to Blue Ribbon Group Member Jesse McHargue‌ for creating this mission!

*This will be a manual mission, not automated, so in early February, I'll peruse the posts below and award points and badges.

85 Comments
jesse_mchargue
Nintex Newbie

I wanted to kick off the New Year with this one for a few reasons, but primarily want to share some tips and advice to other users. Some of us have been doing this for years, some only a few months; so I am eager to see what other people do in their typical day-to-day when dealing with Nintex.

For me, some of the "bad habits" that I have formed tend to be that I create more work than I need to. I will recreate a workflow rather than exporting and then importing it when moving from one environment to another. I find myself over-thinking a solution as well rather than simply creating the basic functionality. I offer up "extras" that we can do because Nintex is so easy to use and that it takes minimal time and effort to produce a working solution, that I find myself making the task larger than it needs to be (I scope creep myself sometimes!).

My advice would be to Keep It Simple (Silly). I know it is something that we have all heard countless times over, but honestly, it can save you hours of effort! If you need to test a workflow or form in a test environment, use the export/import functionality to move it rather then going back and forth to recreate.

Also, and it pains me to say, but Nintex is not ALWAYS the solution (there I said it!). If you know of something else that will work and can get it up and running in less time, then by all means, do it! I will do this with InfoPath (yuk!) when a customer needs something in a pinch and they do not care what it looks like. Later on, I will make a point to go back and revamp the form using Nintex. Knowing what tools to use for what job is critical in development! I always say, just because I have a chainsaw does not mean I need it to cut paper.

TomaszPoszytek
Nintex Newbie

I found recently myself doing the same bad thing over and over again but at least when I realized doing so I'm now trying to keep that in mind and to avoid that.

I guess everyone faces the situation, when the need to create a temporary variables is very high, for example to store current counter value, to store current date, to store... whatever else, that needs to has it's DEFAULT value at the beginning.

For a quite long time I was setting a separate action, at the beginning of the workflow, to SET EACH SUCH VARIABLE's DEFAULT VALUE. For example 0 for the current counter, current date for the date variable and so on. However there is no need to waste precious actions for that purpose  The right way to do that, is to simply check the checkbox in the "initiation" column (on the Workflow Variables form) and then using the "gear" icon set it's default value:

Of course it shouldn't be done that way in case you want to allow users to start workflow manually - in such case user will be able to alter the default value as it will be shown on the initiation form. However as in most cases workflows are triggered automatically, this is a really good approach to follow

Regards,

Tomasz

Chris_Ben
Nintex Newbie

One good habit to form is sensible logging.  It helps out so much, especially when you're trying to debug a new workflow. 

The bad habit

A bad habit that I've seen and, cough, sometimes been found guilty of myself, is keeping unnecessary logging actions in your production workflows.  This is bad - just check out Aaron Labiosa‌'s Defensive Workflow Design article to understand why lots of logging actions slow your whole system down.

The remedy

How do I combat this when moving from test to a production environment?  First I name those debugging logging actions with some sort of keyword in the action.  e.g.:

then when you publish that workflow to a production environment, you can easily identify the logging actions you don't need.  You can either disable them or delete them. Up to you!  Just remember, logging is good.  You will want some logging in production but probably not everything.

Cheers,

Chris

 

andrewg
Nintex Newbie

My bad habit is not cleaning up after myself. Not just around the house, but with forms and workflows also

I was a bit embarrassed when I went back to update a workflow I worked on 8 months ago and found that I had over 60 versions saved! That's a lot of data that is no good to me. And the databases keep their records and it takes up space that can lead to other issues down the road. I had that many because there was a certain part of the process that was difficult to test. 

Whether it be multiple publishes on forms and workflows, left over Log to History actions, history lists of test/dev data, or any other development collateral, make sure to keep track of it. 

Some tips to prevent this is to use a separate site collection for development and testing and import the tested workflows and forms to the production area. Or use separate lists to store history information in while testing or delete it all afterwards. I use these documents as help

And all the defensive workflow design blogs.

You can also delete previous publishes of workflows in place. The habit I should make is reviewing these areas when pushing to prod!

andrewg
Nintex Newbie

If its an epidemic, then its not a personal bad habit right?  

mmatsako
Nintex Newbie

Wouldn't it be nice to have something along the lines of a "test mode" option in workflow settings, where you could check and uncheck it.   The same for each action - so if test mode was checked on an action, and you unchecked the test mode option in the workflow settings, these actions could automatically disable.   Ah yes, wouldn't it be nice.  

Chris_Ben
Nintex Newbie

Very nice!   I'd be using that for a few send notification actions too!  UserVoice?  Or is there already a suggestion for that?

mmatsako
Nintex Newbie

Right on! At a glance it appears they are working on a Debug mode, but I posted up an idea just in case it gives them some more ideas on whatever it is they are implementing:  Test Mode – Customer Feedback for Nintex   Vote it up!

Chris_Ben
Nintex Newbie

3 votes have just been added

praios81
Nintex Newbie

My problem is - as mentioned before - that during development I get a lot of logging actions in my workflow that are helpful while debugging, but once the workflow is finished noone ever needs or should even be able to know some things that I'm writing to the log.

My resolution:

First advice to myself is to take the time to cleanup after finishing. Is as important as developing the workflow itself.

Second, if the workflow is very complex and I will likely have to debug it in the future, I create a workflow constant "debug mode" and in my workflow I add "run if" actions with a check to that constant. Insinde of them I place my logging actions.

renskes
Nintex Newbie

Bad Habit: Not creating separate Workflow History Lists for different workflows when setting up workflows in the development stage. Then I have to go back in at a later stage to add all the different workflow history lists and I need to open each workflow and point it to the appropriate workflow history list.

Tip: Have two screens open when setting up workflows. One for the Workflow Designer and one for the page of Workflow History Lists. Then before you publish the workflow in the designer add a Workflow History List for that Workflow. In the settings of the Workflow designer just select your new Workflow History List to log the history to.

This way you will not have one big Workflow History List (which could result in various problems later on) but a few smaller, manageable workflow history lists.

Hope this helps

eiben
Nintex Newbie

Added my 3 votes as well!

eiben
Nintex Newbie

Bad habit:

Not catching errors and acting accordingly, especially when working with web-service calls. Why bother - when it works during development, what could possibly go wrong at production? Especially when the web-service calls depend on some kind of user input ...

Resolution:

Always check for errors and "gracefully" terminate the workflow. Do not leave errored workflows behind, but instead either compensate errors within the workflow or terminate the workflow and send out a notification.

cassymfreeman
Nintex Newbie

‌ you always blow my mind - I didn't know you could delete previous versions!! I will certainly be doing that!

cassymfreeman
Nintex Newbie

My bad habit is that I am too quick to get on the designer without thinking through the solution.  More often than not this means I tie myself up in knots with permissions - this is a pain because generally I am SCA and I have the power and when I release to users they face all sorts of permission issues when the workflow updates an item etc.  I need to spend more time thinking about the design in terms of permissions and test as a normal, un-Godly user.

 

My hint and tip for everyone who has colleagues who also develop workflows is to LABEL LABEL LABEL your actions so that anyone picking up your workflow can see what you are trying to achieve.  It really doesn't take that long to make your workflow self documenting and your colleagues will thank you if they ever have to support it in your absence.  I am always harping on at other users in my business to do just this!

murphybp2
Nintex Newbie

I do the same thing but use a list to turn it off/on, similar to this post Using Workflow Configuration Lists in O365.  That way I don't have to edit the workflow to turn it on/off.  I just change a field in a list. 

murphybp2
Nintex Newbie

I accomplish this by setting up a separate list that has the workflow name, and a field called "logging" that is a yes/no field.  I then create a UDA that does a lookup to that list and returns the logging variable.  At the beginning of every workflow I check that value and set a variable with that status.  All of my logging actions are within a "Run If" box that only runs if logging is on.  That way I can easily change it to off/on without editing the workflow.   

murphybp2
Nintex Newbie

Bad Habit: Building a single behemoth workflow for a process that is a pain to debug and causes issues if it ever fails, because you have to start it over from the beginning.  I've gotten better over the years of breaking up processes into smaller workflows and then starting those from other workflows.  It's also nice because I can then see a status for each stage of the process. 

 

Tip: Use UDA's. There are many times I find myself copying the same steps from one workflow to another, and then later one if I have to make a change to those steps, I have to do it in every workflow.  I've found using UDA's to be a huge help in reusing processes and keeping it the same across workflows.  If you ever change the UDA, you can push the changes out to all the other workflows.

paul_crawford
Nintex Newbie

My bad habit(s) include most of what people have already posted!! Shame on me!! to add another would be leaving variables in the workflow that are no longer used. Workflow development very rarely ends as you started and after taking many routes and changes to the design i always forget to rmove redundant variables.

My tip is just to take time and review. Its always good to get a process completed but definitely reviewing the final solution is something i will be doing.

greenawayr
Nintex Newbie

My bad habit has always been poor labeling of comments (it's the same when I write code, I know what it does, that's all that matters, right?). However I did make a concerted effort to change this, but it's an off-shoot of working on my own rather than with a team in small companies for the early part of my career.

My best practice is like most others on here. Reusable. Variables, Constants, Snippets. If you can use them do it. It saves time and prevents inconsistencies.

greenawayr
Nintex Newbie

Have 3 more from me

greenawayr
Nintex Newbie

Hahaha, having posted my reply before reading this, you could have easily made the mistake of thinking we worked together and that I didn't label my workflows enough!!!! 

cassymfreeman
Nintex Newbie

haha I did wonder when I saw yours!  I almost tagged you and ‌ but didn't want to name and shame...  oops now I have

mmatsako
Nintex Newbie

So many good - bad habits already mentioned, but here is one:

Bad habit:   Using the default task list for tasks, only to remember that it would have been better to use a task list specific to this process that I had already created for this purpose.

Fix:  Under Workflow Settings (On-prem,  O365 is just called "Settings") you change select a different task list to target.   Separating your tasks out this way really helps managing them easier.

greenawayr
Nintex Newbie

I'd call this two tips. I'm not sure everyone thinks about creating a new workflow history list for each workflow. Not something I have done regularly. Although in my defense, many workflows I write relate to the same process and therefore it's helpful to keep all the logging and history in the same list, or they are a number of small workflows that don't write much to the history list.

However, If creating a number of "busy" workflows in the same site I can certainly see why this would be useful.

jackgelo
Nintex Newbie

Pheew..I'm not the only one with some bad habits that I try to fix..

Bad habit: In order to make it easier for the customer to understand the workflow, I started building workflows as one unique workflow..it's good if the process is not so complex but usually requirements doesn't allow a simple workflow and because of their change during development (yes, who hasn't a customer that changes always requirements?) it's common to have a big workflow..

Tip: Now I try to build it in some more scalable way, using several small workflows so it's easier also to find and solve an issue in it without having to restart the whole process for all running instances. (and yes, UDAs and comments like in other previous posted tips are very useful for a better management of workflows)

burkslm
Nintex Newbie

My Bad Habit: I do not create separate Workflow History Lists for different workflows. All of us developers were corrected on this. I still sometimes forget because there is a default workflow history list that gets set and makes me lazy. 

Solution: Try to make it a point, when you first create a workflow to point it to a newly created workflow history list. This prevents your list from building up from so many workflows pointing to it.

Other People's Bad Habit (just dealt with this today): I hate this one- people like to hard-code email addresses in email notifications!!! I hate that. I've had to go into emails and change them when people leave their positions and are replaced.

Solution: Email addresses should never be hard-coded. There should be list a or group that you can refer to instead. Any changes that are made can be made in that list or group and no change to workflows will be necessary.

sharepointsean
Nintex Newbie

Hello ‌,

This is an excellent idea and I have just added my 3 votes to support it.

janvonreith
Nintex Newbie

Great idea! Thanks for this one! :-)

janvonreith
Nintex Newbie

Very good mission, I already found some very good solutions that'll add to my best practice list!

 

Here's a bad habit that I witnessed a lot of times.

 

Bad Habit:

I'v seen a lot of workflows that include values/parameters that are evironment specific, so when the workflow is exported out of the test environment and imported into the production environment the values need to be changed afterwards. This of course extends the effort for the implementation in the production environment, furthermore there's the risk that not all necessary values/parameters are getting changed, which will lead to unexpected behaviours.

Solution:

Work with workflow constants, so that the environment specific values/parameters can be stored in the constants. The Workflows can the be exported and imported withount any changes afterwards! Furthermore use the common Nintex variables like "Current site URL" so that you don't need to manually add the URL of the current site for example.

fhunth
Nintex Newbie

Bad Habit:

Not to have daily versions of my forms

Solution:

  and then upload it to my TFS.

Warwick
Nintex Newbie

Variable Naming - easy to quickly slap in some text whilst in dev mode but when you go to review or select elsewhere you don't know what you're looking for.

Come up with a naming convention and stick to it. I like v+fieldtype+Usage, so to get the managers Title vtxtManagerTitle

There is also a great presentation in the Nintex Learning center from a presentation at InspireX "Best Practices In Workflow Design, with Intellinet" which has some good tips

Chris_Ben
Nintex Newbie

Funny that you mentioned naming conventions Warwick because I just blogged about it last week.  Good timing!

christopheraucq
Nintex Newbie

Hi,

Bad habit: Thinking Nintex is so easy that you begin developing your workflow without thinking/drawing your solution before.

Tips: Open this post and download the DUCERIM.

I also recommend this post. Most of the workflows uses statuses. If you the workflow is stuck, you would like to be able to relaunch the workflow in the status where it stopped. Here is the template you need to use for that.

Christophe

kmorry19
Nintex Newbie

Bad Habit: Forgetting the power of logging in history list. Makes debugging so much harder without it when it would have taken me 2 seconds to add the action in and write out what is being stored in variables.

Tips: Take the time to future-proof yourself and save yourself a headache in the long run by adding a description to actions and logging in history list. So easy to forget especially when you're building the workflow without the solution properly mapped out.

andrewg
Nintex Newbie

I've seen that presentation before!

Chris_Ben
Nintex Newbie

Also verbose logging for on-prem comes in quite handy.  Just remember though, if you're using it in production, only turn it on temporarily as it writes a ton of information to the Nintex workflow database!

burkslm
Nintex Newbie

Yeah but I have Nintex Workflow 2013.

Chris_Ben
Nintex Newbie

Therefore you have the power.  Use it wisely

jesse_mchargue
Nintex Newbie

Warwick Ward‌ - 

I wanted to give you a personal shout out as you had mentioned something along similar lines in your post in World's Easiest Nintex Connect Mission . 

Warwick Ward wrote:

My suggestion would be one page where everyone comments with their best 1 liners, be it a quick tip, new starter advice, best practice note e.t.c... top 5 one liners with most likes get 1 millions dollars each!!

Sorry that it is not $1 Million for the best one liners...

Warwick
Nintex Newbie

forgot about that one!

greenawayr
Nintex Newbie

We have attempted this. We do this for Major versions only though so it's not true source control. 

akrasheninnikov
Nintex Newbie

Isn't it enterprise-only?

kelliganp
Nintex Newbie

Bad Habit: Multitasking. What! you say? Isn't multitasking a virtue? I say no. In reality, I have found that when I multitask, I end up do several mediocre jobs instead of one thorough job completed with excellence. I know conventional wisdom says that a person can and should be able to multitask but I just do not see it in me or others that I have had the opportunity to work with and/or observe.

 

Tips: Do not multitask. Carve out times to work on a given project and compartmentalize it from email, phone calls and other projects. Suppose you get a great thought on the TSA account you work but you arte in the middle of form building on the ASP program's Safety Audit System? Ok... write the cool idea down where you will find it later and move on with the ASP project. Either pick up a project and do not put it down until you are done or perhaps find a natural break point where the work can be set aside with minimal restart confusion. Or how about you try scheduling work for different days of the week or maybe morning vs. afternoon. this way, you will be able to articulate progress on multiple projects without the "mind mess" involved in trying to handle them both at the same. This way, you do not loose the time is takes to get back into that state of flow on a project. Also, determine when you are going to check and respond to email each day and stick to it.

Chris_Ben
Nintex Newbie

Hi Alexey,

Not as far as I'm aware.  It does need to be enabled in central admin though so that might be why some people can't access it.

Cheers,

Chris

tschaef
Nintex Newbie

Bad Habit: A bad habit that has caused me issues is developing a workflow that works and then going on to the next one without documenting how the first workflow was built and why certain actions were chosen. Later I want to use the workflow as a shortcut to building a similar, but different workflow or someone else wants to do something similar and asks me questions about my workflow, but I can't remember why I made certain decisions.

Tip: Starting this year, I'm going back to previous workflows that I use a lot as the basis for other workflows and document each control and why I chose it and posting it for team members usage. This will help me and team members when I want to use a workflow and tweak it for another use. Also, as I build new workflows, I'll document after I test sections of the workflow and determine they work the way I want them to. I need to stay on top of this, so that by the time the workflow is implemented and I'm ready to move on to the next one, I have documented how the workflow was built and the decisions made in building the workflow.

tschaef
Nintex Newbie

Tip: For larger workflows I test out sections of the workflow and save them separately as snippets, then I add them together at the end for the complete workflow. This helps me re-use the small sections in other workflows.

Warwick
Nintex Newbie

Have agree on this one, I succumb to Monkey Mind with improvement ideas for other workflows/forms/solutions when I'm working on a current one. Certainly need a plan to keep on task and get stuff done!

amolvaidya
Nintex Newbie

some really good tips already listed...

Here is a quick one from me:

Bad Habit: Lack of workflow documentation. Sometimes we forget the logic or hacky actions. Few times I have removed actions which looked useless but actually were some good ideas to circumvent bottlenecks or absence of feature.

Solution: Use all 4 comment area of an action. I usually try to document the workflow right at design time. Some may argue this will increase the workflow size...but honestly this suits me. I always break my workflows into small chunks never going beyond 50-60 actions

Here is a peek at one such comment

greenawayr
Nintex Newbie

Sounds like you need a Pomodoro!