This section provides an overview of sharing principles, limitations, and approaches.
NOTE: You can share connections, too. See Share Connections below.
In the collaborative approach, two or more users can work on the same flow. When a flow is shared, all flow objects are shared, including:
NOTE: A dataset that is created with parameters cannot be modified by a collaborator. It can only be modified by the owner.
- Job results
- Webhook tasks
NOTE: Sharing of data is managed at the flow level. You cannot share individual recipes or datasets from within a flow.
NOTE: You cannot share a flow with yourself.
All collaborators have access to the above objects, as long as they have permissions to the underlying sources. See below.
Example collaboration methods:
- Distribute the work on a flow with multiple recipes among team members for faster throughput.
- Pass recipes to others for commenting, editing, and general review.
- When stuck, share the flow with the team expert to provide guidance.
A workspace administrator has owner access to objects in the workspace. Some limitations and special cases apply. For more information, see Workspace Admin Permissions.
Creator or designated owner of the flow. Owners have full permissions.
NOTE: There can be only one owner of a flow.
A user with whom a flow has been shared. Collaborators have a reduced set of permissions. See below.
Underlying datasets: Sharing a flow does not change the permissions to the underlying data. If a user with whom a flow has been shared does not have access to the data on the datastore, the user cannot work with the flow's datasets.
- Datasets that are accessed through private connections cannot be shared.
- Stricter permissions sets on the datastore can adversely affect users' ability to access shared flows.
Sharing samples: A flow's samples are not necessarily available to all users who have been shared the flow. In some cases, if a user who has been shared a flow does not have access to a recipe's sample, the user may have to collect a separate sample to view data or edit the recipe associated with the sample. To enable universal access to shared samples, you can use either of the following permissions schemes:
- The default output directories for any user can be accessed by any other user. This configuration must be managed in the base storage layer.
- When the sample is executed, an individual user must set his or her default output directory to a location that shared users of the flow can access.
- Use the imported datasets and references as sources in other flows accessible to the collaborator.
- Add new imported datasets.
- Remove existing imported datasets.
- Change the source of datasets.
- Edit dataset names and descriptions.
- Add new recipes.
- Edit the existing recipes, including multi-dataset operations such as union or join.
- Delete recipes.
- Copy recipes within the shared flow.
- Move recipes to the shared flow.
- Move recipes out of the shared flow.
- Run jobs.
Collaborators do not have the following permissions on a flow shared with them:
- Delete the flow
- Edit the name and description of the flow
- Remove the flow owner's access to the flow
- Delete imported datasets
- Modify imported datasets or change their scope via custom SQL
Owners and collaborators have the same permissions to edit recipes in the shared flow. In the Edit History, edits appear under the usernames of the individual contributors.
NOTE : Multiple editors cannot make changes to the same recipe at the same time.
NOTE: When a column is hidden from a dataset, it is hidden for all users.
Tip: You can review the history of changes to a recipe through the Edit History for a recipe. See Recipe Panel.
You can remove sharing access to a flow. When a flow is no longer shared, the collaborator:
- Cannot see the flow or its objects
- Cannot access them, if the user knows the location of the objects
NOTE: If a dataset from a shared flow is referenced in another flow, when sharing access is removed from the flow, the referenced dataset is still available in the other flow.
NOTE: If a flow is unshared with you, you cannot see or access the datasources for any jobs that you have already run on the flow, including any PDF profiles that you generated. You can still access the job results. This is a known issue.
When initially created, a connection is private. It is accessible only to the user who created. it.
Through the Connections page, you can share your connections with other platform users:
- Share connection with individual users: You can share your connection with specified users of the platform.
- You can also share connections that have been shared with you.
- Make connection public: Public connections are available for use by all users.
When shared, private connections can be shared with or without credentials. If credentials are not shared, new users of the shared connection must supply their own credentials. Those credentials must be permitted access if access to any datasets previously imported through the connection is required.
NOTE: A workspace admin has owner-level access to all connections. However, a workspace admin cannot access or use a connection's credentials if those credentials were not shared by the owner of the connection. For more information, see Workspace Admin Permissions.
NOTE: Password values for credentials are always masked in the user interface.
NOTE: For SSO connections, credentials are never shared.Instead, the Kerberos principal of the user with whom the connection is shared is used to connect. That principal must have the appropriate permissions to access the data.
For more information, see Connections Page.
Sharing connections through flows:
When a flow is shared, any connections associated with it are automatically shared to the specified users. If the connection is configured to do so, credentials are included, so that the new users can immediately begin using the flow.
For more information, see Flow View Page.
This page has no comments.