Sharing & Permissions

In Syntasa, access control operates at two levels:

  • Roles (RBAC): Define access to modules and objects. This doesn't define sharing or permissions. 
  • Sharing: Define who can access the specific record of a object.
  • Permissions: Define what actions a user can perform on a specific record of a object. 

In short, role grants module access, sharing grants record access, and permissions control actions on that record. We have covered about different user roles in following articles:

In this article, we will discuss about sharing and permissions assigned while creating any object like connection, app etc. 

Sharing Options for Apps and Resources

When creating a new app or resource, you can choose a sharing option to control its visibility and access. The available options are Private, Public, and Group, each supporting different permission levels.

Regardless of the selected sharing option, users with the System Admin role always have full access to all apps and resources.

Managing Ownership and Sharing

  • The owner of an app or resource is, by default, the user who creates it.
  • Ownership can be changed later by the current owner or a System Admin.
  • The selected sharing option can also be updated after creation by:
    • The owner
    • A System Admin
    • Any user with Manager permission on the component

When editing a component:

  • The owner and sharing settings are visible and editable only to the owner, System Admin, or users with Manager permission.
  • For other users, these settings are hidden.

Sharing Options Explained

  • Private
    Limits access to the component to the owner only. System Admins can still access private components.
  • Public
    The component is accessible to all users.
  • Groups
    Restricts access to specific user group(s) assigned to the component. System Admins can access these components even if they are not part of the assigned group(s). To know more about creating a group with users, please refer Group Management article.

Permission options for apps or resources

Even when a user has access to an object (such as Connections or Runtimes), the actions they can perform depend on the permissions assigned to each object record.

Key Terminology

  • Object : A feature, component or resource such as Connection, Runtime, App, etc.
  • Object Record: An individual instance of a component(e.g., a specific connection or runtime).

How Permissions Work at the Record Level

When a user creates an object record (for example, a connection), they can choose to keep it private or share it with others. As explained above, a record can be shared with:

  • Public
  • User Groups
  • or, we can make it private

Please note that with 9.1 release, a object can be shared with both public and user groups together. Prior to 9.1, they can be shared either with public or user groups. 

During sharing, a permission level (such as Viewer, Editor, or Manager) is assigned to each sharing option. This permission defines what actions other users can perform on that specific object record.

Example Scenario

Given:

  • User A belongs to Group X
  • User B belongs to Group Y
  • User C belongs to Group Z
  • User D doesn't belong to any group

A connection record named Connection A exists:

  • Shared with Group X with Viewer permission
  • Shared with Group Y with Editor permission
  • Shared with Group Z with Manager permission
  • Shared with Public with Viewer Permission

Outcome:

  • User A can view the details of Connection A but cannot edit, delete, or share it.
  • User B can view and edit the details of Connection A but cannot delete, or share it.
  • User C can view, edit, share, and delete Connection A.
  • Any other user from public like User D can view the details of Connection A but cannot edit, delete, or share it.

Even though all three users A, B and C have access to the same connection record, the actions they can perform differ based on the permissions assigned at the record level.

Available Permissions

Syntasa currently supports the following permissions:

  • Use

  • Viewer

  • Execute

  • Editor

  • Deploy

  • Manager

It is important to understand that not all permissions are applicable to every object. The availability of a permission depends on the type of object. This ensures that users only get actions that are relevant to that specific object.

Below is the mapping of permissions based on object type:

  1. Viewer - to all objects

  2. Editor- To all objects

  3. Manager - to all objects

  4. Use - UDP(User-Defined Process) only

  5. Execute - Apps only

  6. Deploy - Apps only

This ensures that users are granted appropriate and context-specific capabilities on each object record, enabling precise and controlled access management.

Permission Definitions

The meaning and capabilities of each permission type are described below (from lowest to highest level of access):

  1. Use
    • Applicable only to UDP
    • Allows the user to use the UDP within an application
    • The user cannot view or modify the UDP definition
  2. Viewer
    • Read-only access to the object record
    • The user can view the configuration
    • Cannot edit, delete, or share the object
  3. Editor
    • Allows modification of the object configuration
    • The user can update details of the object
    • Cannot delete or manage sharing/permissions
  4. Execute
    • Applicable to Apps
    • Allows the user to create jobs and run the app in both development and production workflows
    • Cannot edit, delete, or share the app
  5. Deploy
    • Applicable to Apps
    • Allows the user to deploy workflows to production
    • Includes the ability to modify app configuration required for deployment
  6. Manager
    • Highest level of permission for an object record
    • Allows full control, including: Edit, Delete, Share and manage permissions
    • For Apps, this also includes Execute and Deploy capabilities

Understanding Permission Priority with Multiple Sharing  

With Syntasa 9.1, an object record can be shared simultaneously with public as well as specific user groups, each with different permission levels.

For example, a record can be:

  • Shared with Public with Manager permission
  • Shared with User Group A with Viewer permission

In such cases, a user’s effective access depends on the combination of permissions assigned through public access and group membership. To understand how permissions are evaluated in such scenario where a user has multiple permissions, refer to user guide: Understanding Permission Priority When Multiple Permissions Are Assigned to a User for a Record

Sharing and Permissions for Syntasa Notebooks

Starting with version 9.1, notebooks inherit sharing settings and permissions from their Notebook Workspace. As a result, sharing and permissions cannot be configured at the individual notebook level.

Notebook sharing settings are inherited automatically from the workspace they belong to.

  • These settings are visible only to the notebook owner, System Admin, or users with Manager permission on the Notebook Workspace.
  • The sharing options appear as read-only and cannot be modified at the notebook level by any user, including the owner or System Admin.

  • To change sharing or permissions, updates must be made at the Notebook Workspace level, not on individual notebooks.