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

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.

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.

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

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!

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.

I see a few new active workflows in the administrator's inbox - initiated by the wcm-workflow-service - they are requests to delete a page (request for deletion).

Thanks