Skip navigation
All Places > Training > Blog
1 2 3 Previous Next

Training

43 posts

Hello customers and users of the Nintex Workflow Platform! If you're interested in training, we're building a new experience for you to access Nintex learning material. After December 14th, use learn.nintex.com as your link for Nintex learning and certifications.

 

This post will be updated as the new training domain progresses. An FAQ will be attached based on questions that we receive. If you have questions, please do not hesitate sending them to training@nintex.com

 

Thanks!

The Atlantic magazine just published a great article on The Coming Software Apocalypse. Their argument is that business systems continually fail because the developers lose track of what they are doing at some point during the development. The problem is that many programming tools are so removed from what they create that the developers don’t always understand the impacts of each decision in the code.

 

The author recommends that programming tools move to a more visual and interactive format so the developer can visualize what the code does and immediately see the effects of any changes.

 

This is exactly what the Nintex Workflow and Forms Designers do! When you move a text box in a form, we show you how it impacts the rest of the form. When you add or copy an action in a workflow, we show you how the processes change.

 

You can help us stave off the software apocalypse by creating workflows that are clear, well labeled and minimize confusion.  

 

  • Try naming your workflows like the military names equipment: “Approval, HR, Vacation Request”. It’s not sexy and the names won’t grab you like a movie title does, but when catastrophe strikes, being able to find the right workflow quickly will reward you over and over again.
  • Keep the title of the action in its name: “Send an email: Workflow started” is much easier to understand in the middle of a calamity that just “Workflow started” or the ever popular camel case “EMWkflwStrt”.
  • Put a note in every email so you know where it came from. That way when your workflow starts sending the CEO blank emails, you can quickly figure out where they came from and avoid your own personal end of the world.

 

 

Every disaster movie and book has a beginning, middle and end. Maybe your workflows should too. Books use chapters. Movies use acts. Workflows use containers. The “Action set” and the “Branch by stage” actions are great tools for organizing your processes.

  1. The beginning act in a movie sets up the story and introduces the characters and environment. You can do the same thing in your workflow by writing a clear description, and then collecting the characters (data) forms and connections (environment) into the beginning section.
  2. The middle act is where things happen. Do this, do that, if this - then do that… You’ll find that the “Logic and flow” actions like “Branch by stage” and “Run parallel paths” are great tools for organizing your workflows into clearly defined sections. Stories may jump around from one debacle to the next and then back, but a good workflow reads like a cookbook.
  3. The final act is where everyone rides off into the sunset. The apocalypse is still a threat as long as the data’s not stored away, the final announcements aren’t sent, your workflow is still running on a server somewhere.

 

This may all sound over the top, but the 11 million people (including everyone working at the Nintex Bellevue office) lost 911 service for 6 hours due to poorly designed and documented code running on a server over a thousand miles away. Someone decided that an event counter should have an upper limit of several million. When the system reached that limit, it stopped.

 

The Solar Eclipse across the US this week forced governments across the US to plan for doubled populations, overwhelmed services and traffic jams over 500 miles long.

 

Some areas created new response plans that were focused on the eclipse impacts only. Once the eclipse was over, they were left with a memory and a set of plans with titles like “Eclipse: Day -1” that will never be used again.

 

Other areas pulled out their existing event and disaster response plans and used the eclipse to drive an update. These locations have plans with titles like “Emergency medical response when the roads are blocked” and are in better shape for the next once-in-a-lifetime disaster, once-per-winter blizzard, or even once-per-week rock concerts.

 

Like the eclipse response planers, you have a choice to design workflows for rare events, or for common processes. You could create a hardcoded workflow that only supports the review of the “Monthly statistics report” by Marge N. O’Vera, or you could create a workflow that supports the review of any document by an author selected reviewer. The second option is going to be a lot more useful!

 

When you design your next workflow, look beyond a single issues and identify the underlying processes that can be shared with other parts of your organization.

  1. Try for reusable workflows that solve multiple similar problems.
  2. Settle for repurposable workflows that you can copy and edit.
  3. Create one-use workflows only when you absolutely have to.

Remember that eclipses are high profile, but they don’t have long term impact.

 

 

https://www.theatlantic.com/business/archive/2017/08/eclipse-tourism/537684/

The rock band Van Halen had an exacting standard concert contract that specified how everything was to be set up before their crew arrived with nine semis full of gear. For example, the contract included how many outlets needed to be on the stage, how much power to each, the stage weight capacity, and even how big the access doors needed to be.  It also included this rider way at the end:

