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.

Navigation buttons

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.

• 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. Also, 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 dropdown 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.

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

  • To set margins for all sides, click border-all All.
  • To set margins for each side individually, click border-separate 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 Action Framework or JavaScript) are saved in the model, or canceled.

  Note:  Depending on the needs of your org, it could be bad user experience to update fields without direct user input especially when that user may be unaware of they are doing so.

  • Retained in model ( the default)
  • Cancelled

Style variant conditions

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

• 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 condition(s) are met.

• 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 a set of 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:

• Action Type: Use the Action Framework to launch actions.

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 Action Framework or JavaScript) are saved in the model, or canceled.

  Note:  Depending on the needs of your org, it could be bad user experience to update fields without direct user input especially when that user may be unaware of they are doing so.

  • 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.