Are you asking for Tableau Server or Tableau Desktop or ???
This may be more server-oriented. On the desktop/front-end this would
entail authentication, on the back-end, more of the authorization aspects
so the users only see the data they're permissioned to see, in the reports
On Tue, Nov 3, 2015 at 11:44 AM, Toby Erkson <
1 of 1 people found this helpful
Each view in a workbook has its own set of permissions, and they are set by the publisher, at the time the workbook is published. The easiest way to manage these is to create groups, then assign default permissions to these groups, by project (use groups rather than granting permissions directly to users). These get defaulted when a workbook is published in that project, but the publisher can still override them.
It's also possible for the administrator to apply the project permissions to the workbooks and views contained therein, overriding what the publisher had set (until the workbook gets republished ).
Tableau Server has a small set of roles (publisher, editor, interactor, etc), which are really groupings of permissions. Those are often useful as starting points. Unfortunately, they cannot be customized and, for example, Tableau's idea of an interactor includes web editing, which is not something we want to grant to our interactors, so we use that as a starting point, but end up always with "custom" roles.
Thank you, Glauber. This sounds like an ACL-based permissioning model. Is
there also the notion of role-based authorization?
Also, can access be set at more fine-grained level, as in, per record
and/or per cell of data?
On Tue, Nov 3, 2015 at 1:51 PM, Glauber Ribeiro <
Yes, it's ACL (inherit, grant or deny). There are no roles, per se, but the server admin interface use role names (editor, viewer, interactor, etc) as shortcuts for setting certain groups of permissions.
The administrator cannot give fine-grained access, but it's possible to use conditional logic in the workbooks, in conjunction with a function that returns the user id, to "fake" that. One approach that sometimes is taken, is to use a database table to associate user ids to permissions, and use that in the workbook to determine what data to show.
Generally speaking, account management and security management are not Tableau Server's strong areas. Their emphasis has always been on facilitating the sharing of information, rather than controlling the details of how, what, who and when.
Glauber, very helpful! Thank you.
On Tue, Nov 3, 2015 at 2:14 PM, Glauber Ribeiro <
"Also, can access be set at more fine-grained level, as in, per record
and/or per cell of data?"
Tableau Data Extracts (once data has been returned from the DB to the
Tableau Server) are fully capable of row-level security by User Group or
User. However, individual columns/objects are not natively securable.
To support row-level security you must have a column in your data (such as
Customer ID/name, Plant, Business Unit, etc.) to which you can tie a user
I am currently managing Tableau in a SaaS model for multiple clients and
many end-users using this model.
On Tue, Nov 3, 2015 at 1:05 PM, Dmitry Goldenberg <