Workday Extend App Security: Controlling Who Can View and Edit Pages and CBOs

Workday Extend secures application pages, tasks, and Custom Business Objects (CBOs) using custom .securitydomain model components paired with tenant domain security policies in Workday App Manager. By default, any authenticated user in a tenant can open any page in a deployed Extend app unless you explicitly enable page security on the .securitydomain component and list securityDomains in the .pmd file. Conversely, Custom Business Objects and tasks block all end-user access until an administrator assigns security groups (View or Modify under Report/Task Permissions) and runs Activate Pending Security Policy Changes.

The four layers of Workday Extend security

Understanding why a test user can open a page that renders blank—or why a user cannot see a task at all—requires separating the four independent security layers in an Extend app:

Securing the .task that launches your app's home page does not secure the home page or any secondary pages in the app. Any user with the page URL can still open those pages unless you configure PMD page security.

Declaring .securitydomain model components

Each Workday Extend app can define up to 10 security domains. Security domain filenames and "name" properties must use upper camel case (ManageCharities, SelfServiceTuitionRequest).

When creating a .securitydomain file in the model/ directory, always replace any default placeholder label (such as "My Security Domain") with a descriptive name following Workday functional prefixes (Self-Service:, Manage:, Set Up:, View:, Reports:, or Audit:):

{
  "name": "ManageTuitionRequests",
  "label": "Manage: Tuition Requests",
  "description": "Grants HR administrators access to review and update employee tuition requests.",
  "enabledForPageSecurity": true,
  "id": "fe3a8109c7424b8f91e04b2d8a11c301"
}

Key rules for .securitydomain components

• Maximum per app: 10 security domains.
• enabledForPageSecurity: Set "enabledForPageSecurity": true only if you reference this domain inside the securityDomains array of at least one .pmd page. If a security domain secures only CBOs, fields, tasks, or reports, omit enabledForPageSecurity entirely.
• Permission mapping (Report/Task Permissions): When configuring the domain policy in the tenant, always assign security groups under Report/Task Permissions (View or Modify). Never assign groups under Integration Permissions (Get or Put), which apply only to Workday SOAP web services and have no effect on Extend REST, Graph API, or WQL calls.

Securing PMD pages (securityDomains)

To restrict who can load a page in your Extend app:

1. Ensure every security domain you plan to use on the page has "enabledForPageSecurity": true in its .securitydomain file.
2. Add the top-level "securityDomains" array to the .pmd file (maximum 3 security domains per page):

{
  "id": "tuitionAdminDashboard",
  "securityDomains": ["ManageTuitionRequests", "AuditTuitionRequests"],
  "endPoints": [
    {
      "name": "getRequests",
      "baseUrlType": "app",
      "url": "/tuitionRequests",
      "authType": "sso"
    }
  ],
  "presentation": {
    "title": {
      "type": "title",
      "label": "Tuition Request Administration"
    },
    "body": {
      "type": "section",
      "children": []
    }
  }
}

How Workday evaluates page access

• OR evaluation across domains: If a page lists multiple domains in "securityDomains", a user needs membership in a security group granted access to at least one of those domains.
• View and Modify both grant page access: Workday does not distinguish between View and Modify permissions when evaluating whether a user can open a PMD page. Granting either View or Modify on ManageTuitionRequests allows the user to load tuitionAdminDashboard.pmd (even if the page contains editable inputs). Data mutation security is enforced when the page submits a POST, PUT, PATCH, or DELETE call to the underlying API endpoint.
• Use unconstrained groups for page security: Because a PMD page load does not evaluate a constrained target instance before rendering, Workday recommends assigning unconstrained security groups (or public groups such as All Employees) to domains used for page security, while relying on SSO-authenticated endpoints and secureByTarget on the CBO to filter the data displayed on the page.

Securing Custom Business Objects (object, field, and target security)

Every Custom Business Object (.businessobject) and Attachment Object (.attachment) requires defaultSecurityDomains at the object root. You can also override security on individual fields and enable contextual security using secureByTarget:

{
  "name": "tuitionRequest",
  "label": "Tuition Request",
  "Secured": true,
  "defaultSecurityDomains": ["SelfServiceTuitionRequests", "ManageTuitionRequests"],
  "fields": [
    {
      "name": "requester",
      "label": "Requester",
      "type": {
        "type": "SINGLE_INSTANCE",
        "referencedObjectType": "WORKER"
      },
      "required": true,
      "secureByTarget": true,
      "enableIndex": true,
      "id": "a01bc9120e4a47d18832c4f19002a101"
    },
    {
      "name": "courseTitle",
      "label": "Course Title",
      "type": {
        "type": "TEXT",
        "length": 255
      },
      "required": true,
      "id": "a01bc9120e4a47d18832c4f19002a102"
    },
    {
      "name": "hrReviewerNotes",
      "label": "HR Reviewer Notes",
      "type": {
        "type": "TEXT",
        "length": 1000
      },
      "securityDomains": ["ManageTuitionRequests"],
      "id": "a01bc9120e4a47d18832c4f19002a103"
    }
  ]
}

