Wizard

The Wizard component allows you to create multi-step processes that move users through screens in a specified order. Users can execute complex business processes in a straightforward step-by-step fashion, without getting confused or overwhelmed.

Before you build a Wizard

The Wizard component is a powerful tool, but with great power comes great responsibility. Built thoughtfully, a Wizard can make the navigation of complex processes faster and less confusing; built without insight into the needs of users, a Wizard can simply become one more thing that slows them down.

Start by asking yourself the following questions:

  • What do users need to accomplish at the end of the Wizard?
  • Look at the way users currently work on this task:
    • Where is there confusion?
    • Where are the pitfalls?
    • Are there opportunities to make mistakes or overlook part of the process?
  • How many steps does it take to reach the desired end result?
    • In what order (and why that order?)
  • For each step, what's the best way for them to complete the tasks for that part of the process?

Now, sketch out a loose flow chart of the steps needed within the Wizard, and look it over for any of those areas of confusion mentioned above. Only then build.

Using the Wizard Component

Configuring a Wizard consists of several stages:

Add a Wizard component to a page, a modal, or a sliding panel, and set the Wizard's properties.

The Wizard component breaks up a process into steps. Each step is like a separate "mini-page" that you can configure with components and buttons. Add as many steps as needed ( Add new step), but configure them one step at a time by first adding components, then adding and configuring buttons.

Add one (or more) components to each step, set their properties, and add any necessary elements (such as fields)

Component best practices

  • Streamline each component as much as possible by removing any unnecessary features, such as search boxes or Save/Cancel buttons.
  • In general, use Edit as the Default mode when using Tables and Field Editors. This lets users quickly enter relevant information and tab through forms without needing to open the field with a double click.

Users need to be able to navigate back and forth between steps within the Wizard. When first dropped into the canvas, the Wizard includes a preconfigured Next button in the Wizard's Step stepper 1, and both a preconfigured Back and Next buttons in the Wizard's Step stepper 2. (Each subsequent step similarly includes Next and Back buttons.)

These preconfigured buttons use the Navigate to Step action type, and are therefore capable of performing only that action: navigating to the designated step. If a navigation button needs to perform additional actions, build a script in the Actions tab, which provides access to all the standard Action Framework options. For example, use a Next button to ...

  • Save changes in multiple Models.
  • Create a new row in another model, and set some default values

Note:  When in the Wizard, Nintex Apps offers an additional action type: Navigate to Step.

Other buttons

In addition to navigating through the wizard, users may need to to save, cancel, or perform other tasks. Build these buttons as you would in a Button Set or Page Title component, using the Action Framework. For example:

  • Create a Refresh button that returns users to the first step, cancels changes in all models and creates a new row in the appropriate models.
  • Include a Skip to Step 3 button in Step 1 if users don't always to fill out Step 2 information.
  • Use display logic so users see only the buttons they need to use.

Button best practices

  • Give buttons helpful labels (and perhaps icons), so it's clear to the user what they need to do.
  • Use the Step Id listed in the Step properties for the Step Id required on Wizard navigation buttons.

Note:  Want to see a Wizard in action? For a specific use case that uses a wizard to create new records, see Create a New Account Wizard.

Choosing a progress indication type and layout

The Wizard component comes with two progress indication types: numbered steps and navigation.

  • Numbered steps appear as a circle beside the label.
  • Navigation items appear as a clickable label, behaving like Navigation and Vertical Navigation for horizontal and vertical layouts, respectively.

Numbered steps help reinforce the sequence of a Wizard, so they may be a good choice for Wizards that must be done in a particular order. Navigation-based Wizards are more useful for forms that can be completed non-sequentially, or that have a vertical layout.

As for layout, it's possible to have your Wizard navigate horizontally:

Numbered steps

Navigation

Or to have it navigate vertically:

Numbered steps

Navigation

It's best to consider your user's screen size when selecting a layout, as wide screens may better support horizontal layouts. If your Wizard could be used on wide and narrow screens, consider enabling the Vertical layout/navigation on smaller screens property, which automatically switches the component's layout at runtime--better ensuring the Wizard that appears to your end users does not overflow the screen space.

