Understanding data sharing
In a nutshell
Data sharing lets you define from which roles' data (records added by users in the role) should be shared with other roles. For example, records added by a manager can be shared with a staff member. Sharing can either be read only or both read and write.
While having role hierarchy allows only users in the higher hierarchy to view their own records and those added by their subordinates, data sharing provides a way to override this default behavior of roles.
Availability
- Data Sharing is accessible in all plans of Creator.
- Only the super admin, admins, and developers can create and manage Data Sharing.
1. Overview
Any organization primarily runs on data. Be it an application for public use, for organizational use, or for personal use, the data obtained from the basic module, a form, is the basis for all further actions that can be performed. Sharing this data between the people involved in the organization facilitates these actions for different processes. To avoid reckless sharing of data, one should limit and consciously build rigid guidelines.
User Permissions encapsulates three triads that govern the accessibility of an application's components and the data stored in it. When you incorporate the potential of permissions, role hierarchy, and data sharing rules in an application, a standardized and controlled approach of data handling can be achieved.
In Creator, we have multiple folds of security to enhance data protection which avoids unnecessary sharing of information. Not everybody in an organization needs access to all the data guarded by the application. Therefore, a restricted flow of data should come into place. To bring about this customization, you can use Data Sharing which will extend access rights to users/roles who will not have access to data by default.
This feature ensures that only the necessary data is accessed by the users / roles. Once the data sharing rules are configured, users associated to other roles and groups can gain additional access to the records that belong to other users. The data sharing rule lets you configure the level of access for the records. The two types of access levels are:
- Read only - The shared records can only be viewed.
- Read/Write - The shared records can be viewed and editing of the records is also enabled.
1.1 See how it works
1.2 Use case
Say you're running a project management company. The Customer Executive team interacts with customers and creates records in a Add Project Details form while the Project Creation team works on the projects. Since they are two different teams under different roles that don't report to each other, the Project Creation team cannot access the Customer Executive team's records by default. Therefore, a data sharing rule is drafted where records can be shared from the Customer Executive team (role) to the Project Creation team. It allows the latter team to access the details of the projects and start working on them.
1.3 Navigation guide
In the Edit mode of the application, User Permissions is situated under the Permissions section of the Settings page. When the Data Sharing tab is clicked, the screen from where you can add new share rules and manage the same appears.
1.4 Data sharing rule configuration
- Name - You can specify a name for the data sharing rule.
- Form - You can further choose the Form whose records you want to share.
- Records shared from - Select the role/user, whose added records will be shared.
- Records shared to - Select the role/user to whom the data will be shared.
- Level of access - You can choose from two types of access - Read Only or Read/Write.
2. Achieving granular access control using user permissions
Any organization will want authority over how their data is circulated within their organization. When a systemized structure which decides how and who can access an application's data comes into place, both the management of data and its security is ensured. Using the combined power of permissions, role hierarchy, and
data sharing rules
helps you achieve this.
Each of the above features allows you to create a different type of exclusive access for users, to the data of an application. They work in different ways to achieve the intricate control of data that an organization needs.
Permissions vs Role Hierarchy
This table explains which records a user can access when they are assigned with the permissions listed below.
Permission Set Actions | Role hierarchy Disabled | Role hierarchy Enabled |
View | Records added by them. | Records added by them. |
Edit |
|
|
View All | All records. | All records. |
Modify All | All records. | All records. |
Data Sharing vs Permissions
Data sharing rules allow the records of a report to be shared from one user/role to another. However, the shared data will be accessible by the receiver only if they have the permission to access that report.
Data Sharing vs Role Hierarchy
Data sharing rules overrule role hierarchy and allow users/roles to access shared data.
Usecase : Say you add a user, Teresa, to an application. You assign her a role and a permission set while adding her to the application. A few scenarios are explained below to bring more clarity on how you can use User Permissions to define which records she can access.
- Scenario 1 - To let her access and delete only the records added by herself in a report, you assign her with a permission set that allows View, Edit, and Delete actions.
- Scenario 2 - To let her access both, her records and the records of her subordinates, you enable role hierarchy.
- Scenario 3 - To customize the sharing of records from a role/user to her (when she does not have access by default), you define a data sharing rule.
- Scenario 4 - To let her view all the records of a report regardless of who added it, you assign her with a permission set that allows View All/ Modify All actions.
3. Points to note
- You can add as many data sharing rules as required by your application.
- When environments is enabled, the configured data sharing rules will reflect on the users in the live mode only when the application is pushed to the Production environment.
4. Related topics
What's next
Previous
What's next
Previous