---
nav: wcp_docs
parent_url: /wcp_docs/
title: Get Started with Extend Model Components
layout: subsection
---

<b>For ODP Quick Starts and WE Extend Certification Curriculum</b>

This guide provides a high-level overview of the foundational model components—business objects, business processes, attachments, tasks, and security domains—required to build applications in Workday Extend. These components are complementary and must be designed in unison to create a governed, scalable, and consistent application experience.

By the end of this guide, you will be able to:

-   Describe the role of model components within a Workday Extend application.
-   Distinguish among business objects, business processes, attachment objects, tasks, and security domains.
-   Identify the component or components needed for a common app requirement.
-   Explain why data modeling, process design, and security should be considered together.


## <a id="before-you-begin"></a>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 <b>Console</b>, select <b>Tenants</b>.
4.  On the <b>Tenants</b> page, select <b>Create Tenant</b>. 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.

    <b>Note:</b> 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 <i>lmcneil</i> and the password that you just created.


<b>Note:</b> When you sign in to the development tenant with the username <i>lmcneil</i>, you’re signing in as the persona <i>Logan McNeil</i>. 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.

## The Extend Model: A Connected Application Foundation

In an Extend application, <b>model components</b> define how the application stores data, manages data flow, facilitates user access, associates files, and controls permissions for data and actions.

Think of an Extend app as a simple service-request application:

-   A worker submits a request.
-   The request has details, such as request type, date, description, and status.
-   The worker may add supporting files.
-   A manager reviews and approves the request.
-   Different users need different levels of access.


Because no single component handles all these requirements, model components are designed to be complementary. You combine them to create a complete and governed application experience.

![](GUID-e281eb8a-ab25-4f43-9354-83d12da3eeb9.png)

## Model the Data with Business Objects

A business object enables you to create custom data structures to track information not natively available in Workday, such as project-specific details, equipment inventory, or custom survey responses.

Business objects extend the Workday object model and enable an app to store and relate data. In the service-request example, you might create a Service Request business object. Each submitted request is an individual instance of that object.

When designing a business object, start with these questions:

-   What real-world thing does this object represent?
-   What information must be captured about it?
-   What other objects should it relate to?
-   What information needs to be available for reporting, processes, or pages?


For example, a Service Request object could include fields for request category, description, requested date, priority, status, and requester. It could also relate to another custom object such as Service Request Category.

To create a business object:

1.  Add a model component to your Extend project. This component manages data, logic, and security in a manner consistent with the Workday object model, business process framework, and configurable security model.
2.  Create the custom business object and specify its fields and field types. If your business object must reference existing Workday data, you can define single-instance fields that associate it with those native business objects.
3.  Add supporting elements, such as derivative fields and attachment objects, to enhance the data structure.
4.  Deploy the app with the business object to a tenant, where you can post data to it, get data from it, create custom reports, and make it accessible to other apps and services.


<b>Design principle:</b> Create business objects for durable business data, not for every screen field or temporary calculation. Give each object one clear purpose.

![](GUID-bdfcbb21-ae8f-4c1c-96f9-b11a15bd5ecd.png)

## Manage Work and Lifecycle with Business Processes

A <b>business process</b> defines the workflow within your application, applying Workday’s business process framework to your custom application data.

For the service-request app, a process might include:

1.  The worker initiates a request.
2.  The manager reviews it.
3.  The manager approves, denies, or sends it back for correction.
4.  The request status is updated and the process concludes.


![](GUID-f5f9dba3-5a88-4392-aafa-e7f07cb1ad3b.png)

To create a business process in an Extend application:

1.  Add a business process component to your project and associate it with a security domain.
2.  Associate the business process with the custom business object – this ties the workflow to a specific instance of your app's custom data, the same way native Workday business processes are tied to objects like Worker or Expense Report.
3.  Deploy the Extend app to the tenant, where you configure the business process steps and security.
4.  In the tenant, configure the business process definition, the sequence of steps that the business process will execute. A business process might include typical steps that mirror native Workday, such as action/review steps, approval steps, and to do steps. You can also add service steps that trigger an orchestration or another business process.
5.  Configure the routing and approval flow. Define the roles, security groups, or participants responsible for each step and determine their permissions to approve, deny, or edit data.
6.  You can add conditional logic to branch the flow (examples: skip a step, route differently) based on values in the custom object's fields, similar to how condition rules drive native business processes.


![](GUID-780e6998-d086-4a54-8b54-1bef16ecd752.png)

## Store Files with Attachments

<b>Attachments</b> allow users to upload documentation relevant to custom objects or processes, such as attaching project plans to a project object or evidence of completion to a task.

In the service-request app, the requester may need to include supporting documentation, such as a receipt, form, image, or statement. Rather than treating a file as unrelated to the request, use an attachment object to connect it to the relevant business object.

Consider these questions before adding attachments:

-   What business record should the file be associated with?
-   Which users can add, view, or manage it?
-   Is an attachment optional or required at a particular point in the process?
-   Are there confidentiality or retention considerations?


To create an attachment:

1.  Add an attachment component to your Extend application, define its fields (such as <i>uploadedBy</i> and <i>uploadedDate</i>), and associate it with a security domain.
2.  Associate it with a custom or Workday-delivered business object.
3.  Secure the attachment object with a security domain, just as you would any other model component.


![](GUID-caebe7fc-1fc9-4a2a-9815-a96165db9a9a.png)

## Enable Users to Find and Access Your App with Tasks

