The permissions model

Two separate mechanisms decide what someone can see and do in arcodash, and they don’t always move together. Understanding both — and how they interact — explains some behavior that looks like a bug the first time you hit it, but isn’t.

Layer 1: per-object sharing

Every query, dashboard, and monitor has its own access control, independent of every other object. An object’s visibility is one of:

• Workspace — every signed-in member of the organization can see it (the default).
• Restricted — only the owner, an admin, and anyone explicitly granted access can see it.

A dashboard can additionally be made reachable outside the organization via a secret-token public link — that’s a separate feature layered on top of visibility, not a third visibility option. See Public links.

On top of visibility, an object’s owner (or an admin) can grant specific users or groups direct access at one of two levels: viewer (see it) or editor (see and modify it). Owner is the object’s creator (or an admin) — a fixed role, not something you grant. See Sharing with your team for how to actually grant viewer/editor access.

This whole layer answers one question: can this person open this query/dashboard/monitor at all, and can they change it?

Layer 2: group-based data source access

Separately, every data source is scoped to groups, not individuals — see Groups and data source access. A user’s reachable data sources are the union of what every group they belong to can reach; there’s no per-user data-source grant that stands apart from group membership.

This layer answers a different question: can this person’s query actually run against this data source, and see the real rows it returns?

How the two interact

A dashboard’s own sharing (layer 1) controls whether someone can open the dashboard page at all. It says nothing about whether the queries backing that dashboard’s widgets are things the viewer’s groups can reach. These are checked independently:

• You can be granted viewer access to a dashboard whose widgets are built on a data source none of your groups reach. You’ll see the dashboard, its layout, and its widget titles — but a widget whose query needs that data source will fail to load its result for you, even though the dashboard itself opened fine.
• Conversely, being in a group that reaches a data source doesn’t put every query or dashboard built on it in front of you — those still need their own visibility/sharing to allow you in, same as any other object.

[!NOTE] In practice this shows up as: “I can see the dashboard, but this one widget just won’t load.” The fix is either sharing granting your group reach to the underlying data source, or building the widget on a query whose data source your groups already reach.

Where to go next

• Sharing with your team — granting layer-1 access on a specific query or dashboard.
• Groups and data source access — the layer-2 mechanism, including the restricted/unrestricted toggle and a worked example.
• Roles and permissions — the org-wide capabilities (like create_embed or share_public_anonymous) that gate what a role can do at all, underneath both layers above.