Native comes from Workday's widgets, not from styling

A PMD file describes widgets, and Presentation Components render each one in Workday's own style. So a page looks native when it is built from the same pieces Workday uses, in the same way. Pages look foreign when they use the wrong widget for the job: plain text where Workday shows a linked record, a richText block used as layout, custom buttons where the standard OK button belongs, or one huge page where Workday would use several short ones.

Workday's own guidance in its PMD best practices names the design principles: keep the UI brief, familiar and relevant, and build efficient page-sized experiences. Split a long or widget-heavy page into focused pages.

Start with a title and a structured layout

Give every page a title tag. It shows in the page banner and the browser tab, and on a popup (micro) page it shows at the top of the window. If the app's SMD defines localized titles, they override it, so translated titles come from there.

Then pick a structured layout as the top-level tag in body. For what every other widget is for, see which Extend widget to use for what. Each of them must be the top-level tag:

  • basicFormLayout for a simple form. It stacks bordered layoutSection containers.
  • columnLayout for a record with several groups of fields side by side. It's responsive, takes 1 to 3 columns, and centres a single column at two thirds of the page width.
  • areaLayout for a main area with a secondary panel of context.
  • multiStepLayout for a guided sequence of up to 10 numbered steps.

Inside a layout section, group fields with fieldSet when the group needs a heading (title), or should collapse (collapsible, optionally initializeCollapsed). Use section for groups without a heading. Keep the nesting shallow. Workday advises against nested fieldSets, and against deep nesting of section and fieldSet inside a layoutSection.

Show records the way Workday shows them

The strongest native signal is how records appear. On Workday's own pages, a worker, organization or Cost Center is a link with a related actions menu, not plain text. An Extend view page gets the same behaviour from an instanceList whose instances carry a wid:

{
  "type": "instanceList",
  "label": "Requested For",
  "instanceList": [
    {
      "id": "<% request.requestedFor.id %>",
      "descriptor": "<% request.requestedFor.descriptor %>",
      "wid": "<% request.requestedFor.id %>"
    }
  ]
}

Setting wid turns on both the view link and the related actions menu. Set view to false to keep the menu but drop the link, or relatedTask to false to drop the menu. Do the same inside a grid column's cellTemplate, so each row's worker or record is a link, as in a Workday report.

On edit pages, use the instanceList prompt for any field that holds a record, rather than a dropdown of descriptors. Users get the search-as-you-type prompt they use everywhere else in Workday. For long sources, use searchEndPoint or onSearch so the prompt doesn't preload thousands of values.

Let the widgets do the formatting

Hand-built formatting makes an Extend page look slightly off next to a Workday page. Let the widget do it:

  • Money: the currency widget formats by currencyCode and the user's locale, including alignment, decimal places and symbol. Don't build "$1,250.00" in a string.
  • Dates: use the date widget, or readOnlyText with formatAsDate true, so the user's date format applies. Format a date yourself only when the requirement demands a specific pattern.
  • Yes or no: a checkBox on a view page shows its trueLabel or falseLabel rather than a box.
  • Read-only values on an edit page: set enabled to false, or use readOnlyText. Either keeps the field's Workday formatting without letting the user change it.

Use the standard buttons and page types

An edit page already has OK and Cancel at the bottom, like every Workday task. Change the OK label (for example to Submit) or add more submitting buttons with editButtonBar, not with extra button widgets. Hide Cancel only by setting standardEditButtonsHidden on presentation. For the end of a flow, a page with pageType confirm shows read-only widgets and a Done button that returns to the previous page.

For navigation buttons, follow Workday's emphasis rules on button: PRIMARY for the single action that moves the user forward, AUXILIARY for secondary actions and for leaving a process, and LINK for page navigation. A page with three primary buttons doesn't look like Workday.

When the next step belongs in a Workday-delivered task or report, send the user there with workdayTaskReference and the task's Integration ID, rather than rebuilding it. Find the ID from the task's related actions, under Integration IDs > View IDs. It's the same across environments. It can't pass parameters to the delivered task.

Make tables and help feel familiar

For lists of records, use a view-page grid with sorting and filtering on the columns users scan. Set excelExportEnabled (view pages only) where people will want the data in Excel, as they can from Workday reports. When a page has several grids, set doNotPutInTab to false on them so they sit in tabs at the bottom of the page.

For field help, use guide on simple widgets on edit pages. It adds the ? popup Workday uses for guided help. Guides are hidden until the user clicks ? in the page banner, unless the tenant turns on Always Show Guided Tours in Edit Tenant Setup - System.

Make sure every required field has a label. Workday's best practices call this out as standard for usability and accessibility.

Fit into Workday's own business process screens

If the app has an Extend business process, give it a details page route. Workday renders that page wherever the event's details show in the tenant, so your request appears inside the standard event view instead of on a separate screen. Use a view page for approval steps. The framework then adds the Approve, Deny and Send Back buttons itself, exactly as on a delivered business process.

Check it the way users will see it

Review each page signed in as a user in the role that will use it, not as an administrator, on the narrowest screen it must support. The layouts above are responsive, but a page with many horizontal sections can still crowd on a small screen. If the page will be used in the Workday mobile app (see Extend apps on mobile), check that each tag is mobile-enabled in Workday's PMD Tags reference before you rely on it. The LINK button style, for example, isn't supported in the mobile app.

kiweely can run this check in the real tenant: it opens the deployed page in the browser as a given role, so you see the page as that role sees it, next to the Workday-delivered task it sits beside.

Sources checked