A <b>task</b> integrates an Extend application seamlessly into the Workday ecosystem.

In practical terms, a task is an entry point that lets users discover and launch an appropriate app action from Workday. For example, an app might provide a task named <b>Create a Work Event</b>.

A well-designed task is:

-   <b>Action-oriented:</b> It begins with a verb, such as Create, Review, Manage, or View.
-   <b>Specific:</b> Users can predict what will happen after selecting it.
-   <b>Role-appropriate:</b> Only users who need the task should see or use it.
-   <b>Consistent:</b> Its naming and behavior align with Workday conventions.


Tasks connect your app to the user’s everyday Workday experience. They should make the app easier to find and use, rather than adding another unclear destination.

To create a task:

1.  Build the Extend application page that the task will navigate to before creating the task itself.
2.  In the Extend app, add and configure the task component. Give it a name that is easy for users to remember. Associate a security domain and define the page route to which it will take the user.
3.  Configure security. Assign the task to the appropriate security groups/domains so only intended users can find and launch it — this reuses existing domain and business process security policies within Workday rather than a separate security model.


![](GUID-0214f934-0946-4903-8ea8-a252d7673387.png)

## Create Custom Reports

Workday automatically builds a reporting layer on top of your custom data model. Report data sources are generated by Workday, allowing for custom reporting without additional developer effort.

The purpose is to let the same standard Workday reporting tools work seamlessly against custom Extend application data, just as they do against native HCM or Financials data. This means:

-   Business users and admins can report on custom app data without needing a developer to expose it first.
-   Reporting stays consistent with the rest of Workday, rather than requiring a separate BI or reporting tool for extended apps.


To create a custom report:

1.  Use the Create Custom Report task and select your Extend business object's data source. You must specify the Data Source, Report Type, and Report name — for most model reports, the Advanced Report type allows fairly complex, multi-data business object reporting (joins on tables) and complex record selection (filtering) and multi-level sorting.
2.  Add fields. The report data source provides a view into the primary business object, giving access to class report fields as well as links to related business objects — so you can pull in your custom model's own fields plus any related native Workday objects you linked it to (e.g., Worker).
3.  Set filters, sorting, and prompts on the primary object as needed, the same as any Workday report.
4.  Secure and share it. Each data source has an association with a primary business object, and has its own security — the defined access for a data source controls whether a user can create or run a custom report that uses it, and each data source has a list of permitted security groups. Share the report only with those authorized groups.


![](GUID-66d43b6e-3d05-4b92-993c-74c463c611db.png)

## Use Security Domains to Secure Access to App Data

A <b>security domain</b> extends the Workday security model to protect your application data.

Domains organize securable items so that you can define which security groups have access to app data and related actions. Users receive access through membership in security groups, and those groups are assigned to security policies.

For the service-request example, you might need to distinguish among:

-   <b>Requesters</b>, who can create and view their own requests.
-   <b>Managers</b>, who can view and act on requests requiring their review.
-   <b>App administrators</b>, who can manage configuration and resolve exceptions.
-   <b>Auditors</b>, who may need view-only access.


Security is not a final implementation step. It directly affects how you design objects, processes, attachments, and tasks.

<b>Design principle:</b> Apply least-privilege access. Grant only the access users need to complete their responsibilities, and validate access using realistic roles and scenarios.

To create a security domain:

1.  Add a security domain component to your Extend application and associate it with other model components, such as a business object or business process.
2.  Deploy the app to a tenant.
3.  In the tenant, create the domain security policy and add security groups to Report/Task Permissions and Integration Permissions. This enables you to restrict access to only those people who are members of the added security groups.
4.  Run the Activate Pending Security Policy Changes task, which activates the changes you made to the security policy.


![](GUID-9feb22ca-b5c1-4533-ae6f-8855d328e503.png)

## Put the Components Together

For a quick reference, this table describes how model components can work together in an Extend custom application.

<table><thead><tr><th>Requirement</th><th>Model component</th><th>Purpose</th></tr></thead><tbody><tr><td>Store request details</td><td>Business object</td><td>Defines the request data and relationships</td></tr><tr><td>Route request for review</td><td>Business process</td><td>Defines the lifecycle, actions, and approvals</td></tr><tr><td>Store supporting evidence</td><td>Attachment object</td><td>Associates files with the request</td></tr><tr><td>Let a worker begin a request</td><td>Task</td><td>Provides a clear Workday entry point</td></tr><tr><td>Control who can see or act</td><td>Security domain and process security</td><td>Governs access to data and workflow actions</td></tr></tbody></table><br/>

## Knowledge Check

## Scenario

Your organization wants an app for employees to submit equipment requests. Employees provide the item needed, business justification, and estimated cost. They may upload a vendor quote. Requests over a defined amount require manager approval. Employees should see their own requests; managers should act only on requests routed to them.

## Questions

1.  Which component stores the item, justification, cost, and requester?
2.  Which component handles the approval requirement?
3.  Which component associates the vendor quote with the request?
4.  Which component gives employees a clear way to begin the request in Workday?
5.  What should you configure to limit data access appropriately?


## Answers

1.  A custom <b>business object</b>, such as Equipment Request.
2.  A <b>business process</b> with the appropriate review or approval flow.
3.  An <b>attachment object</b> related to the equipment request.
4.  A <b>task</b>, such as <b>Create Equipment Request</b>.
5.  <b>Security domains</b> for app data, along with business process security for initiation and workflow actions.