AEM workflow access and visibility issues caused by ACL configuration
In AEM, users can lose access to workflow models, see workflows they should not see, or fail to start workflows when access control is applied incorrectly. These problems are usually caused by ACLs on workflow runtime nodes under /var/workflow/models, overly broad deny rules, missing rep:glob restrictions, or requests that still reference legacy /etc/workflow/models paths. Group membership can also affect whether users see only their own workflows or all workflows. Correct the ACL scope, validate the workflow model path, and review effective permissions so workflow visibility and execution match the intended access.
Description description
Environment
- Adobe Experience Manager as a Cloud Service
- AEM Managed Services
- Adobe Experience Manager On-Premise Software
Issue/Symptoms
- Users cannot see workflow models in the Workflow Console even though they belong to
workflow-usersorworkflow-administrators. - Users still see default workflow models such as
InboxRequestafter deny rules are applied. - Users can trigger workflows they were not intended to use.
- API requests fail with
400 Bad RequestandUnknown workflow model with id /etc/workflow/models/.... - Workflow models do not appear in permission pickers when administrators try to target them in access control entries.
Cause
Workflow visibility and access are controlled by ACLs on workflow model runtime nodes under /var/workflow/models. Problems occur when ACLs are applied to the wrong location, when rep:glob restrictions are missing or too broad, when deny rules override intended allow rules, or when workflow requests still reference /etc/workflow/models instead of the runtime path. In some cases, administrators also expect workflow permissions to apply per model without adding path-based restrictions.
Resolution resolution
To resolve workflow access and visibility issues caused by ACL configuration:
- Determine which workflow access problem applies: missing visibility, unintended visibility, unexpected execution access, API failure, or ACL application failure.
- Verify that the workflow model exists under
/var/workflow/modelsand not only under/etc. - Review the affected user’s group membership and confirm the user is assigned to the appropriate workflow group for the required level of access.
- Check for deny
jcr:readentries on/var/workflow/modelsor parent paths and remove or narrow any rule that blocks the required workflow model unintentionally. - To hide a specific workflow model from a group, add a deny
jcr:readACE on/var/workflow/modelswith arep:globrestriction that targets that workflow model, for example/InboxRequest. - To allow only selected workflow models, apply specific allow rules with appropriate
rep:globrestrictions instead of using broad permissions. - If an API request fails with an unknown workflow model error, update the request so it points to the correct model path under
/var/workflow/models. - If ACLs are applied through code, ensure the target folder exists before applying the ACL so the deployment does not fail on a non-existent path.
- Test again as the affected user and confirm that the intended workflow models are visible, hidden, or executable as expected.
- If the workflow model exists under
/var/workflow/models, the correct groups and ACLs are in place, and users still cannot see, start, or restrict the intended workflow models as expected, submit a case to Adobe Support and include the affected workflow model path, user group, expected behavior, and any error such asUnknown workflow model with id /etc/workflow/models/....