Workflow Approval Process (we don't want to use it)

[this-that-the-otter]

We're running AEM 6.5.19. 

We would prefer not to use workflow approval inbox/email chains and instead rely solely on content permissions. 

However, some of our editors are seemingly subject to certain approval workflows when they attempt to replicate, edit, move, or delete content. 

For example, I might have full permissions on a node (except for edit acl), yet if I attempt to replicate this page, an approval workflow winds up in the admin user's inbox. 

We've been deleting these workflows but are worried user's requests wind up in a workflow black hole of sorts. The user may be expecting someone to act on the request.

We would prefer for a user who does not have the correct permission on a node to be unable to take the action. 

We do not want to trigger a workflow that winds up in the admin user's inbox. 

We would prefer that the action just not be possible for a user without the corresponding permission. 

In a different case, some of our users seem not to be subject to this workflow approval process? 

I'm not sure what separates these 2 cases, maybe some underlying permission difference? 

A support engineer suggested as much, and also suggested copying some of the default workflows and editing them to remove the approval step? Any advice on this? 

Also, assuming this is a potential solution, how would we change association from the default workflow to the new/edited workflow without the approval step? 

Thanks for any suggestions and/or info on how your team is or is not using workflow approval steps.

[giuseppebag]

hi @this-that-the-otter,

I would start by checking all user groups to ensure that the replicate permission has not been mistakenly assigned to any undesired groups: check the specific permission sets for users who bypass workflows versus those who trigger them.

Without the replicate permission, users will be unable to replicate any resources, as the Publish button will not be visible, and the Manage Publication feature will fail, displaying a red error message.

You should also verify if any custom launchers are triggering workflows, especially if those workflows are using a service account that has the replication permission. 

Additionally, take a look at this article, which explains how to trigger a customized workflow using the Manage Publication feature.

Besides, you can navigate to the Launchers console to examine all active workflow launchers and identify which models (Request for Activation, Request for Deletion, etc.) are associated with specific events. If workflows are reaching the admin inbox, check the participant step configuration in the workflow models because the participant step is typically assigned to the admin user or admin group, which explains why requests accumulate there.

[SantoshSai]

Hi @this-that-the-otter,

From what you’re describing, it sounds like two things may be happening at once:

1. Permissions vs. workflow launcher behavior
   – If a user truly has the replicate permission on a node, the replication should happen immediately, no approval needed.
   – If they don’t have the permission, normally the Publish button wouldn’t even show up. The fact that you’re seeing “Request for Activation” workflows fire suggests that one of the OOTB workflow launchers (e.g. Request for Activation or Request for Deletion) is still active and is catching that event. Those models are often configured to drop tasks into the admin inbox by default.

2. Why some users see workflows and others don’t
   – Likely tied to group membership. Some groups have the replicate permission directly, so those users replicate straight away. Others don’t, so their attempt triggers the workflow launcher. That’s why you’re seeing inconsistent behavior.

What you can do:

• Go into Tools -> Workflow -> Launchers and check for active launchers on /content paths. You’ll probably see the default Request for Activation and Request for Deletion launchers. If you want to enforce “permission only, no approval queue,” you can either disable these launchers or replace them with simplified models that don’t include a participant/approval step.

• In Tools -> Security -> Permissions, audit which groups actually have replicate. Make sure it’s only on the groups that truly should. That way, if a user doesn’t have the permission, the button won’t be available at all, and no workflow will trigger.

• If you do decide to customize, copy the default workflow model, strip out the participant step, and re-associate the launcher with your new model. That way you keep a clean history but eliminate the approval behavior.

[arunpatidar]

Hi @this-that-the-otter 

You can rely on OOTB edit, delete, quick publish etc action buttons to perform those operations.

And if the user does not have the permission, you can hide corresponding buttons for them.

Example on below path you can deny read permission to your all content-authors and allow read permission for author who suppose to see the publish button
/libs/dam/gui/content/assetdetails/jcr:content/actions/quickpublish

[this-that-the-otter]

Thanks all for each of these very helpful replies. I will investigate each to hopefully get to the bottom of this. I really appreciate your help!

[this-that-the-otter]

Here's some more info: 

I have an active / running example where a user has full permissions on a node and its parent, etc. (except edit acl) -

the workflow info is:

efghi
/content/xxx/en/yyy/zzz/aaa/bbb-ccc
/var/workflow/instances/server3/2025-10-07_3/request_to_complete_move_operation_112 (this node shows: /var/workflow/models/request_to_complete_move_operation as value for "modelId" parameter name)
Request to complete Move operation
A move operation was done by an author and needs to be confirmed for replication
1.2

In touch UI I see this user's groups as:

Groups that this user is a member of
Role: Approver
DAM Base
Contributors
everyone
xxx - Approver Access
yyy - Approver
workflow-users

In the classic ui, groups for this user appear slightly different -

contributors and workflow-users don't show (maybe these groups are members of the listed group in this interface)?

I don't see any launchers with this content path. I do see the model "request to complete move operation"

Some more info, in the past our person who managed permissions would sometimes ask me to reorder them for a particular node or group - via /crx/explorer content explorer - (make sure denies come before allows) not sure if this could be relevant.

Thanks