---
nav: wcp_docs
parent_url: /wcp_docs/
title: Getting Started with Extend Presentation Components
layout: subsection
---
In this course, you'll explore the basic presentation components that you'll use to create pages in a Workday Extend app.
After completing this course, you should be able to:
- Define the high-level purpose of presentation components.
- Differentiate among AMD, PMD, and SMD file types.
- Describe the characteristics of the various page types.
Presentation components are the building blocks of your Workday Extend app’s user interface. They define what displays on the screen and how users interact with your custom logic and data
## Before You Begin: Create an Account on the Workday Build Platform
To do this activity, you must have an account on the Workday Build platform and a development tenant. If you’ve already created an account and a tenant, you can go to the first task of this activity.
If you haven’t already created an account, you can do so now. It’s free!
1. Go to the [Workday Build Platform](https://developer.workday.com) and create an account with your personal email address.
2. Once you have created an account, sign in to the [Workday Build Platform](https://developer.workday.com).
3. In the upper-left corner, select the hamburger menu, and under Console, select Tenants.
4. On the Tenants page, select Create Tenant. It will take 1 to 2 minutes for the development tenant to be created.
5. Check your personal email for a link to change your tenant password.
Note: Remember the password. You’ll need to sign in to the tenant while you do this activity.
6. Sign in to the tenant with the username lmcneil and the password that you just created.
Note: When you sign in to the development tenant with the username lmcneil, you’re signing in as the persona Logan McNeil. Logan is one of several user accounts that you can use to test the agents and app that you create and deploy to your development tenant.
## JSON Data Structure
Workday Extend uses the JSON format to represent an app’s metadata in a structured, machine-readable way. Think of it as a hierarchical set of key–value pairs (objects) and ordered lists (arrays) that together describe everything about the app: its identity, data model, security, UI, and integrations.
When you build a Workday Extend app, you can use Visual mode, which allows you to quickly create and rearrange widgets in your app by selecting from a preset list of options. In Visual mode, you can drag and drop the elements to reflect how they'll render on a page. Additionally, you can also build using Code mode, which displays the JSON behind your app. You can switch between these two modes using the toggle highlighted in the images below.
Review each takeaway for this section.
- Presentation components make up the user interface of your Workday Extend app, defining what displays and how users interact with it.
- Workday Extend uses JSON to represent an app's metadata.
## Page Metadata
Page metadata (PMD) describes the structure and behavior of an individual page within your app. It defines the layout, components (fields, buttons, tables, etc.), data bindings, and actions for that page. Its purpose is to specify how the page displays and what it does so that Workday can render the UI, connect it to data and logic, and handle user interactions consistently with the rest of the Extend app.
## Presentation Subschema
A Workday Extend page is structured by a presentation subschema that defines the page display and user interaction. The presentation subschema contains PMD tags, which specify how content is displayed on a page. By default, new Workday Extend pages include these tags:
- Title: A headline at the top of the page.
- Body: The root section that contains other PMD tags.
- Section: A tag inside the body that defines how content is structured in horizontal or vertical columns.
- Text: A tag that displays a message in plain text.
- Footer: A section at the bottom of the page. The footer contains a rich text tag that displays text formatted with HTML tags.
## Section Layout
In sections, you can lay out content vertically or horizontally. To lay out content horizontally in a section:
1. Determine if you want your content to appear in rows or columns.
- For rows, set the `horizontal`attribute to `false`.
- For columns, set the `horizontal`attribute to `true`and define the `columnWidthRatios`for each column in which you want to display content. For example, .33 each for 3 columns.
2. Under the section, you can use the `children`attribute to add more tags to this section, as shown in the images below.
Resource: For more information on section layout, check out the Developer Documentation: [section](/wcp_docs/wjy1524108289078.html#) topic.
The app metadata (AMD) is where you configure page routes, flows, data providers, and other custom properties that govern how users and data flow through the app:
- Page Routes: Tasks contain page declarations and their corresponding URL routing pattern. The routing pattern can have parameters, which enable you to extract data from the URLs. You can then build your page content based on the parameter values. When you create a page, App Builder adds a task in the tasks `[ ]` array. The default `routingPattern`is the page ID. If you need to customize the routing pattern of the page in the app URL, you can override the default `routingPattern`.
- Flows: Flow definitions are a way of stringing pages together to form sequences of steps to complete a user task. Flows support conditional logic so that the sequence of pages can vary depending on runtime conditions.
- Data Providers: Data providers are the REST web services that the app can invoke to retrieve or update data. The `dataProviders`array in the AMD contains the base URL paths of the REST endpoints. After you declare a data provider in `dataProviders[ ]`, you can reference its key as the base URL of your page endpoints.
Resource: For details about the AMD properties and subschemas, check out the Developer Documentation: [Reference: Extend App Metadata](/wcp_docs/btj1547749859781.html#G_PEER_1).
## Site Metadata
Site metadata (SMD) describes how your app is exposed as a “site” or entry point in the Workday UI. It controls where and how users launch the app (examples: via a Workday Home page, menu, or task), what shell or navigation it uses, and which initial page or flow is loaded. Its purpose is to define how users discover, access, and navigate into your Workday Extend application from within Workday.
## PMD Tags
Basic UI tags are the fundamental widgets used to build the user experience. Their purpose is to bind to your data sources and endpoints to give you a standardized set of controls that are consistent with the Workday user experience (UX).
You can use PMD tags that display text to:
- Show static content that you create.
- Retrieve dynamic values from Workday or external API endpoints defined on the page.
These tags support localization, so you can surface user-friendly, translatable labels rather than hard-coded strings. They can also format values (like dates, numbers, and codes) into readable text.
## Static Text
The text tag is a simple way to display text. In Visual mode, you can expand the tag to show all available attributes.
- The Label attribute will display bold text, like a headline.
- In the Value attribute, you can enter a short paragraph of static text. To display dynamic content, you’d enter a scripted value that references an API endpoint or data passed from another page in your app.
Refer to the image of an example below.
Other PMD tags work in a similar way. For example, a rich text tag enables you to use the Label and Value attributes to display text formatted with HTML tags.
## Input Forms
On an edit page, a text tag will display as a field in which a user can enter data. In the image below:
- The Label attribute describes the data to be entered.
- The Value attribute will display as an empty field or as text that the user can edit.
By default, text, rich text, and text area tags will display as fields on an edit page.
If you want to use a tag to display static text, set the Enabled attribute to false. Alternatively, you can use the read only text tag to display unchangeable text on an edit page.
## Dynamic Data
In many cases, you’ll want to display real-time data, such as current time-off balances, open requisitions, or pending approvals. To do this, you can use PMD tags to call a Workday API with the signed-in user’s context and render the results on the page. Then, the app can adapt its content dynamically so each user sees up-to-date data relevant to their role and actions without manual refresh or navigation to separate reports.
For example, you can configure an instance list to display the user’s direct reports by calling an inbound API endpoint that’s declared in the page’s Page Load tab.
## Configuration
In the instance list’s Values attribute, create a short PMD script—directReport.data—that references the name of the inbound directReports endpoint: (/workers/{ID}/directReports).
## Page Load
When the page loads, the inbound endpoint returns a collection of direct reports to the page.
You can bind this API response to different UI elements (e.g., to lists, cards, or tables), so the app can dynamically display up-to-date information about a worker’s direct reports.
## Data in a Grid
You can also use a Grid tag to display a lot of data on a page. A Grid tag displays data by binding its rows and columns to a data model that is populated from a Workday API endpoint via a PMD script. When the page loads or the bound model refreshes, the grid reads the API response collection and renders each item as a row, mapping specific fields in the payload to configured grid columns and formats.
Resource: To view all the available PMD tags, check out the Developer Documentation: [Reference: PMD Tags](/wcp_docs/dyg1528862158582.html#G_PEER_1).
- Page metadata (PMD) describes the structure and behavior of a page.
- App metadata (AMD) contains properties that govern how both users and data flow through an app.
- Site metadata (SMD) controls where and how users launch an app.
## Page Types
There are three types of pages in a Workday Extend app: view, edit, and confirmation pages.
## View Pages
A view page consists of widgets that display read-only text. You can set the page type to view by setting the presentation tag in the PMD as:
```
"pageType": "view"
```
A view page may include inbound data, but it won't contain outbound data.
Note: Since view pages may include inbound data, let's discuss inbound data at a high level. Inbound endpoints define how a page in a Workday Extend app retrieves data from Workday and external API data sources when a page loads.
## Edit Pages
An edit page consists of editable widgets that a user can interact with by either selecting or entering data. An edit page, however, can also have read-only widgets.
You can set the page type to edit by setting the presentation tag in the PMD as:
```
"pageType": "edit"
```
An edit page includes outbound data, and it may also include inbound data.
Note: Since edit pages include outbound data, let's discuss outbound data at a high-level. Outbound endpoints define how your Workday Extend app sends data out to external services or Workday APIs.
## Confirmation Pages
A confirmation page consists of widgets that display read-only text. You can set the page type to confirmation by setting the presentation tag in the PMD as:
```
"pageType": "confirm"
```
A confirmation page displays a Done button to navigate a user back to the previous page. You can use a confirmation page at the end of a flow.
- View pages display read-only text.
- A user can interact with an edit page by selecting or entering data.
- Confirmation pages are read-only and can appear at the end of a flow.
## Inbound and Outbound Data
Inbound and outbound API endpoints enable pages in your Extend app to retrieve and send data to Workday or external data sources, including model component business objects in your app.
Inbound endpoints define how a page in an Extend app retrieves data from Workday and external API data sources when a page loads. On a page, you define REST, Graph, or WQL inbound endpoints on the Page Load tab. When the page loads, the data is automatically retrieved unless you set the deferred attribute to true, in which case you can trigger the endpoint from a user action using the On Change attribute.
Outbound endpoints define how your Workday Extend app sends data out to external services or Workday APIs. Outbound endpoints are configured on the Page Submit tab of a page.
The basic endpoint attributes you must set are:
- Name - You create a unique and intuitive name for the API endpoint, such as “getWorker” or “usersDirectReports”. You’ll use the endpoint’s name to reference its data in other PMD tags on the page.
- Base URL Type - This is typically an alias that represents the root part of the URL that identifies the API family you’re calling, before any specific resource paths or query parameters. A best practice is to assign a simple key to the base URL in the AMD’s dataProvider [ ] array. You can then use the key to reference the base URL from other components in the app.
- URL- This is a path to a specific resource and query parameters.
- Auth Type - The endpoint authentication scheme. Specify the authType id, which is defined in the authTypes [ ] array in the Site Metadata (SMD). Workday REST APIs use SSO, which is the default authentication type.
## Summary
Congratulations! Now that you have completed this course, you should be able to:
- Define the high-level purpose of presentation components.
- Differentiate among AMD, PMD, and SMD file types.
- Describe the characteristics of the various page types.