Custom Delete Workflow for XFS and CFS

[harshak11490245]

We have a requirement to implement a custom delete workflow to handle the deletion of multiple XFS and CFS instances. As part of this process, the workflow should generate a single, consolidated notification indicating whether each asset was either deleted or locked.

Additionally, in cases where an asset is locked, we would like to explore the possibility of automatically re-triggering the workflow once the asset becomes unlocked.

Has anyone implemented a similar solution, or are there any best practices you could share?

[AmitVishwakarma]

Hi @harshak11490245 ,

Custom Delete Workflow for XFS and CFS (with Lock Handling & Retry Logic):

Try below steps:

1. Custom Workflow Step

Create a Process Step that receives a payload list of XFS/CFS paths (could be passed via workflow metadata or fetched from a list node):

@Override
public void execute(WorkItem workItem, WorkflowSession session, MetaDataMap args) throws WorkflowException {
    WorkflowData data = workItem.getWorkflowData();
    List<String> assetPaths = getPathsFromPayload(data);
    
    Map<String, String> resultMap = new HashMap<>();
    
    for (String path : assetPaths) {
        Resource res = resourceResolver.getResource(path);
        if (res == null) {
            resultMap.put(path, "NOT FOUND");
            continue;
        }
        Node node = res.adaptTo(Node.class);
        if (node != null) {
            if (!node.isLocked()) {
                node.remove(); // or use assetManager.removeAsset() if in /content/dam
                resultMap.put(path, "DELETED");
            } else {
                resultMap.put(path, "LOCKED");
                addToRetryQueue(path); // Your retry mechanism
            }
        }
    }

    storeResult(workItem.getWorkflowData().getPayload().toString(), resultMap);
}

2. Retry Mechanism for Locked Assets

Use one of these:

Option A: Sling Scheduler (recommended for AEMaaCS)
  - Store locked paths in a custom node (e.g., /var/delete-retry-queue).

Run a Sling Scheduler job every few minutes:
  - Re-check lock status.

  - If unlocked, delete and update status.

Option B: JCR Event Listener
  - Listen to unlock events (javax.jcr.lock.lock).
  - If asset was previously locked and queued for deletion, re-run deletion logic.

3. Consolidated Notification
Create a summary like:

Deletion Summary:
- /content/dam/xf1 → DELETED
- /content/dam/cf2 → LOCKED (retry scheduled)
- /content/dam/xf3 → NOT FOUND

Then send using:
  - AEM Email Service (MessageGatewayService)
  - Or external system via webhook, Slack, etc.

4. Workflow Model

Input: List of paths (from workflow metadata or a folder).

Steps:

  - Custom Step to check/delete

  - Notification Step

  - Optional: schedule retry if any locked

Note:
Ensure service user permissions to delete fragments.
Avoid long workflows — offload retry logic to scheduler.
Log each operation for audit/debug.
Use granular exception handling to isolate failures per asset.

Regards,
Amit

[aanchal-sikka]

@harshak11490245 Did you find the suggestions helpful? Please let us know if you require more information. Otherwise, please mark the answer as correct for posterity. If you've discovered a solution yourself, we would appreciate it if you could share it with the community. Thank you!