do not have experience with 2016 yet but I do not expect a change in this regard.

if you do not explicitly directs state machine to change state (change state action) or end state machine or even end whole workflows, it will loop  within current state forever.

you can as well use change state action to switch back to the current state at next turn.

but in both cases you have to be careful so that you don't end up with an infinite workflow.

Interesting question.  I ran a test in 2013, and you can call the same state from within the state.  Here is the workflow I setup and it worked.  My question would be though, what is a scenario that you would need this?  Why not just build a loop within the state?

Thanks, Marian.  Do you happen to know if the looping effect is by design, meaning did Nintex develop that on purpose so you can loop within a state?

Loops require additional control flow logic to evaluate on each cycle whereas switches/conditions/task outcomes and state changes are generally easier to understand for the business user because they create visual branches, like in your example.  This is the main reason why I prefer recursion over looping.  Nice to know this works in 2013!

I ask mainly because I get requests for custom task delegation constantly.  Easiest way to do that is have a task outcome called Delegate and a field on the task form for Who.  The current task ends with a Delegate outcome and the state recursively calls itself with the new user in the Assigned To variable.  All this takes is two actions: Set Variables and Change State.  Super easy, and conveys the point as clear as day to the business, plus you can then do things (like talk to Hawkeye) in between assignees.  Just wasn't 100% sure that was possible, but it seems like it is.

NINTEX's state machine is nothing but a loop. so, it's by design.

check the docu - http://help.nintex.com/en-US/nintex2013/help/#Workflow/RootCategory/Actions/Nintex.Workflow.StateMachine.htm%3FTocPath%3… 

Hence why it's affected by the Enforce safe looping setting.  Thanks for the documentation reference!

hm, I do not know your exact requirements, but note that you do not delegate the task this way but rather let create a new task for different asignee(s). it doesn't matter whether it's within the same SM branch or another.

so if you have eg several assignees you  need not be able to 'delegate' task this way just for one of them.

if your concern is about delegation you might want to look on following Cassy Freeman‌'s blog