1. Object-level vs. field-level security

• defaultSecurityDomains: Controls access to the CBO instance and all fields that do not specify their own securityDomains. Users with View permission on any domain in defaultSecurityDomains can read instances (GET); users with Modify permission can create, update, or delete instances (POST, PUT, PATCH, DELETE).
• Field-level securityDomains: Restricts sensitive fields (such as hrReviewerNotes above) to a narrower domain. When an employee with only SelfServiceTuitionRequests queries the CBO via Graph API, REST, or WQL, Workday omits or blocks hrReviewerNotes while returning requester and courseTitle.
• Indexed field restriction (enableIndex: true): Workday only supports defaultSecurityDomains on indexed fields. You cannot add a field-level securityDomains override to a field that has "enableIndex": true.

2. Contextual security (secureByTarget: true) and allowed security groups

The "secureByTarget": true attribute on a SINGLE_INSTANCE field referencing a Workday-delivered object (such as WORKER, COMPANY, or COST_CENTER) determines which types of Workday security groups you are allowed to add to your app's domain security policies:

3. Multiple secureByTarget: true fields on one CBO

If you set "secureByTarget": true on more than one SINGLE_INSTANCE field (for example, requester of type WORKER and chargingCostCenter of type COST_CENTER):

• Domain policy access (OR logic): A user can access the CBO instance if they have permission through at least one of the target instances (for example, they are the worker's Manager or they are the Cost Center Manager for chargingCostCenter).
• Business process step routing (AND logic): If a business process step routes to a constrained role, the recipient must satisfy the security context for all relevant target instances unless separated into distinct role assignments.
• Inspecting an instance's security targets: In the tenant, open the related actions menu on any CBO instance and select Workday Extend > View Security Context (or run the View Security for Extend Related Instance task, secured by Manage: App Manager).

Controlling widget visibility with Model Component Security

When a single PMD page serves both regular employees and administrators, avoid running complex WQL queries against Workday security group tables just to toggle an "Admin Edit" button. Instead, use Workday's recommended CheckAccess CBO pattern:

1. Create a lightweight checkAccess CBO with "defaultSecurityDomains": ["SelfServiceTuitionRequests", "ManageTuitionRequests"].
2. Add a boolean or text field isAdmin with field-level "securityDomains": ["ManageTuitionRequests"].
3. Create a single row in checkAccess with isAdmin populated.
4. Query checkAccess on page load via the Graph API (/graph/v1) and bind the widget's render property to the field's presence:

{
  "type": "button",
  "label": "Approve Request",
  "render": "<% !empty(getAccess.data.checkAccess.data[0].isAdmin) %>"
}

Because Workday strips fields the caller is not authorized to view, isAdmin is returned only for users in ManageTuitionRequests.

Activating security in the tenant and troubleshooting 403 / blank pages

Deploying an Extend app creates the .securitydomain shells in the tenant, but no user has permission until a tenant administrator configures and activates the domain security policies.

Step-by-step activation in Workday App Manager

1. Sign in to the tenant as an administrator with access to the Manage: App Manager security domain (in the System functional area).
2. Run Workday App Manager (or Workday Extend App Manager), locate your app on the Custom Apps (or Installed) tab, and click Configure.
3. On the Configurations tab under Security Domains, click Create next to each new security domain (or select Domain Security Policy > Edit Permissions from the related actions menu of an existing domain).
4. Under Report/Task Permissions, add the required security groups to View (for read/page access) and Modify (for write access).
5. Click Activate Pending Security directly above the Security Domains grid in App Manager, or run the Activate Pending Security Policy Changes task in Workday search.

Common security errors and how to fix them

How kiweely fits

Kiweely models .securitydomain, .businessobject, .task, and .pmd security references together so your page securityDomains, CBO defaultSecurityDomains, and secureByTarget relationships stay consistent across your application package before deployment. Kiweely Personal is free for your Workday personal developer account and its tenant. Any other tenant needs a Personal licence, $99 a month, or a seat in your firm.

Frequently asked questions

Why can any user in the tenant open my Extend app page even though I secured the custom task?

In Workday Extend, custom tasks (.task) and application pages (.pmd) are secured independently. Securing a task only hides the task link in Workday search and related actions menus; anyone with the direct URL can still load the page unless you set "enabledForPageSecurity": true on a .securitydomain component and reference that domain in the top-level "securityDomains" array of the .pmd file.

Should I grant View/Modify under Report/Task Permissions or Get/Put under Integration Permissions?

Always grant View and Modify under Report/Task Permissions on a Workday Extend domain security policy. Integration Permissions (Get and Put) apply strictly to Workday SOAP web services and are ignored by Workday Extend pages, Custom Business Object REST APIs, the Graph API, and WQL queries.

How many security domains can I add to a Workday Extend app and a single PMD page?

A Workday Extend app supports up to 10 .securitydomain model components in total, and each .pmd page can reference up to 3 security domains in its top-level "securityDomains" array.