Analytics dashboard access denied for custom IAM role despite correct policy assignment in OCI security

We’ve created a custom IAM role for our analytics team with specific dashboard access permissions, but users are consistently getting ‘Access Denied’ errors when trying to view dashboards in Oracle Analytics Cloud. The policy syntax looks correct and follows OCI IAM documentation, but something isn’t working.

Our policy statement includes:


Allow group AnalyticsViewers to read analytics-instances in compartment Analytics
Allow group AnalyticsViewers to use analytics-dashboards in compartment Analytics

Users are in the correct group and the compartment structure matches our resource hierarchy. The dashboard resource type should be covered by ‘analytics-dashboards’ but we’re not sure if compartment-level permissions are propagating correctly. Has anyone encountered similar IAM policy issues with analytics resources?

I had a similar problem last month. The issue was that we needed separate policies for the analytics instance itself and the content within it. You need ‘manage’ or at least ‘use’ permission on the analytics-instance resource, not just the dashboards. Also double-check that your group membership is correctly assigned in the Identity domain you’re using.

I’ve seen this before. The resource type ‘analytics-dashboards’ might not be the correct identifier for OCI Analytics Cloud. Try using ‘analytics-workspaces’ instead, as dashboards are contained within workspaces. Also verify your compartment OCID matches exactly what’s in your tenancy structure.

Policy propagation is usually instant, so that’s unlikely. Have you checked the audit logs to see exactly which permission is being denied? Go to Governance & Administration > Audit and filter by your user identity. The audit trail will show the specific resource and action that’s failing. This will tell you if it’s a compartment issue, resource type mismatch, or something else entirely.

Your policy needs refinement to properly address OCI IAM policy syntax for analytics resources, compartment-level permissions, and the correct analytics dashboard resource type. Here’s what’s missing:

First, the resource type hierarchy matters. Analytics dashboards aren’t directly addressable - they’re part of analytics instances. Your policy should be:


Allow group AnalyticsViewers to read analytics-instances in compartment Analytics
Allow group AnalyticsViewers to use analytics-instances in compartment Analytics
Allow group AnalyticsViewers to inspect analytics-instances in compartment Analytics

For compartment-level permissions with nested structures, you need to explicitly handle inheritance. If your dashboards are in a sub-compartment, add:


Allow group AnalyticsViewers to inspect compartments in compartment Analytics

This allows users to traverse the compartment hierarchy. The ‘use’ verb is critical - it grants permission to interact with the instance content, including dashboards.

Regarding the analytics dashboard resource type, OCI doesn’t expose ‘analytics-dashboards’ as a separate resource type in IAM policies. Everything goes through the ‘analytics-instances’ resource. The content-level permissions (dashboards, reports, datasets) are managed within the Analytics Cloud application itself through its own role-based access control.

To verify your setup:

  1. Check audit logs for the exact denied action (it will show ‘analytics-instances’ not ‘analytics-dashboards’)
  2. Ensure users have ‘AnalyticsServiceUser’ or ‘AnalyticsServiceAdmin’ application role assigned in the Analytics instance
  3. Verify the compartment path includes all parent compartments if using nested structure
  4. Test with a policy in the root compartment first to isolate compartment-level permission issues

The combination of correct IAM policy syntax (using analytics-instances), proper compartment permissions (including inspect), and application-level roles should resolve your access issues. The key is understanding that IAM controls instance access while application roles control dashboard visibility.