AEM Workflow: Request for Deletion Workflow in AEM

Request for Deletion is an AEM OOTB Workflow. In this blog, we will talk about,
1. What is a request for the deletion workflow?
2. How it works?
3. What are the challenges with this workflow?

Request for Deletion Workflow: This workflow gets initiated when the content-authors don’t have replicate permissions and try to delete a page.

Request for Deletion OOTB workflow has four steps:

Fig1: OOTB Request for Deletion Workflow

Step1: When an author deletes a page, the "Request for Deletion" step gets executed and it initiates a notification to the administrators by default (you can change it to approver group).
Step2: When the approver approves the request, the page gets deactivated from the publisher.
Step3: Again a request goes to the administrator or content-approvers to take the approval to delete the page in the author instance.
Step4: When the request gets approved, the page gets deleted from the author server.

Product Bug: When the author deletes the page, a request for deletion notification is visible to the approver inbox, but after the approver approves the request and workflow completes the deactivation of page step, the workflow itself aborted after step2.

Because of this issue, the page is getting deactivated from publishing but the page is not getting deleted from author CRXDE and because of that all the pages authors deleted in author instance are not visible in Sites console but still sitting in CRXDE.

Fig2: Request for Deletion workflow history to show aborted scenario

I raised it as a daycare and this is what they replied.
Solution: “I looked at the code that gets triggered in this event (an event handler). What it actually does is, trigger a Request for deletion workflow with system user wcm-workflow-service, when the user deleting the page does not have enough permission.

Now if you provide delete and replicate permission to that user "wcm-workflow-service" at the /content level the workflow is getting completed successfully.
Always remember that Request for deletion workflow has two participant steps, so you need to approve twice, once for deactivating the page, then for the deletion of the resource step.”

And the above-mentioned solution worked for me.

Fig2: Request for Deletion workflow history after fixing permissions

Note: I face the above issue in AEM 6.5.2, so I am not sure what all AEM version has this
issue. So check accordingly.

Client Concern:
Deletion is a very crucial activity that can lead to loss of content/pages if done unintentionally. That’s why AEM provided approvals at two levels. But in our project, the client concern was that it’s quite annoying for the content-authors when they just delete an unpublished page from the author, for this also it asks for two-level approvals.

So here we removed the second level approval by considering that if the approver approved at the first step, it means that he really doesn't want that page/content in the author as well as publish. And I think it really makes sense too as it is very difficult to manage so many approvals also.

Fig4: Workflow model after removing the approval step

Note: Always remember, before you hand over the production server to content-authors, always decide the workflow for a request for deletion, make the authors aware about it and test it once because after authors start authoring, and you face this kind of product bug, where pages still exist in author after deletion, you have to fix them by going to the crx and this is hectic task also for a developer and authors.

Source: http://www.sgaemsolutions.com/2020/04/aem-workflow-request-for-deletion.html