Munchies: M & M's (warning: Absolutely no brown ones)

 

The offending brown M&Ms were not a dietary issue nor a case of rock star hubris, but were meant as a flag for the advance crew. When they came in a found a bowl of M&Ms without brown ones, they would do the usual setup. However, if there were brown M&Ms, they knew that the contractor hadn’t followed their contract and that everything in the setup was therefore suspect. 

 

In our world we’d say that Van Halen had a task-based workflow with an unusual quality and completeness flag.

 

Think about your own task-based workflows where one person sets up the conditions, and another person performs a task. Your biggest fear here is that the task person either puts in the minimum information required to start the process, or just checks all the required boxes without really doing the work.

 

In management the rule of thumb is that you get what you measure. If completeness is important to your process, then you need to find a way to measure it that goes beyond just the count of boxes checked and actually measures the quality of the job.

 

For example, a measure of quality and completeness among baristas is the intentional misalignment of the seam in the paper coffee cup and the drinking hole in the lid. Excellent baristas know that when they align you have a dribble cup. Poor baristas don’t.

 

Is there an equivalent to brown M&Ms that you can use to check to see that the conditions are truly set up and ready for the task?

Recordings from the InspireX 2017 conference are now available to view online. Each of these hour long recordings focuses on how you can solve real business problems with Nintex Drawloop and Nintex Document Generation.

 

You can see the complete list of sessions here.

 

Recordings from the InspireX 2017 conference are now available to view online. Each of these hour long recordings focuses on how you can solve real business problems with Nintex.

 

You can see the complete list of sessions here

 

Recordings from the InspireX 2017 conference are now available to view online. Each of these hour long recordings focuses on how you can solve real business problems with Nintex.

 

You can see the complete list of sessions here.

 

There are a lot of answers to that question, and some are better than others. A workflow that automatically makes a decision based on logic may run for less than a second. Another workflow requiring a person to make a decision may run for about a week. A third workflow asking four people to make a decision may run for over a month.

 

But how long is “too long” for a workflow to run?

 

Take the Acme HR workflow that keeps track of reviews as an example. It starts when a person is hired, and runs for 30 days before notifying that a review is needed. At 60 days it announces another required review, and again at 90 days. This runs well in a pilot test, so an annual review reminder is added and it’s rolled out to all 700 employees.

 

Now you have a problem: 700 parallel workflow instances, each checking the HR database every .5 seconds to see if the date of hire for their subject is 30, 60, 90 or any multiple of 365 ¼ days ago, and they all need to run for years uninterrupted by software updates, bugs, and system changes.

One solution is to reconfigure the workflows to track by manager instead of employee and add a 1,000 x time delay to a cut down on the license use. Now you have 100 parallel workflows running every 5 minutes year after year, and you need to account for staff reorganizations in the workflow.

 

Maybe a better solution is to think sideways from the business process. Instead of a set of workflows that align with the review process running endlessly, try designing one workflow that runs once a week and checks the calendar against all employee start dates. That way all of the 30, 60, 90, and annual review notices would go out together once a week, the workflow is protected from staff reorganizations, software updates and server changes, and the license only requires one workflow.

 

While this is an extreme (and real) case, take a look at your own workflows to see if they would run better sideways to the business process or in smaller sections. The key is to separate the overall business process (in this case regular employee reviews) from the task that is being automated (identifying upcoming review dates). Rather than modeling the Business process in your workflow, it may be better to run a regularly scheduled workflow, or wait for something to happen and use that event to trigger your workflow?

 

The decision is yours.

There are few things more frustrating than a business-critical workflow that doesn’t let anyone know when it starts, when it ends, and what the final result is. If your workflows don’t give an immediate response to the originator*, they are likely to decide that the system failed and resend, or try another system to start the process again.

 

Imagine the poor person in the field who filled in a form but can’t tell if anything started. They click the submit button a couple of times before giving up on the form and emailing in a request. If they still don’t get a response, they finally call in their request with the security of knowing that they talked to someone directly. The end result is at least 5 parallel requests for the same action. The next time that person needs the same outcome, they’ll likely skip the form and email and go straight to the phone. As a result your workflow is abandoned because no one is going to trust their project and their next performance review to a tool that doesn’t appear to do anything.

 

