What secureByTarget does on a business object field

"secureByTarget": true on a SINGLE_INSTANCE field tells Workday to delegate contextual security to the instance of the field's target business object, in addition to the security it applies to the Extend business object itself (Reference: Model Component Attributes). In Workday's expense example, with secureByTarget on the Worker field, the Manager group sees a transaction only when the manager has security context to that worker.

That one attribute decides which kinds of security group your app's domains can use at all.

Why only public and unconstrained groups are allowed without it

When an app with model components is deployed, Workday checks whether any SINGLE_INSTANCE field on its business objects or attachments has contextual security. If none does, the app's security domains accept only public and unconstrained groups. If at least one does, any group type can be added (Concept: Allowed Security Group Types for Extend Apps). A policy that already contains a group of the wrong type shows an error on the View Domain Security Policy report.

So if a constrained group such as Manager or Cost Center Manager will not stay on an Extend domain, check whether any SINGLE_INSTANCE field on the app's business objects or attachments sets secureByTarget. Constrained groups are evaluated against a target, which is what that field supplies. The general difference between the two group types is covered in constrained versus unconstrained security groups.

Define secureByTarget in the business object JSON

{
  "id": 1,
  "name": "EquipmentRequest",
  "label": "Equipment Request",
  "defaultSecurityDomains": ["ManageEquipmentRequests"],
  "defaultCollection": { "name": "equipmentRequests", "label": "All Equipment Requests" },
  "fields": [
    { "id": 1, "name": "requester", "type": "SINGLE_INSTANCE", "target": "WORKER", "label": "Requester", "secureByTarget": true },
    { "id": 2, "name": "costCenter", "type": "SINGLE_INSTANCE", "target": "COST_CENTER", "label": "Cost Center", "secureByTarget": true },
    { "id": 3, "name": "item", "type": "TEXT", "label": "Item" }
  ]
}

Rules from the attribute reference and error codes:

  • Only SINGLE_INSTANCE fields. MULTI_INSTANCE fields cannot set secureByTarget.
  • Only targets that support contextual security. The View Business Objects Available to Extend report shows, for each Workday-delivered object, its target name and whether it supports contextual security (Reference: Targets for Referencing Workday Business Objects). Using it on an unsupported target fails validation with F300.

The error code list still includes B203, "You can only define secureByTarget on 1 SINGLE_INSTANCE field in a business object" (Reference: Model Component Error Codes), while Workday's current examples, including the one in Add Business Objects, set it on worker, cost center and company fields together. The two pages disagree. If a deployment returns B203, the documentation does not say which page is current; reduce the object to the one secured field your routing depends on and validate again.

How access and routing work with several secured fields

With more than one secured field, Workday aggregates the security contexts, and the aggregation reads differently for access and for routing (Security Evaluation with Multiple Targets):

  • Access is OR. With Cost Center Manager on the domain policy, a user can see an instance as the cost center manager of either the creating worker's cost center or the costCenter field's cost center.
  • Routing reaches all of them. A business process step routed to Cost Center Manager goes to both cost center managers, if they are different people. In Workday's expense example, either one approving moves the event past that step (Example: Securing Expense Type Transaction to Worker and Cost Center).

Adding a second secured field to widen visibility therefore also adds approvers to every step routed to that role.

Route an Extend business process to Manager or Cost Center Manager

Workday documents secureByTarget as the way to route an Extend business process to constrained security groups (Reference: Design Considerations for Business Processes). Set it on a SINGLE_INSTANCE field of the business process's target business object.

How it affects REST calls and bulk writes

The same evaluation applies when the business object's REST API is used:

  • REST queries. A GET on the business object's collection returns only the instances the processing user is contextually allowed to see. With more than one query parameter, the user must have access to the instances returned by all of them (Example: Query Parameters in Business Object API Requests).
  • Bulk writes. In Workday's bulk example, a manager signed in as Logan has records for his own reports accepted and every other record returns "status": 400; responses come back in request order.

The constraint decides first whether a user can access the instance at all; field-level security then decides each field. A field's own securityDomains array overrides the object's default domains for that field. For reports on these objects, see reporting on Extend business objects.

Change secureByTarget after the app is promoted

Changing secureByTarget on a SINGLE_INSTANCE field is an allowed update after promotion (Reference: Allowed Updates After Extend App Promotion). Because the allowed group types depend on it, removing the last secured field leaves any constrained group in the policies out of bounds, which the View Domain Security Policy report flags. Try the change in a sandbox first and read that report afterwards.

Check that secureByTarget secures the right records

Workday provides a direct check. On any Extend business object instance, the related action Workday Extend > View Security Context runs View Security for Extend Related Instance (secured by Manage: App Manager) and shows the target objects that make up that instance's security context, aggregated across all secured fields. Run it on a typical instance first.

Then test as people, not as an administrator:

  1. Sign in as, or proxy as, a manager whose team includes the requester and open the request. It is visible.
  2. Sign in as a manager outside that hierarchy. The same request is not visible in the app's pages or through GET /equipmentRequests.
  3. Initiate the business process and confirm in the process history that the approval routed to the expected manager, and to both cost center managers when the two cost centers differ.

The domain and page layers that sit around this are covered in Extend app security domains.

Sources checked