Model tasks vs custom tasks in Workday Extend: which to use and why

Model tasks travel with the app; custom tasks stay in one tenant

A model task is a Task component you author in App Builder as part of the app. Because it isn't tenanted, it deploys with the app to every tenant you install it on. A custom task is a tenant object you create with the Create Custom Task task, pointing at an app's ID, site and route, and you have to create or migrate it separately in each tenant. Workday now files custom tasks under Legacy Components in the Developer Guide; for a new Extend app, use model tasks.

Both do the same basic job: give people a named entry point into an Extend app, so nobody has to remember the app's URL. They differ in where they live, how they get context and security, and which places in Workday can show them.

How a model task is defined

A model task has a name, an optional label, a routePath that must match a routingPattern in the AMD's tasks array, and securityDomains drawn from the app's own domains. Leave out businessObject and the task is context-free; users find it in global search.

{
  "id": 1,
  "name": "EquipmentHome",
  "label": "Equipment Requests",
  "routePath": "/",
  "securityDomains": ["ManageEquipmentRequests"]
}

Add businessObject and the task appears as a related action on that object instead. The object can be one of the app's Extend business objects or a Workday-delivered object that supports the target attribute; it can't be an attachment. At run time, Workday swaps {taskObjectId} in the route for the Workday ID of the instance the user started from:

{
  "id": 2,
  "name": "ViewEquipmentRequest",
  "label": "View Equipment Request",
  "routePath": "/requests/{taskObjectId}",
  "businessObject": "EquipmentRequest",
  "securityDomains": ["ManageEquipmentRequests"],
  "secured": true
}

"secured": true adds contextual security on top of the domain policy: the related action shows only on instances the user is contextually secured to. With an Extend object, that context comes from the object's secureByTarget field; with a delivered object like WORKER, Workday evaluates the user against that worker. When you apply contextual security, Workday says the task's domain policy shouldn't contain unconstrained groups.

Names must start with an uppercase letter, use only letters and digits, and stay within 100 characters; a label must be unique per model component type in the app. An app can have up to 20 tasks.

How a custom task is defined

On Create Custom Task (secured by the Custom Task domain) you enter a title, the app's applicationId from the AMD, its siteId from the SMD, and a Route Path. The route can carry path and query parameters and two keywords: {customTaskObjectId}, the ID of the instance the task was launched from, and {taskTitle}. Workday resolves the URL as /<tenantname>/d/wday/app/<applicationId>/<siteId>/<routepath>.

Context is chosen in the Business Object section:

• Secured selection: Workday prompts for an instance and evaluates contextual security, so with Worker and Employee as Self the task runs only from the user's own profile.
• Unsecured selection: Workday prompts for an instance but skips contextual security, so every instance is available.
• No selection: no prompt and no related action.

Security is the domains you pick on the task, plus a Testing Mode Only check box that limits it to permitted testers.

Where each can appear

Two rows need a note, and the To Do row has its own guide: using a model task as a To Do in Onboarding or Hire. Workday states that model tasks aren't supported as worklets; you can still add context-free model tasks to a custom dashboard as menu items. For profiles, Workday's task entry-point page says tasks aren't currently supported on profile groups, while the model Profile Group component accepts context-free model tasks and model reports under a profile such as WORKER_PROFILE. Read that as: configure the tab through the app's Profile Group component, not through the tenant's profile group task.

Workday documents two display limits for a custom task on a custom dashboard: the dashboard has no scroll bar, so a long app page can be cut off in the worklet, and because custom dashboards are read-only, an edit page renders as a view page.

Why the tenancy difference matters most

Everything about a custom task sits in one tenant. Move the app from Implementation to Production and the custom task doesn't come with it; it has to be recreated or migrated, and any Quicklink that uses the app URL has to be updated per tenant.

A model task is part of the app. Promote the app and the task arrives with the same route, label and domains, and its domain policy is configured in App Manager like the app's other domains. The cost is that model components follow the app lifecycle: after promotion you can't delete model components that deployed in an earlier version, and new or changed model components deploy to Implementation, Sandbox and Production tenants with Workday's Weekly Service Update, so they're subject to promotion deadlines. Name and route tasks with that permanence in mind; the app promotion guide covers the deadlines.

When a custom task still makes sense

Keep a custom task when you maintain an older app that already depends on one, or when you need an entry point Workday documents only for custom tasks, such as a custom report on a Workday-delivered worklet. Before replacing one, check what uses it: Workday won't delete a custom task that an active custom business process, dashboard menu, profile group or worklet still uses.

Check that the entry point works

For a model task, deploy to a Development tenant, then sign in as a user in the domain's security group:

1. Context-free task: search for its label in global search and open it.
2. Context task: open an instance of the business object and look for the task under related actions; with secured on, confirm it is missing on an instance the user isn't contextually secured to.
3. Open the page and confirm it received the ID: routeParams or queryParams should hold the instance's Workday ID, not the literal {taskObjectId}.

For a custom task, use Custom Task > Run as a related action on the task itself, then repeat the same checks in each tenant where you created it.