We recently migrated our knowledge base to Adobe Experience Cloud 2023 and now our content team can’t publish articles. Every publish attempt fails with “Permission Denied - User lacks kb.publish privilege” even though these same users had full publishing rights in our previous on-premise setup.
The error appears in AEM Admin Console logs but the role-permission mapping documentation for cloud deployments seems incomplete. We’ve verified the users are assigned to the “KB Content Manager” role which should include publish permissions according to the cloud permission model, but something’s clearly not configured correctly.
Has anyone dealt with role-permission mapping issues after migrating to cloud? Specifically need guidance on:
- How cloud permission models differ from on-premise
- Proper admin console configuration for KB publishing
- Whether there are additional cloud-specific privileges we’re missing
This is blocking our entire content update workflow and we need to resolve it quickly.
I’ve seen this exact issue during three different cloud migrations. The cloud permission model works fundamentally differently - it’s not just a direct translation of on-premise roles. In AEC 2023, KB publishing requires both the role assignment AND explicit cloud resource permissions that aren’t automatically migrated.
Check your Admin Console product profiles. For KB publishing in cloud, users need to be in a profile that has both “Knowledge Base - Author” AND “Knowledge Base - Publisher” product permissions enabled. The cloud model separates authoring from publishing as distinct capabilities, whereas on-premise often bundled these together. Navigate to Admin Console > Products > Adobe Experience Cloud > Product Profiles and verify your team’s profile includes both permissions. This caught us too during migration.
Building on what others said - here’s a complete picture of why you’re seeing this and how to fix it systematically.
Root Cause - Cloud Permission Model Differences:
The cloud permission model in AEC 2023 implements a three-tier authorization system that didn’t exist in on-premise:
- Product Profile assignment (what products/modules a user can access)
- Capability permissions within each module (Author vs Publisher vs Admin)
- Resource-level permissions (which specific KB collections/categories)
Your “Permission Denied” error indicates the users have tier 1 (Product Profile) but are missing tier 2 (Publisher capability).
Role-Permission Mapping Fix:
Here’s the exact admin console workflow:
- Admin Console > Products > Adobe Experience Cloud > Product Profiles
- Select your “KB Content Manager” profile (or create a new “KB Publishers” profile)
- Click “Permissions” tab
- Under “Knowledge Base” section, enable both:
- “Knowledge Base - Author” (create/edit articles)
- “Knowledge Base - Publisher” (publish to production)
- If you see “Requires System Admin approval” - this means your org has governance policies enabled
Admin Console Approval Process:
If approval is required:
- Submit the permission change (it goes to pending state)
- System Admin receives notification in Admin Console > Permissions > Pending Requests
- System Admin reviews and approves based on your org’s governance policy
- Wait 15-30 minutes for permission propagation across cloud infrastructure
- Users must log out/in to refresh OAuth tokens with new permissions
Cloud-Specific Considerations:
- Cloud uses just-in-time permission evaluation, so changes take effect faster than on-premise batch updates
- However, there IS a CDN cache layer that needs to clear (hence the 15-30 min delay)
- Publisher permissions in cloud also grant access to the publishing queue monitoring dashboard
- If you have multiple KB collections, you may need to set resource-level permissions per collection
Verification Steps:
After permission changes propagate:
- Have user log out completely and clear browser cache
- Log back in and navigate to Knowledge Base module
- Open any draft article - you should now see “Publish” button (not grayed out)
- Check AEM Admin Console > Activity Log to confirm the new permissions are reflected
- Test publish on a non-critical article first
Additional Cloud-Specific Privileges:
For full KB workflow in cloud, the profile should also include:
- “KB - Workflow Manager” if you use approval workflows before publishing
- “KB - Analytics Viewer” if publishers need to see article performance metrics
- “KB - Version Control” if you need rollback capabilities
These weren’t separate permissions in on-premise but are explicitly required in cloud. The cloud permission model is more granular for better security and compliance, but requires more detailed configuration during migration. Let me know if you hit any issues with the approval workflow.
Thanks for the responses. I checked the product profiles and found the “KB Content Manager” profile only has Author permissions enabled. However, when I try to add Publisher permissions, I get a message saying “This capability requires cloud administrator approval.” Is this a separate approval workflow in the cloud model? Our on-premise setup never had this kind of gating.
Yes, that’s the cloud governance model in action. Publisher-level permissions require System Administrator approval in AEC because they can affect public-facing content. You’ll need someone with the System Admin role to approve the permission elevation. This is actually a security improvement over on-premise where role boundaries were less enforced. Go to Admin Console > Permissions > Pending Requests to see if there’s already a request queued, or have your System Admin directly modify the product profile.
One thing to add - after the System Admin approves and adds Publisher permissions to the profile, there’s a propagation delay of 15-30 minutes before the permissions become active in the runtime environment. We made the mistake of testing immediately after the change and thought it didn’t work. Also make sure your users log out and back in to refresh their permission tokens. The cloud permission model caches credentials differently than on-premise.