App Sharing
App Sharing controls who can access your Data App and what they can do with the data it presents. You manage access through two mechanisms: app members and record-level policies.
App Members
Every Data App maintains a member list that determines which users and groups have access. When you add a member to an app, that member can see the app in the App Catalog and launch it.
To manage members:
- Open the Data App in the App Builder.
- Navigate to the Sharing panel.
- Click Add Member to invite individual users or groups.
- Assign each member a role that defines their level of access within the app.
Adding a group rather than individual users simplifies administration. When a new user joins the group, they automatically gain access to every app shared with that group.
If you remove a member from the app, the app immediately disappears from their App Catalog and they can no longer launch it.
Record-Level Policies
Beyond controlling who can see and launch an app, you can define record-level policies that govern what each member can do with the underlying data. Record-level policies use an allow/deny model that applies to four distinct actions.
Actions
| Action | Description |
|---|---|
| Read | View records returned by the app's data widgets. |
| Write | Create or update records through input widgets or data forms. |
| Delete | Remove records through the app interface. |
| Run | Execute queries, procedures, or agent workflows triggered by app controls. |
Allow and Deny Rules
Each action can be set to Allow or Deny for a given member or group. The evaluation logic follows these principles:
- Explicit Deny wins -- If a Deny rule exists for an action, it takes precedence over any Allow rule, regardless of how the rules are layered.
- No implicit access -- If neither an Allow nor a Deny rule is defined for an action, the action is denied by default. You must explicitly grant access.
- Inheritance -- Policies assigned to a group apply to every member of that group. Individual user policies can further restrict (but not expand beyond) group-level grants.
If a user belongs to a group with an Allow rule for Write, but the user also has an individual Deny rule for Write, the Deny rule takes effect. Always check for conflicting policies when troubleshooting access issues.
Configuring Policies
To configure record-level policies for a Data App:
- Open the Data App in the App Builder.
- Navigate to the Sharing panel.
- Select a member or group from the member list.
- For each action (Read, Write, Delete, Run), set the policy to Allow or Deny.
- Save your changes.
Policy changes take effect immediately. Any user currently viewing the app will see updated permissions on their next data request.
Example Policy Configuration
| Member | Read | Write | Delete | Run |
|---|---|---|---|---|
| Analysts (group) | Allow | Deny | Deny | Allow |
| Data Engineers (group) | Allow | Allow | Allow | Allow |
| External Reviewers (group) | Allow | Deny | Deny | Deny |
| jane.doe (user) | Allow | Allow | Deny | Allow |
In this example, the Analysts group can read data and run queries but cannot modify or delete records. The External Reviewers group has read-only access with no ability to execute workflows. The user jane.doe has been granted individual Write access that goes beyond what a typical analyst receives.
Record-level policies in Data Apps work in conjunction with the platform-wide policies defined in Policies & Governance. If a platform policy restricts a user from seeing certain rows, that restriction is enforced inside the Data App as well.
Next Steps
- App Builder -- Return to the builder to configure your app's pages and widgets.
- App Catalog -- See how sharing settings affect catalog visibility.