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.