Using the Wizard with the File Upload component

If using the File Upload component in a Wizard that creates new records, the File Upload component can not attach a file to a record until the record is saved. Best practice:

Make sure to save the File Upload's model in a step that precedes the one where users upload files using the component. Once the model saves, the record exists, and the file can be attached to it.

To see a use case, see File Upload in Wizards.

Best Practices

  • Wizard users are often creating and editing multiple objects, so an error when saving can lead to data disruption. When creating a Save Model Changes action on more than one model, check Roll back entire save on any error. This prevents the save (and any subsequent actions in the sequence) from happening until the user corrects the error.
  • Want to create conditional paths in the Wizard? (For example, if a user selects Option A from a picklist in Step 1, move to Step 2. But, if they select Option B from that same picklist in Step 1, jump from Step 1 to Step 4, skipping Steps 2 and 3.) Use branch actions with the navigation buttons to create separate, conditional paths based on if/else statements. Or conditionally render buttons on the Wizard so that they only appear when they are relevant to the process.

Component actions

Component actions are available using Run component action.

Navigate users to a specific step in the Wizard component.

Most useful if a list of actions requires a user be taken to a specific step, for example if a branch formula determines a user should proceed to an alternate area of the Wizard.

  • Step ID: The ID of the step to navigate the end user to. Compatible with merge syntax.

Navigate users to the previous step in the Wizard component.

This works for general purpose Previous button actions without requiring a specific step ID, as with the Navigate to Step action.

Navigate users to the next step in the Wizard component.

This works for general purpose Next button actions without requiring a specific step ID, as with the Navigate to Step action.

Used to alter the layout of the selected Wizard, which is initially set in the component's General properties.

When a Wizard's layout is changed, the user remains on their current step, but the position of the step's content, as well as any enabled step/progress indicators, will shift.

  • Layout: Determines the layout to switch the selected Wizard to.
    • Toggle: Switches the Wizard to the opposite layout of what it's currently set to, e.g. Horizontal > Vertical or vice versa.
    • Vertical: Switches the Wizard to the vertical layout. If the Wizard is already in a vertical layout, there is no effect.
    • Horizontal: Switches the Wizard to the horizontal layout. If the Wizard is already in a horizontal layout, there is no effect.

Properties

Component properties

  • Progress indication: Determines the style of the Wizard's progress indication area, which appears at the top of the component. This property value also updates the labels of other component properties to reflect selected progress type.

    • Numbered steps: Step indicators appear with their label and circular element displaying the step number.
    • Navigation: Step indicators appear as navigation items that display the step label, but no numbered indicator.
    • None: No step indicators appear.

  • Numbered step/Navigation layout Controls how the wizard's steps are displayed.

    • Horizontal
    • Vertical

  • Vertical layout/navigation on smaller screens: Available when Numbered step/Navigation layout is set to Horizontal. If checked, and the end user's screen is too narrow to display all the Wizard steps horizontally, the steps will stack vertically.

  • Disable step buttons: If checked, disables the clickable progress indicator buttons. These buttons can then be conditionally enabled using display logic.

  • Unique ID (optional): Nintex Apps automatically generates an alphanumeric ID for the component; if preferred, give it a practical name.

  • Allow HTML in step labels: Determines HTML rendering behavior for each step's Step label contents. When enabled, any HTML syntax will be rendered. When disabled, HTML syntax is displayed as plain text. For example:

    Enabled:

    This text is important

    Disabled:

    <strong>This text is important</strong>

  • Style variant: Style variants are created and set in the Design System Studio. Some components have pre-defined variants for a specific aspect of a component's style. Nintex Apps builders can style and customize elements to create their own themes within the DSS. These themes will dynamically populate as selectable values in the Style variant drop-down menu.

    Note: 

    • To refresh available style variant options, click refresh Refresh style variants.

    • This is useful for when changes to the design system (like style variants or variable options) have been made in another browser window or by another user.

  • Margins: Sets a component's margin (the space around it) relative to other components on the page.

    • To set margins for all sides, click All.
    • To set margins for each side individually, click Separate.

    Margin values can be set to any configured spacing variable for the page's design system. Margin cannot be set an arbitrary value; it must use a design system variable.

