---
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, UI components]
nav: wcp_docs
parent_url: /wcp_docs/
title: >-
Concept: Page Navigation
layout: subsection
---
Page navigation is an important aspect of user interaction with your custom app. Use page flows to define different ways the user can navigate across the pages in your app. Although a page flow typically consists of edit pages, a page flow can end with a view page or confirmation page. A page flow can render in full pages, popup windows (also called micro edit pages), or within a task orchestration widget. Consider the different page navigation patterns when you design your custom app.
## Extend App Landing Page
To assign or change the landing or home page of an Extend app:
1. In the App Metadata (AMD), go to `tasks[]`.
2. Edit the task whose `routingPattern` attribute is `"/"`.
3. Set the page `id` to the `id` of the PMD.
This AMD snippet shows the task that specifies the app landing page, newHome:
```
"tasks": [
{
"id": "root",
"routingPattern": "/",
"page": {
"id": "newHome"
}
},
. . .
]
```
## Page Flow Ending with a Confirmation Page
You can end a page flow with a confirmation page. A confirmation page is a view page that displays the Done button at the bottom.
Sample flow definition:
```
{
"id": "confirmationFlow",
"flowSteps": [
{
"id": "editTask",
"transitions": [
{
"value": "confirmationTask",
"order": "a",
"condition": "true"
}
],
"taskId": "edit"
},
{
"id": "confirmationTask",
"taskId": "confirmation"
}
]
},
```
The `presentation` tag of this sample confirmation page contains `"pageType" : "confirm"`:
```
{
"id" : "confirmation",
"endPoints" : [ ],
"presentation" : {
"pageType" : "confirm",
"headerSize" : "STANDARD",
"body" : {
"type" : "section",
"horizontal" : false,
"children" : [ {
"type" : "text",
"id" : "message",
"label" : "Confirmation message:",
"value" : "You successfully submitted your request."
} ]
}
}
}
```
## Page Flow Ending with a View Page
You can end a page flow with a view page. Add widgets that provide navigation options on your view page.
Sample flow definition:
```
{
"id": "editThenViewFlow",
"flowSteps": [
{
"id": "simpleEdit",
"startsFlow": true,
"transitions": [
{
"value": "simpleView",
"order": "a",
"condition": "true"
}
],
"taskId": "simpleEdit"
},
{
"id": "simpleView",
"taskId": "noPageType"
}
]
},
```
This sample page is the view page that ends the above flow definition. It also uses an `externalLink` to provide users an option to navigate to a related site.
```
{
"id" : "simpleView",
"endPoints" : [ ],
"presentation" : {
"pageType": "view",
"headerSize" : "STANDARD",
"body" : {
"type" : "section",
"horizontal" : false,
"children" : [ {
"type" : "text",
"id" : "hello",
"label" : "Confirmation message:",
"value" : "You successfully submitted your request."
},
{
"type" : "externalLink",
"label" : "You're done!",
"descriptor" : "Now check out Workday!",
"url" : "https://www.workday.com"
}]
}
}
}
```
## Page Flow in a Task Orchestration
You can embed a page flow within the `taskOrch` widget on a view page. The widget displays a progress bar and navigation buttons as it renders each edit page in the flow.
Sample flow:
```
{
"id": "taskOrchFlowId",
"name": "taskOrchFlow",
"flowSteps": [
{
"id": "editStep",
"taskId": "taskOrchEdit",
"startsFlow": true,
"taskBindingName": "Step 1",
"transitions": [
{
"id": "finishEditTransition",
"value": "summaryStep",
"order": "a",
"condition": "true"
}
]
},
{
"id": "summaryStep",
"endsFlow": true,
"taskId": "taskOrchSummary",
"taskBindingName": "Summary Step",
"transitions": [
{
"id": "exitFlowTransition",
"value": "exitFlowStep",
"order": "a",
"condition": "true"
}
]
},
{
"id": "exitFlowStep",
"excludeFromFlow": true,
"taskId": "home"
}
]
},
```
This sample view page contains the `taskOrch` tag:
```
{
"id": "taskOrchPage",
"presentation": {
"pageType": "view",
"body": {
"type": "section",
"horizontal": false,
"children": [
{
"type": "text",
"id": "hello",
"label": "Follow the steps...",
"enabled": "false"
},
{
"type": "section",
"children": [
{
"type": "taskOrch",
"flowId": "taskOrchFlow"
}
]
}
]
}
}
}
```
All pages used in the flow referenced by the `taskOrch` tag must be edit pages, even the summary page. This PMD is the sample summary page, which is also an edit page. Note that because the PMD contains `outboundEndPoints`, the `"pageType": "edit"` attribute is optional.
```
{
"id": "taskOrchSummary",
"outboundData": {
"outboundEndPoints": [
{
"name": "sampleOutbound",
"url": "http://localhost:3000"
}
]
},
"presentation": {
"pageType": "edit",
"body": {
"type": "section",
"horizontal": false,
"children": [
{
"type": "text",
"id": "hello",
"label": "Summary",
"value": "Sample summary information",
"enabled": "false"
}
]
}
}
}
```
## Page Flow and Path Parameters
You can use route (or "path") parameters to persist parameter values on a page after a user navigates back to it from a page flow. Example: A page starts a flow and needs to persist parameters after the user navigates backwards either by:
- Clicking Cancel during the page flow.
- Clicking the Back button on the browser.
- Completing the page flow.
To persist parameters after a user navigates back from a page flow:
1. Specify path parameters in the `routingPattern` of the task definition in the AMD.
This sample task definition in `tasks[]` navigates to a sample `viewWorker` page, and uses 2 path parameters. Note that the `action` parameter can contain either summary or details.
```
{
"id": "viewWorker",
"routingPattern": "viewWorker/{workerID}/{action}",
"page": {
"id": "viewWorker"
}
}
```
2. On the `taskReference` that navigates to the page, set the `parameterBindings` attribute. Ensure that you set the same path parameters you specified in `routingPattern`.
This sample `button` navigates to the `viewWorker` page. Note that the `parameterBindings` attribute specifies the `workerID` and `action` path parameters.
```
{
"type": "button",
"action": "LINK",
"label": "View Worker",
"taskReference": {
"taskId": "viewWorker",
"parameterBindings": {
"workerID": "<% currentWorker.id %>",
"action": "summary"
}
}
}
```
When a user clicks the button, this sample URL displays the path parameters:
```
.../myApp_abcdef/viewWorker/3aa5550b7fe348b98d7b5741afc65534/summary.htmld
```
3. On the page that starts a page flow, use the `routeParams` variable to reference the path parameters.
These sample `text` and `button` widgets reference the `workerID` and `action` path parameters:
```
{
"type": "text",
"id": "workerParam",
"label": "workerID path parameter",
"value": "<% routeParams.workerID%>",
"enabled": false
},
{
"action": "PRIMARY",
"id": "enterFlowButton",
"label": "Enter Flow",
"type": "button",
"taskReference": {
"type": "taskReference",
"taskId": "summaryPage",
"parameterBindings": {
"summaryOnly": "<% routeParams.action == 'summary' ? true : false %>"
}
}
}
```
If you have a custom task that loads the page, specify the path parameters in the Route Path of the custom task. The sample `routingPattern` above corresponds to this sample Route Path: `/viewWorker/{customTaskObjectId}/summary`. In this case, `summary` is the value of the `{action}` path parameter in `routingPattern`.
Note the difference between `routeParams` and `queryParams`:
- Use the `routeParams` variable for accessing path parameters in app URL. The `routeParams` variable is a map that specifically contains the route parameters in the app URL. If you use a custom task to load the page, the `routeParams` variable contains the path parameters in the Route Path of the custom task.
- Use the `queryParams` variable for accessing query parameters when navigating from a page to another through the `taskReference` tag. The parameter bindings in a `taskReference` adds parameters to `queryParams`. If you use a custom task to load the page, the `queryParams` variable contains the query parameters in the Route Path of the custom task.
- The query parameters sent from a custom task to a landing page don't persist after a user navigates back to it from a page flow. To persist the parameters on the landing page, use path parameters and the `routeParams` variable instead.
## Multiple Custom Tasks Using the Same Page Flow
When you configure a custom task in Workday, you can configure the Route Path to load a page that starts a page flow. You can also include parameters that the custom task sends to the custom app.
- Path parameters: The landing page can access the path parameters through the `routeParams` variable. The path parameters in `routeParams` persist on the landing page after the page flow ends or when the user navigates back to the landing page. Example path parameters: `/myCustomTask/pathParam1/pathParam2`
- Query parameters: The landing page can access the query parameters through the `queryParams` variable. The query parameters in `queryParams` don't persist on the landing page after the page flow ends or when the user navigates back to the landing page. Example query parameters: `/myCustomTask?queryParam1=value1&queryParam2=value2`
In some cases, you might need to create multiple custom tasks that launch the same page flow. The same landing page can display different widgets based on the custom task parameters. The page flow can also change transitions based on the custom task parameters. In this situation, assign a unique Route Path for each custom task. Use the same positional path parameters for each Route Path. Ensure that at least 1 parameter at the same position in the path is unique.
In the AMD, you can use the same task definition for both custom tasks. Ensure that the root of the `routingPattern` matches the root of each Route Path of the custom tasks. Specify the path parameters, enclosed in curly braces, at the same path location as the parameters in the Route Path.
To illustrate multiple tasks that use the same page with different path parameters, we use 2 sample custom tasks: View Summary and View Details. Both of these custom tasks launch the `viewWorker` page, which navigates to the `summaryPage` to start a page flow.
The Route Path and page flow transition for each sample custom task:
Custom Task
Route Path
Page Flow Transition
View Summary
/viewWorker/{customTaskObjectId}/summary
summaryPage > confirmationPage
View Details
/viewWorker/{customTaskObjectId}/details
summaryPage > detailsPage > confirmationPage
The task definitions in the AMD:
```
"tasks": [
{
"id": "viewWorker",
"routingPattern": "viewWorker/{workerID}/{action}",
"page": {
"id": "viewWorker"
}
},
{
"id": "summaryPage",
"routingPattern": "summaryPage",
"page": {
"id": "summaryPage"
}
},
{
"id": "detailsPage",
"routingPattern": "detailsPage",
"page": {
"id": "detailsPage"
}
},
{
"id": "confirmationPage",
"routingPattern": "confirmationPage",
"page": {
"id": "confirmationPage"
}
}
]
```
This `button` on the `viewWorker` landing page navigates to the `summaryPage`. The `summaryOnly` parameter binding detects the custom task parameter `summary`, and sends the `queryParams.summaryOnly` variable to the `summaryPage`.
```
{
"action": "PRIMARY",
"label": "Enter Flow",
"id": "enterFlowButton",
"type": "button",
"taskReference": {
"type": "taskReference",
"taskId": "summaryPage",
"parameterBindings": {
"summaryOnly": "<% routeParams.action == 'summary' ? true : false %>"
}
}
}
```
On the `summaryPage`, the `outboundVariable` sends `queryParams.summaryOnly` to the page flow. Note that setting `variableScope` to `flow` sends the `flowVariables.summaryOnly` variable to the page flow.
```
"outboundData": {
"outboundEndPoints": [
{
"name": "transitionOutboundVars",
"type": "outboundVariable",
"variableScope": "flow",
"values": [
{
"outboundPath": "summaryOnly",
"value": "<% queryParams.summaryOnly %>"
}
]
}
]
}
```
In the `flowDefinitions[]` in the AMD, the transitions in the `flowStep` for the `summaryPage` evaluate `flowVariables.summaryOnly`. The `summaryPage` transitions to either the `confirmationPage` or the `detailsPage`.
```
{
"id": "summaryPage",
"transitions": [
{
"value": "confirmationPage",
"condition": "<% flowVariables.summaryOnly %>",
"order": "a"
},
{
"value": "detailsPage",
"condition": "<% ! flowVariables.summaryOnly %>",
"order": "b"
}
],
"taskId": "summaryPage",
"name": "summaryPage"
}
```
This snippet displays the complete `flowDefinitions[]`:
```
"flowDefinitions": [
{
"id": "viewWorkerFlow",
"name": "viewWorkerFlow",
"flowSteps": [
{
"id": "summaryPage",
"transitions": [
{
"value": "confirmationPage",
"condition": "<% flowVariables.summaryOnly %>",
"order": "a"
},
{
"value": "detailsPage",
"condition": "<% ! flowVariables.summaryOnly %>",
"order": "b"
}
],
"taskId": "summaryPage",
"name": "summaryPage"
},
{
"id": "detailsPage",
"transitions": [
{
"value": "confirmationPage",
"condition": "true",
"order": "a"
}
],
"taskId": "detailsPage",
"name": "detailsPage"
},
{
"id": "confirmationPage",
"taskId": "confirmationPage",
"name": "confirmationPage"
}
]
}
]
```
## Self-Referencing Page
An edit page can navigate to itself after the user clicks OK. You can't use this pattern with a profile group. The default buttons on the edit page don't display on a profile group tab.
Sample flow:
```
{
"id": "selfRef",
"name": "selfRef",
"flowSteps": [
{
"id": "selfRef",
"transitions": [
{
"id": "self",
"value": "self",
"order": "a",
"condition": "true"
}
],
"taskId": "selfReferencePage"
},
{
"id": "self",
"taskId": "selfReferencePage"
}
]
}
```
## Self-Referencing Page with a Popup Window
An edit page can display the `congratulationsPopup` window and then navigate to itself after the user clicks OK. You can't use this pattern with a profile group. The default buttons on the edit page don't display on a profile group tab.
Sample flow:
```
{
"id": "selfRefPopup",
"name": "selfRefPopup",
"flowSteps": [
{
"id": "selfRefPopup",
"transitions": [
{
"id": "selfPop",
"value": "selfPop",
"order": "a",
"condition": "true"
}
],
"taskId": "selfReferencePagePopup"
},
{
"id": "selfPop",
"taskId": "selfReferencePagePopup"
}
]
}
```
This sample edit page uses the `congratulationsPopup` tag that renders when `flowVariables.submitted` is true.
```
{
"id" : "selfReferencePagePopup",
"outboundData" : {
"outboundEndPoints" : [ {
"values" : [ {
"outboundPath" : "submitted",
"value" : true
} ],
"name" : "transitionOutboundVars",
"type" : "outboundVariable",
"variableScope" : "flow"
} ]
},
"presentation" : {
"headerSize" : "STANDARD",
"dirtyPage" : "false",
"body" : {
"type" : "section",
"horizontal" : false,
"sorted" : false,
"children" : [ {
"type" : "congratulationsPopup",
"render" : "<% flowVariables.submitted ?? true %>",
"textCongrats" : "Thank You!",
"textSubmitted" : "Your comment has been submitted. Feel free to enter another comment."
},
{
"type": "textArea",
"label": "Enter a comment."
},
{
"type" : "button",
"id" : "home",
"label" : "Go Home",
"action" : "LINK",
"taskReference" : {
"taskId" : "home"
}
} ]
}
}
}
```
## Micro Edit Page with a Micro Conclusion
You can display the edit pages of a flow as popup windows (micro edit pages). After the last micro edit page, you can add a micro conclusion page that displays a green confirmation message at the top.
Sample flow:
```
{
"id": "microEditConclusionFlow",
"name": "microEditConclusionFlow",
"flowSteps": [
{
"id": "edit2",
"transitions": [
{
"id": "view",
"value": "view",
"order": "a",
"condition": "true"
}
],
"taskId": "microEdit2"
},
{
"id": "view",
"taskId": "microConclusion"
}
]
},
```
This sample PMD is the micro conclusion page. A PMD with a `presentation` tag that contains `"microConclusion" : "true"` doesn't display at the end of the micro edit flow. Instead, the popup window closes and displays a green confirmation message at the top:
```
{
"id" : "microConclusionPage",
"endPoints" : [ ],
"presentation" : {
"microConclusion" : "true",
"body" : {
"type" : "section",
"horizontal" : "true",
"children" : [ {
"type" : "text",
"label" : "Placeholder tag. This micro conclusion page does not display. "
} ]
}
}
}
```
Note: You can only start a micro edit flow from a view page. An edit page that starts a micro edit flow can cause undefined behavior. Example: An edit page can't have a button that links to a micro edit page.
## First Micro Edit Page Then Full Edit Page
You can display the first edit page as a popup window, then the next edit page as a full page.
Sample flow:
```
{
"id": "microFirstPageFlow",
"name": "microFirstPageFlow",
"flowSteps": [
{
"id": "microFirst",
"startsFlow": true,
"transitions": [
{
"value": "simpleEdit",
"order": "a",
"condition": "true"
}
],
"taskId": "microEditSingle"
},
{
"id": "simpleEdit",
"startsFlow": false,
"transitions": [
{
"value": "simpleView",
"order": "a",
"condition": "true"
}
],
"taskId": "simpleEdit"
},
{
"id": "simpleView",
"taskId": "simpleView"
}
]
},
```
This sample PMD is the first micro edit page. Its `presentation` tag sets `"micro" : "true"` and `"microFirstPageOnly" : "true"`.
```
{
"id" : "microEditSingle",
"outboundData" : {
"outboundEndPoints" : [ {
"type" : "outboundVariable",
"name" : "aVariable",
"values" : [ ]
} ]
},
"presentation" : {
"micro" : "true",
"microFirstPageOnly" : "true",
"body" : {
"type" : "section",
"title" : "Details",
"horizontal" : true,
"children" : [ {
"label" : "Enter the name.",
"id" : "name",
"type" : "text",
"valueOutBinding" : "aVariable.name"
} ]
}
}
}
```
If you remove `"microFirstPageOnly" : "true"` from the sample micro edit page, the next edit page continues to display as a popup window.
Note: You can only start a micro edit flow from a view page. An edit page that starts a micro edit flow can cause undefined behavior. Example: An edit page can't have a button that links to a micro edit page.
## Workday Navigation to a Page Flow
You can use these Workday navigation options to enable your users to access a page flow from Workday:
- Custom tasks.
To link a page flow to a custom task, set its Route Path to the `routingPattern` of the first flow step. Example: Using the [Page Flow Ending with a Confirmation Page](/wcp_docs/qoc1553369215127.html#section-page-flow-ending-with-a-confirmation-page) pattern:
1. In the AMD, get the `taskId` of the first flow step. Example: `"taskId": "edit"`
2. In the AMD, get the `routingPattern` for the task id in the `tasks[]` subschema. Example: `"routingPattern": "/edit",`
3. When you create the custom task on the tenant, set Route Path to the `routingPattern` value. Example: `/edit`
- Related actions.
You can add the custom task to the related actions menu of a business object instance. To add your custom task to the related actions menu, access the Edit Custom Task task. Under the business object, select either Secured selection or Unsecured selection. Optionally, you can select a Related Actions Category Override.
- Profile groups.
You can link a custom task to profile groups. Access the Configure Profile Group task to add the custom task to a tab in the profile group.
- Custom dashboards.
You can link a custom task to a custom worklet, which you can add to a custom dashboard.
### Related Information
[Concept: Page Types](/wcp_docs/zrd1553321160092.html)
[Concept: Page Flows](/wcp_docs/zji1528861641063.html)
[Tutorial: Navigate Pages with Buttons and Button Groups](https://wd5.myworkday.com/workday/learning/course/62d106356d1b10051260edf509b90000?type=9882927d138b100019b928e75843018d)
[Tutorial: Send Data to Pages with Buttons](https://wd5.myworkday.com/workday/learning/course/61eba84c34fc100824ab1d1389a80000?type=9882927d138b100019b928e75843018d)