The same problem is true for workflows that don’t let the originator know what the final result is. If your workflow includes reviews by other people, it may not finish for several hours or days. Without a sense of closure, the originator is likely to follow up on their initial request, interrupting everyone involved in the quest to find out if their request was handled.

 

In the Nintex Workflow Cloud templates we include an immediate “Hello” email back to the originator to verify that a workflow has actually started. We also send a final “Goodbye” email right before the workflow ends explaining what the results are. The upshot is that the originator has confidence that a workflow is underway, and the reassurance that their request was processed.

 

*Interestingly, if you give feedback too quickly, such as a popup in response to clicking the Submit button, your customers may believe that they have just received a response for the click rather than an actual result from the app.

Sometimes you have to decide if it’s better for your workflow to respond quickly to an event, knowing that the response will be incorrect some of the time, or more slowly and accurately. There is no simple answer to this question.

 

The Escalate Field Service Requests template in Nintex Workflow Cloud includes this type of issue.

The template sorts field service requests for the text “gas”. The idea is that any service request including a gas spill, leak or exposure should trigger a high priority task in Salesforce, and that a Slack message should be sent out on the company account explaining the situation.

 

The Workflow runs in this order:

  1. Filter for “gas” in the message with a Branch by condition action.
  2. Create a high-priority task with a Salesforce Create a record action.
  3. Publish the message from the field with a Slack Post a message

 

There are two problems with this design: a filter that will sometimes create an unnecessarily high priority Salesforce task records, and a direct link to slack that may create PR issues by posting un-reviewed or edited internal service requests.

 

The following messages will create both an unnecessarily High-priority task, and a PR issue:

  • “This is a <censored> electrical issue, not a problem with the gas!”
  • “The problem is that we forgot to install a water line gasket the last time we were out here.”
  • “I’m tired of working with Sam, he has gas.”

 

To solve these problems you could add an Express approval action to bring a person in to review the service request with but where should it go?

  • Placing the Express approval action before the Slack action (step 3) has the benefit of limiting PR issues with raw text from the field, but it will delay the announcement to the field for hours or days until someone has read and responded to the email.  
  • Placing the Express approval action before or after the Create a record: High-priority case action (step 2) depends on balance between the cost of an unnecessarily High-priority Salesforce task, and the cost of delaying the creation of an accurate task for hours or days until someone has read and responded to the email.

 

In the guidance on how to extend this template, we recommend that the Express approval action go after the Salesforce task action and before the Slack message action. That location assumes a low cost for an overly quick response, and a high cost for publishing a raw message.

 

Where would you put the Express approval action?

 

(click the link above when viewing the document to see the video)

 

You'll like the clean new look of the Nintex Workflow 2016, Workflow Designer!

 

We've updated the UI with clearer icons and reorganized menus. The Core menu contains actions in an adaptable and expandable structure that helps you find and configure the right action quickly. The Connectors menu provides the Nintex Live Actions as a set of configurable Connectors. Inside of each connector we've bundled up all of the options for that connector so you can be up and running right away.

Episode 3: Calculate Date

Use the Calculate Data action to add and subtract time from a date to create a new one. See the video on how to use this action!

 

nimupdatepic

(click the image above to watch the video in another window)

 

 

Related Content

View the Calculate Date help topic for more info.

Episode 2: Add User to AD Group

This workflow action will add a user to an Active Directory security group.

 

This topic applies to Nintex Workflow Enterprise Edition only.

 

nimpic(click the image to view the video)

 

Related Content

View the LDAP Picker help topic for more info.

View the Add User to AD Group help topic for more info.

Episode 1: Action Set

Sometimes it can be hard to keep track of all of the parts of your workflow.

 

Here's an action that bundles a collection of actions into a container that can be collapsed or expanded to make keeping track of your workflow actions more convenient.

 

Related Content

View the Action Set help topic for more info.

IMAG01365.jpg

Designing an onboarding workflow for a new hire, new customer, or partner requires coordinating processes across the company.

In this short set of videos Nintex Technical Evangelist Brad Orluk  explains how to design a best in class HR onboarding workflow that results in a successful new hire experience.

 

You can see the first video on the value of a successful HR Onboarding Workflow, and the costs of failure here:

For the rest of Brad Orluk's "How to Design an HR Onboarding Workflow" videos and guidance on how to create Nintex Workflows go to the Nintex Learning Center.

 

For more detailed guidance on creating Nintex Workflows see our Help Files and SDKs.

For Instructor-led training on creating Nintex Workflows contact your local Nintex Training Partner