In SeaTable, various individual shares are available to you. For example, you have the option to share individual bases, tables and views with individual users or entire groups.
Moreover, you have the possibility to create shared datasets that allow you to share a predefined table view with other groups and users.
But what is the difference between the two functions mentioned and in which context does which of the two functions prove to be more beneficial?
Individual release options
With an individual share you grant access to a base, table or view to other persons. The authorized users will see the share as a separate base on the home page. Depending on the type of share, other users can only view or also edit your data.
With individual shares, all users with whom the base, table or view has been shared work on the same data set. For example, users are able to add columns to the shared table or delete existing columns. The changes made are overwritten in the shared dataset and thus visible to all users as well.
For this reason, the individual release options prove to be particularly advantageous when you are working on the same data in a team and changes to the shared data set are desired.
Common data sets
Using shared data sets, it is possible to make a pre-defined table view available to other groups and users so that they can access specific data in a wide variety of contexts and departments.
Unlike individual shares, shared records represent a master table whose contents are used in other tables. Your team members can customize the offshoots of the master table at any time so that they can use the shared record data in a wide variety of contexts.
Unlike individual releases, however, the changes made by users do not affect the underlying data set. The offshoots of the master table are independent of each other and cannot be viewed by other users either. For this reason, shared data sets prove to be particularly advantageous when different departments and employees of a company access certain data sets in their own contexts.
This will be illustrated by the following example:
- An employee list that is relevant to multiple user groups (e.g., HR, Accounting, and Internal Communications) can be made available to your team members via shared records as a template for new tables.
- After your team members import the shared record into a base, they can add columns to the table as they wish and customize it to their specific use cases (e.g., vacation scheduling, payroll, distribution list for internal newsletters).
- The tables accessing a common data record can be synchronized at any time, i.e. compared with the latest version of the data record (e.g. when new employees join or leave).
- There is a top-down relationship here: changes to the common data set are transferred to the dependent tables during synchronization. However, changes in these tables have no effect on the underlying data set.