Disable the dashboard sharing field for dashboard creators

[Eibraao]

"How can I disable the dashboard sharing field for dashboard creators who are not admins? I tried changing the creator’s permission from 'CAN_MANAGE' to 'CAN_READ', but it had no effect — the creator still retains the 'CAN_MANAGE' permission

[Eibraao]

[MoJaMa]

The Creator will always have CAN_MANAGE in addition to the Workspace Admins.

In your screenshot that 3rd row email is a different one from the creator right?

Creator (1st row email) ends with "a". 3rd row email ends with "s".

Are you trying to make sure that 3rd email does not have CAN_MANAGE?

[Eibraao]

No — I’m not trying to remove the CAN_MANAGE permission from the third email. That user was added only as a test to see how a newly added user with CAN_MANAGE would appear.

My actual issue is different:

Regular workspace users automatically receive CAN_MANAGE on the dashboards they create, which means they can share those dashboards freely. What I want is to disable the sharing option for non-admin users.

I initially thought that changing the dashboard creator’s permission from CAN_MANAGE to CAN_EDIT could help, but I realized this isn’t possible because:

• Creators always inherit CAN_MANAGE by default.
• The dashboard can also inherit permissions from the folder where it was created.
  So if the user has CAN_MANAGE on that folder, they will automatically have it on the dashboard as well.

Given these constraints, I’m looking for another way to disable the share button for users who are not workspace admins, allowing only admins to share dashboards and change sharing settings.

[MoJaMa]

Ah ok. That suggests that your issue lies further up. Try navigating up all the way up to the top and see what your permissions are set up like. In this example, I navigated all the way up to the "Workspace" and I can see that "All workspace users" have View access. Check if yours are more permissible.

But to be clear, there isn't a setting that prevents User1 from creating Dashboard1 and choosing to Share it with User2/Group3.

 

[Eibraao]

Thank you for your response. I wasn’t able to find an ideal way to disable the Share button for regular users, nor to prevent them from adding new users and assigning permission levels directly on the dashboard.

What I’m currently testing is a routine that monitors dashboard permissions through a Databricks API endpoint. The routine checks the ACL list for each dashboard in the workspace, evaluating all users, groups, and their respective permission levels. If it finds that any dashboard has users or groups with permissions beyond the admin group and the owner, it automatically resets those permissions. It also consistently resets the View access for “All workspace users” back to its default state.

My intention with this approach is to enforce stronger control over how sensitive business dashboards and data are shared across users, promoting a stricter “least privilege” access policy.

[MoJaMa]

Makes sense. You can't unilaterally disable the "Share" option. Because it is expected that users share objects they own. There have been requests from customers to try and guardrail this such as maybe members of a team/group can share with each other but no broader etc. But that's not a thing today. So your approach seems like a good corrective option.

[charl-p-botha]

Any movement on this topic?

We too need to restrict sharing, in our case ideally with only other users of the same workspace. As it stands, any user who creates a dashboard can share that dashboard with any account user, across all of our workspaces. This is on Azure Databricks.

[iyashk-DB]

Hey, that thread's already got the core answer right: there's no setting to strip CAN_MANAGE from a dashboard creator, and you already found that out the hard way when the API downgrade to CAN_READ had no effect. That's expected, Databricks docs confirm creators always keep CAN_MANAGE on objects they create, and that's not something an ACL update can override. 

The thing worth separating out for your automated routine: don't waste cycles trying to touch the creator's own permission entry, that call will always be a no-op. What actually matters is who else is in the dashboard's ACL.

Sharing works by adding new principals to that list, so your enforcement job should be diffing the ACL against an allowlist (creator, admins, whatever groups you've decided are fine) and stripping anyone outside that list, rather than trying to change the creator's own entry.

GET /api/2.0/permissions/dashboards/{dashboard_id}
to pull the current ACL, then

PUT /api/2.0/permissions/dashboards/{dashboard_id} 
{
"access_control_list":
    [
      { "user_name": "creator@company.com", "permission_level": "CAN_MANAGE" },
      { "group_name": "admins", "permission_level": "CAN_MANAGE" }
    ]
}

to reset it back to just your allowed principals. PUT replaces the whole list, so anything the creator added gets dropped in one call. If you want to react faster than a polling job, check the `dashboards` service in your audit logs, worth confirming what action name actually fires on a permission change in your workspace before you build detection around it, since the documented action list for that service covers dashboard CRUD and publishing but doesn't call out a dedicated sharing/permission event name. A quick test share plus a look at `system.access.audit` right after will tell you exactly what to filter on.