Bulk deleting Workday Extend business object records, and when to purge instead

Delete in batches of 100, from an orchestration

To delete many records of an Extend business object, send DELETE to the object's collection URL with ?bulk=true and a data array of up to 100 instance IDs per request. Workday doesn't allow the bulk DELETE from a PMD page, so run it from an orchestration (or an external client); a page can only delete one record per call with DELETE /{collection}/{id}.

DELETE https://api.workday.com/apps/{appId}/v1/equipmentRequests?bulk=true

{
  "data": [
    { "id": "bd304b424c3f812705b509291a007505" },
    { "id": "bd304b424c3f811cb5cc09291a007605" }
  ]
}

The collection name is the business object's defaultCollection name. For PUT, PATCH and DELETE in bulk, each item must carry its id in the body.

Deleting removes instances. Purging permanently erases the values of fields you marked purgeable, through the Purge Person Data task, and exists for privacy obligations such as GDPR. Order matters between the two, covered below.

The orchestration pattern Workday's samples use

Workday's Employee Relations Incident Management sample deletes a case and everything under it with a Send Workday API Request chain. For each child collection it does three steps:

1. Send Workday API Request, method GET, path apps/ + context.appReferenceId() + /v1/protectedCaseEntryBO, with a query parameter that filters by the parent case's ID.

2. Create Text Template, content type application/json, building the delete body from that response:

   {
     "data": [
       {{#each data.SendWorkdayAPIRequestGetCaseEntries.response.iterator("$.data[*]") }}
       {{#if this.isFirst.not() }},{{/if}}{"id": "{{this.stringAtJsonPath("$.id")}}"}
       {{/each}}
     ]
   }
   

3. Send Workday API Request, method DELETE, same path, query parameter bulk = true, body set to the text template's message.

Only after the children are gone does it delete the parent record with a single DELETE .../v1/protectedCaseBO/{id}. Attachments are handled one at a time, because the DELETE operation on attachment objects doesn't support bulk=true; the attachment objects guide covers their API.

For a large set, two adjustments. The 100-item cap applies per request, so wrap the delete in a Batch Loop with the Size strategy and a Data Breakpoint Number of 100, and build one body per batch; the Batch Loop guide covers splitting and aggregating. And decide the set from a report rather than a raw GET: the same sample's bulk-delete page has the user pick a custom report, runs it, maps each row's workdayID into {"data": [{"id": …}]} and passes that list to the orchestration it launches.

Follow the sample's order, children before parents (attachments, entries, connections, then the case). Workday doesn't document a cascade delete for Extend business objects, so the child records are yours to remove.

What a bulk response tells you

A bulk call doesn't fail as a whole when one item fails. Workday's bulk example returns an overall status of 207, with a data array that has one entry per request item, in the same order as the request, each carrying its own status and either the result or an errors list. In that example two items return 201 and one returns 400 because the user's constrained security didn't allow that record.

So read every entry. A call that comes back without an error can still have skipped records the processing user couldn't access. Write the failed IDs to the orchestration's log or a status record and rerun just those once the cause is fixed.

Records you can't delete

• A record that has been associated with a business process can't be deleted. Workday states this in its business process design considerations; plan for it before you treat a request object as disposable test data.
• Each item is evaluated against the processing user's security on the business object, including any secureByTarget constraint, which is why one item in a bulk call can fail while its neighbours succeed.

Removing every record: redeploy only in Development

If you remove a business object from the app and redeploy to the Development tenant, Workday removes the object and all its instances. That is a fast reset while building, and only there: after promotion, you can't delete business objects, attachments, business processes or regular fields from the app. In Implementation, Sandbox and Production, records go through the API.

Purge: erasing data rather than records

Purging works on field values, not instances:

1. Mark each field that may be purged with "isPurgeable": true. For attachment objects, "isFilePurgeable": true makes the file and file name purgeable too. Derived fields can't be purgeable.
2. Build an Advanced custom report on the business object's data source, with Optimized for Performance cleared, the Purge report tag, at least one identifying field, filters for the instances to purge, and no prompts. The person running it needs unconstrained access to everything it returns.
3. Run Purge Person Data with that report. View report on selected population shows what will be erased first.

Workday's recommendations are specific: purge no more than 25,000 instances at a time and let one purge finish before the next, because each purge spawns a job per affected object and only 25,000 of those jobs can run at once. Watch progress in the Purge Person Data Job Monitor report. Who ran the purge, which data types and which report are recorded and visible through View Object, View Task Audit Trail and View User.

Purging a SINGLE_INSTANCE field breaks the relationship it held, so a purged link to an attachment no longer shows on reports from the parent object.

Purge first, then delete

You can't purge instances you already deleted through the business object or attachment REST API, and deleted instances no longer appear on the Purge Summary Report. If sensitive data must be provably erased, Workday's advice is to purge before deleting. Reverse the order and the data may sit beyond the reach of the purge tool.

Deleting does have one capacity benefit: the per-tenant instance limit, 10 million for Extend Core and Legacy SKUs and 100 million for Extend Professional, is counted excluding deleted instances, and is shared across all Extend business and attachment objects in the tenant. The Extend Object Instance Count report (secured by Manage: App Manager) shows where you stand.

Prove the delete happened

1. Before running, count the target set with the same WQL query or report you used to collect IDs.
2. After the run, read each bulk response entry and confirm every status is a success code; list any that aren't.
3. Run the count again. It should drop by exactly the number of successful deletes, and a GET /{collection}/{id} on a sample of deleted IDs should no longer return the record.
4. If you purged, run the purge report again and compare it with the earlier run, as Workday recommends.