Concept | Project permissions and asset sharing#
This article outlines some of the key features built into Dataiku to enable effective collaboration from the perspective of a project designer. In particular, it examines:
User profiles and user groups
Global and project-level permissions
Sharing assets outside of projects
Collaboration challenges and responsibilities#
A data platform that enables effective collaboration is able to meet both of the following needs:
Users can work together, share assets, and track progress in real-time on a shared space.
Users can access what they need, but nothing more. Collaboration must be achieved in a framework that respects data privacy and security restrictions.
The extent to which you’ll need to familiarize yourself with the features addressing these challenges depends on your role with respect to Dataiku.
On one end of the spectrum, an instance administrator will want to master all instance-wide settings that govern the everyday experience of users.
At the other end, some users may only explore assets that other users have created. These users can largely ignore the features discussed here as other users will be responsible for granting them access where it is needed.
However, users in between — those designing and/or deploying projects and data assets — can benefit from a basic understanding of some of the concepts at work that govern their ability to collaborate effectively on a daily basis.
User profiles#
One of the first collaboration concepts that a user may encounter is the idea of a user profile. Common user profiles include designer, reader, or explorer.
It’s important to recognize though that user profiles are a licensing concept. They are not used for security and are not the key concept for understanding project permissions and asset sharing.
Dataiku Cloud users can find their profile from the Users, Profiles & Groups panel of their Launchpad.
All users can find their profile by clicking the Profile and settings gear from the User center in the top right corner of the instance.
User groups#
From the standpoint of daily collaboration, much more relevant than the user profile is the concept of a user group.
Users can belong to any number of groups. An organization can set its own principles for defining group membership. Groups might be based on:
Expertise (e.g. data_team)
A region (e.g. northeast)
A line of business (e.g. retail)
Any initiative
Groups are not mutually exclusive. One user could belong to all of these example groups.
A group has two levels of permissions:
Permission level |
Scope |
Examples |
|---|---|---|
Global |
Instance-wide |
|
Project |
Project-specific |
|
Note
See the reference documentation for the complete list of global-level and project-level permissions.
Project-level permissions#
Managing global permissions for a group is typically the responsibility of an instance administrator. Project designers though will want to be aware of the second type of group permissions: project-level.
The Permissions panel on the Security page for a project includes a matrix of permissions specific to that project. A user with admin rights on the project, such as the project owner, has the ability to define the exact permissions for groups or individual users within that project.
Tip
Co-creators of the project, for example, would need the permission to write project content. However, many other users may work exclusively downstream using assets created by the project. These users would only need permission to read a dashboard or run a scenario.
Collaboration beyond one project#
The Permissions panel in the project security page governs who can do what within a project. But what about collaboration between projects or on the instance more generally?
Object sharing between projects#
When Flow zones are not sufficient for dividing a workflow into stages, you may want to divide one large project into a series of smaller projects. The final output of one project (a dataset or a model perhaps) may be shared as the starting input to another project. This can be particularly helpful where differential access between project stages is required.
You can share a Flow object with another project by selecting Share in the Actions tab and choosing a target project.
The Shared objects panel of the project security page provides a view of all objects in the project shared with other projects.
See also
Learn more about shared objects in the reference documentation.
Project discovery#
Once you have the correct groups of users interacting with your project within the correct limits, you may or may not want others unaware of the project to be able to find your work. This could depend on many factors such as the project’s lifecycle stage, scope, or sensitivity.
Within the Permissions panel of the project security page, the settings for Project visibility and Project access requests — if enabled by the instance administrator — can allow other users to discover the project, view its summary, and request access.
See also
Learn more about project discovery and request access workflows in the reference documentation.
Asset publication#
In addition to allowing for discovery of your project itself, you might want to publish specific assets from your project to other shared resources.
In the Actions tab of a dataset, for example, the Publish button will enable you to share your work on a workspace, feature store, or data collection.
What’s next?#
This article includes links to more information about many of the topics introduced here. Consult those most relevant to you.
See also
For more information, including how-tos on sharing projects and Dataiku assets, visit Sharing Projects & Dataiku Assets in the Knowledge Base.
Tip
You can find this content (and more) by registering for the Dataiku Academy course, Collaboration. When ready, challenge yourself to earn a certification!