Note:  For information on individual condition properties, see the Display Logic docs.

Render conditions

These conditions govern when an element or component will display.

  • Render if...: The conditions that must be met to enable the element's display.

    • ALL conditions are met
    • ANY conditions are met
    • Custom logic is met
      • Condition logic: The custom logic for grouping and applying one or more conditions.

  • If hidden, model field changes should be: ( only available on Field rendering tabs ) If the field is hidden by conditional rendering, this property determines whether any changes made to this field (via an action flow or JavaScript) are saved in the model, or canceled.

    Note:  Updating fields without direct user input can lead to poor user experience, especially when the user may be unaware that field changes are occuring.

    • Retained in model ( the default)
    • Cancelled

Style variant conditions

These conditions govern which style variant is applied and displayed on a component or element.

Note: 

You can create one, or more, style variant conditions and set each individually.

  1. Click Add a new condition to add a new style variant condition.
  2. C lick the new style variant condition and configure.

When Nintex Apps executes the display logic, the style variant conditions are evaluated in order.

  • Use this Style Variant if...: The model conditions that must be met to enable the styling.

    • ALL conditions are met
    • ANY conditions are met
    • Custom logic is met
      • Condition logic: The custom logic for grouping and applying one or more conditions.
    • Style variant: The style variant to be rendered if conditions are met.

Nested elements

Step properties

  • Step ID: How the step is identified for button navigation.

  • Step label: A plain language label that tells the user what the button is for and why they might want to click it. Can contain merge syntax.

    If Allow HTML in step labels is enabled, then any HTML will be parsed and rendered—otherwise it will appear as plain text.

  • Change order: Moves the step forward or backward in the Wizard's sequence.

  • Align buttons: Determines the location of the step buttons within the Wizard. Options include:

    • Left: All step buttons are clustered on the left.
    • Right: All step buttons are clustered on the right.
    • Center: All step buttons are centered.
    • Separated: Step buttons are spaced out along the length of the Wizard.

    Note:  It's possible to set different alignments for the horizontal and vertical layouts.

A floating box that displays when the user hovers over a button, the tooltip provides guidance usage.

  • Text: The tooltip's content.

  • Position: This field determines the alignment of the tooltip relative to the button:

    • Top ( default ): Above the button.
    • Bottom: below the button.
    • Left: to the left of the button.
    • Right: to the right of the button.

    Note:  The Position settings are contingent upon available space. For example, if the Button Set is at the top of the page, and the tooltip position is set to Top, the tooltip cannot display above the button: there's not space. So it will display below the button.

  • Tooltip style:

    • Dark ( default ): The tooltip box is a black.
    • Light: The tooltip box is white, with a drop shadow.

  • Compact size: Reduces the amount of padding around the text in the tooltip box.

Used to configure actions that are triggered when the end user sees the step within the Wizard.

  • When first shown: Actions will only run the first time an end user selects this step on page load.
  • Whenever rendered: Actions will run every time an end user selects this step.

Click add Add action, then select:

Note:  For information on individual condition properties, see the Display Logic docs.

Render conditions

These conditions govern when an element or component will display.

  • Render if...: The conditions that must be met to enable the element's display.

    • ALL conditions are met
    • ANY conditions are met
    • Custom logic is met
      • Condition logic: The custom logic for grouping and applying one or more conditions.

  • If hidden, model field changes should be: ( only available on Field rendering tabs ) If the field is hidden by conditional rendering, this property determines whether any changes made to this field (via an action flow or JavaScript) are saved in the model, or canceled.

    Note:  Updating fields without direct user input can lead to poor user experience, especially when the user may be unaware that field changes are occuring.

    • Retained in model ( the default)
    • Cancelled

Enable conditions

These conditions govern when a displayed element may or may not be enabled for use.

  • Enable if...: The model conditions that must be met to enable the field's editing.
    • ALL conditions are met
    • ANY conditions are met
    • Custom logic is met
      • Condition logic: The custom logic for grouping and applying one or more conditions.
  • Message to show when disabled: A brief explanation for why the field is disabled.

Button properties

The properties available on Wizard buttons are the same as those for Button Set buttons.