---
category: [Administration & Integrations, Platform and Product Extensions, Platform and Product Extensions/Integration, Administration & Integrations/Custom Integrations & Apps, Platform and Product Extensions/Workday Extend]
keyword: [Extend, Presentation Components, widgets, tags, UI components]
nav: wcp_docs
parent_url: /wcp_docs/
title: taskOrch
layout: subsection
wd_wcptag: taskOrch
---

<a id="section_N10021_N1001E_N10001"></a>
Encapsulates a flow into a single, dynamic page that navigates through the edit steps of the flow. Use `taskOrch` only on view pages.

The `taskOrch` widget displays these UI elements:

-   A progress bar with step titles and navigation buttons.
-   The <b>Next</b> and <b>Back</b> buttons on each edit step in the flow. When the user clicks <b>Next</b>, the step submits the outbound endpoints on the edit page.
-   The <b>Submit</b> button on the last edit step in the flow. When the user clicks <b>Submit</b>, the step submits the outbound endpoints on the edit page. The flow then navigates to the page specified in the final flow step.


<b>Note:</b> The [editWizard](/wcp_docs/GUID-e22407f5-5782-4e59-a714-85499158a0bb-enHYPHENus.html) and `taskOrch` widgets both guide users through a series of tasks. However, there are some key differences between the two widgets:

-   `editWizard` is a more lightweight widget that groups related (but not dependent) tasks that can be submitted together. It doesn't require a flow definition in the AMD.
-   `taskOrch` requires a flow definition that enables conditional logic and branching.

    We recommend the `editWizard` instead of using the `taskOrch`. If you need conditional logic, you can configure a flow definition with edit pages without the `taskOrch`.



## <a id="section_jzd_pdl_chb"></a>Prerequisites

-   Use the `taskOrch` container widget only on view pages.

    Although the `taskOrch` widget displays on a view page, the flow associated with the `taskOrch` must use edit pages. Each edit page in the flow renders as an embedded edit page within the `taskOrch` widget.

-   When you define the flow that you want to use with the `taskOrch` tag, consider these requirements:

    -   Each step in the flow must use an edit page.
    -   The first flow step must set `startsFlow` to true.
    -   The last flow step must set `endsFlow` to true. Note that if the last step displays summary information, the summary page must also be an edit page.
    -   The last step that ends the flow must transition to an exit flow step, which sets `excludeFromFlow` to true. The exit step also specifies the page to navigate to when the user clicks <b>Submit</b> on the last step.

-   Define the flow in `flowDefinitions[]` in the App Metadata (AMD) with these required properties:

<table><thead><tr><th>Property</th><th>Usage</th></tr></thead><tbody><tr><td><code>name</code></td><td>Use the <code>name</code> on the <code>flowId</code> attribute of <code>taskOrch</code>.</td></tr><tr><td>flowStep: <code>taskId</code></td><td>Each edit flow step in the task orchestration must specify the taskId of an edit page. <p>Don't link a view page to a flow step, unless it's the final flow step that exits the flow.</p></td></tr><tr><td>flowStep: <code>transitions[]</code></td><td>Each flow step must contain at least 1 transition whose <code>value</code> specifies the next flow step.</td></tr><tr><td>flowStep: <code>startsFlow</code></td><td>The first flow step must set <code>startsFlow</code> to true.</td></tr><tr><td>flowStep: <code>endsFlow</code></td><td>The summary or confirmation flow step must set <code>endsFlow</code> to true. This flow step displays the <b>Submit</b> button.</td></tr><tr><td>flowStep: <code>excludeFromFlow</code></td><td>The final flow step that exits the flow must set <code>excludeFromFlow</code> to true. After the user clicks <b>Submit</b> on the preceding flow step, this flow step navigates to the page specified in <code>taskId</code>.</td></tr><tr><td>flowStep: <code>taskBindingName</code></td><td>Each flow step must specify the step title that displays on the <code>taskOrch</code> progress bar.</td></tr><tr><td>(Optional) flowStep: <code>skipStep</code></td><td>If true, the <code>taskOrch</code> widget doesn't display the flow step. The <code>skipStep</code> attribute can reference a parameter in the <code>stepParameters</code> attribute of <code>taskOrch</code>. Ensure that you apply correct logic with <code>skipStep</code>.</td></tr></tbody></table><br/>



Consider these guidelines and limitations:

-   For a basic flow that navigates from 1 edit page to the next, you'd typically set `"condition": true` in `transitions[]`. If you need to apply transition logic, keep it simple and ensure that you correctly configure the logic in the `condition` attribute.

    Similarly, if you need to use `skipStep` on a flow step, ensure that you correctly configure the logic. Example: If `skipStep` evaluates to true but the transition value leads to a flow step with an incorrect `condition`, the `taskOrch` widget might execute an endless loop.

-   Use the `taskOrch` widget as a simple container widget of edit pages with the standard <b>Next</b>, <b>Back</b>, and <b>Submit</b> buttons. The `taskOrch` widget isn't compatible with:

    -   Edit pages that enable `standardEditButtonsHidden` and `cancelOverride`.
    -   Other container widgets such as `superEdit`.

-   Avoid using a `stepParameters` binding with the `taskBindingName` attribute.


## <a id="section_dxv_nml_chb"></a>Example

This sample view page uses `taskOrch`:

```
{
 "id": "taskOrchestration",
 "presentation": {
   "body": {
     "type": "section",
     "children": [
         {
            "type": "taskOrch",
            "id": "sampleTaskOrch",
            "flowId": "taskOrchFlow"
         }
     ]
   }
 }
}
```

The sample `flowDefinition` used by <i>sampleTaskOrch</i>:

```
"flowDefinitions": [
   {
     "id": "taskOrchFlowId",
     "name": "taskOrchFlow",
     "flowSteps": [
       {
         "id": "editStep",
         "taskId": "taskOrchEdit",
         "startsFlow": true,
         "taskBindingName": "Edit Step 1",
         "transitions": [
           {
             "id": "finishEditTransition",
             "value": "summaryStep",
             "condition": "true",
             "order": "a"
           }
         ]
       },
       {
         "id": "summaryStep",
         "endsFlow": true,
         "taskId": "taskOrchSummary",
         "taskBindingName": "Summary Step",
         "transitions": [
           {
             "id": "exitFlowTransition",
             "value": "exitFlowStep",
             "condition": "true",
             "order": "b"
           }
         ]
       },
       {
         "id": "exitFlowStep",
         "excludeFromFlow": true,
         "taskId": "confirmationPage"
       }
     ]
   }
 ]
```

To see an example of sending parameters to the flow steps, see the `stepParameters` attribute.

## <a id="section-mobile-support"></a>Mobile Support

Android, iOS

## <a id="section_kt1_dkg_5cb"></a>Attributes

-   <b>flowId</b>

    Data type: binding-String

    The `name` of the flow definition whose flow steps display in the `taskOrch` widget.

-   <b>id</b>

    Data type: binding-String

    Unique identifier used to reference this widget from other tags.

    Notes:

    -   The `id` must start with a letter.
    -   The `id` must be unique per page.
    -   To enable other widgets to reference this widget `id`, place this widget before the other widgets on the PMD. The PMD validation returns an "Undefined variable" error if it doesn't find a previously defined `id` in the PMD.
    -   Workday recommends that you include the `id` in your tag definitions for debugging purposes.

-   <b>stepParameters</b>

    Data type: Map

    A map of name/value parameters that the `skipStep` and transition `condition` attributes can reference in the flow steps. If you set these attributes based on the derived values in `stepParameters`, the `taskOrch` tag uses these values to pre-determine which steps to render on the progress bar. The parameters in `stepParameters` are only computed once, on the very initial page load. Note that as the user navigates through the steps, each flow step separately evaluates the `skipStep` and `condition` attributes to execute the appropriate transition.

    This sample `taskOrch` tag uses `stepParameters`, which sends a boolean that indicates whether or not the worker email is empty. If the worker has an email address, the flow should skip the flow step that renders the <i>contactInfo</i> edit page.

    ```
    {
    "type": "taskOrch",
    "id": "taskOrchWithParams",
    "flowId": "taskOrchFlowName",
    "stepParameters": {
      "skipContactInfoStep": "<% !empty(getMyWorkerData.person.email) %>"
    }
    }
    ```

    To reference the step parameters in the flow steps, use the `queryParams` variable. The <i>editStep3</i> flow step in this sample flow definition uses `skipStep` to determine whether or not to skip the <i>Contact Info</i> step.

    ```
    "flowDefinitions": [
      {
        "id": "taskOrchFlowId",
        "name": "taskOrchFlowName",
        "flowSteps": [
          {
            "id": "editStep1",
            "startsFlow": true,
            "taskId": "questionnaire",
            "taskBindingName": "Questionnaire",
            "transitions": [
              {
                "id": "startEditTransition",
                "order": "a",
                "value": "editStep2",
                "condition": true
              }
            ]
          },
          {
            "id": "editStep2",
            "taskId": "miscInfo",
            "taskBindingName": "Miscellaneous Info",
            "transitions": [
              {
                "id": "continueEditTransition",
                "order": "b",
                "value": "editStep3",
                "condition": true
              }
            ]
          },
          {
            "id": "editStep3",
            "taskId": "contactInfo",
            "taskBindingName": "Contact Info",
            "skipStep": "<% queryParams.skipContactInfoStep %>",
            "transitions": [
              {
                "id": "finishEditTransition",
                "order": "c",
                "value": "summaryStep",
                "condition": true
              }
            ]
          },
          {
            "id": "summaryStep",
            "endsFlow": true,
            "taskId": "summary",
            "taskBindingName": "Summary",
            "transitions": [
              {
                "id": "exitFlowTransition",
                "order": "d",
                "value": "afterFlowStep",
                "condition": true
              }
            ]
          },
          {
            "id": "afterFlowStep",
            "excludeFromFlow": true,
            "taskId": "confirmationPage"
          }
        ]
      }
    ]
    ```

-   <b>visible</b>

    Data type: dynamicBinding-Boolean

    If true, the widget generated by this tag is visible. If false, this tag and its children tags aren't visible. This tag provides the ability to display or hide the widget dynamically based on user interactions on the page. The default is true. Unlike the `render` attribute, the generated widget persists on the page even when `visible` is false.

    <b>Notes:</b>

    -   When the widget or field you’re hiding changes on the page, you must include it inside a `fieldSet`.
    -   When the `visible` attribute is false for this widget on an edit page, the outbound endpoint doesn't include the `valueOutBinding` or `valuesOut` data of the widget in the payload. To include the `valueOutBinding` or `valuesOut` data in the payload, use the `onSend` event handler.