---
category: [Administration & Integrations, Platform and Product Extensions, Platform and Product Extensions/Integration, Administration & Integrations/Custom Integrations & Apps, Platform and Product Extensions/Workday Extend]
keyword: Extend
nav: wcp_docs
parent_url: /wcp_docs/
title: Control Widgets with Model Component Security
layout: subsection
---
### Prerequisites
- An Extend app with a page whose widget visibility depends on the type of user access, such as either administrator or end-user access.
### Context
When you need to display or hide widgets based on the user access, you can use a model business object that:
- Uses security domains for field-level security.
- Is accessible to all users of the app by default.
- Contains fields that indicate specific states or contexts. Example: boolean field whose access is controlled by a security domain for administrators.
Configuring security domains on a business object is easier than using WQL to perform the security checks, which can be slow and inefficient. If you need to implement changes in security roles during the life of the app in production, it’s easier to change security policy configurations than maintaining WQL code.
Note: Changing widget visibility is mainly for providing role-based convenience for the users. Widget visibility doesn’t provide security itself, as the URLs are visible and can be bookmarked. You should still consider the security mechanisms provided at the service and page levels.
The procedure in this topic walks through an example that shows how to use a model business object and security domains to control widget visibility. In this procedure, the app contains a page used by both administrators and end-users. The page displays a button only if the logged-in user has administrator access.
To see a full sample app that uses this configuration, see the presentation and sample Extend File Transfer app on [Developer Forum: Workday Extend Knowledge Sharing Session - Graph Attachments](https://forum.developer.workday.com/t/workday-extend-kss-december-3-2024-graph-attachments/17930).
### Steps
1. In App Builder, create security domains for administrator and end-user access.
Example: For administrator access, create the AdminAccess security domain. For end-user access, create the EndUserAccess security domain.
Enable page security on both security domains so you can use them for page-level security on role-specific pages.
2. Create a model business object whose main purpose is to check whether a user is an administrator or an end-user.
Example: CheckAccess business object.
Specify the EndUserAccess security domain as the default security domain for this business object.
3. In the CheckAccess business object, add boolean fields that indicate the type of access. Secure each field with the appropriate security domain.
Example:
- isAdmin - Specify the AdminAccess security domain.
- isEndUser - Use the default security domain, EndUserAccess.
Here’s the sample CheckAccess business object, its boolean fields, and their security domains:
```
{
"id": 1,
"name": "CheckAccess",
"label": "Check Access",
"defaultSecurityDomains": [
"EndUserAccess"
],
"defaultCollection": {
"name": "checkAccesses",
"label": "Check Access"
},
"fields": [
{
"id": 1,
"name": "isAdmin",
"type": "BOOLEAN",
"description": "Used for checking if user has admin access.",
"isPurgeable": false,
"enableIndex": false,
"securityDomains": [
"AdminAccess"
]
},
{
"id": 2,
"name": "isEndUser",
"type": "BOOLEAN",
"description": "Used for checking if user has end-user access.",
"isPurgeable": false,
"enableIndex": false
}
]
}
```
4. Deploy the app, and configure the new AdminAccess and EndUserAccess security domains.
Assign the appropriate users and security groups to each security domain policy.
5. Add a row of data to the CheckAccess business object.
Example: This sample mutation adds a row. Note that we only need 1 row to implement the security checks.
```
mutation myApp_ycjtxv_createCheckAccess {
myApp_ycjtxv_createCheckAccess(
input: { isAdmin: true, isEndUser: true }) { }
}
```
6. In the PMD that displays the widget, define an endpoint that fetches data from the CheckAccess business object. You can use REST or Graph API to fetch the CheckAccess data.
Example: This sample endpoint uses a Graph API query to get the isAdmin field.
```
"endPoints": [
{
"name": "getAccess",
"graphQuery": {
"queryId": "getCheckAccess"
},
"httpMethod": "POST",
"authType": "sso",
"url": "https://api.workday.com/graphql/v1"
},
. . .
]
```
Here’s the sample getCheckAccess Graph query component:
```
{
"id": "getCheckAccess",
"query": "query getCheckAccess {
checkAccess: myApp_ycjtxv_checkAccess(
dataSource: {myApp_ycjtxv_checkAccess : {}}
) {
data {
descriptor
isAdmin
isEndUser
workdayID {
id
}
}
}
}
"
}
```
Tip: You can use Developer Copilot to generate the Graph query component. To enable Developer Copilot to detect your model business objects, connect to the tenant before you generate components. Example: After deploying the app that contains the Check Access business object, the “Fetch all Check Access in a query” in the Prompt Library generates the Graph query component.
7. On the widget that needs to change its visibility according to the type of access, add the `render` attribute to the PMD tag.
Set the `render` value to check whether the corresponding boolean field is empty or not.
Example: This sample button displays only if the query returns a row with the isAdmin field. If the logged in user has access to the AdminAccess security domain, the query returns a row.
```
{
"type": "button",
"id": "ShowAdmin",
"label": "Show Administrator Page",
"render":"<%!empty(getAccess.data.checkAccess.data[0].isAdmin) %>",
"taskReference": {
"taskId": "adminPage"
}
}
```
### Result
If a user logs in the tenant as an administrator, the page displays the Show Administrator Page button. If a user logs in the tenant as an end-user, the page hides the button. Note that the administrator page should be secured to the AdminAccess domain.
### Related Information
[Concept: Extend App Security](/wcp_docs/vel1628698852360.html)