Permissions and Access Control

Access control in Connect AI is ensured using roles, permissions, and authentication patterns (shared or per-user authentication).

Connect AI’s data governance allows granular permissions by using Role-Based Access Control (RBAC). Instead of each user being granted access to resources individually, each credentialed user belongs to one or more roles. Roles determine permissions to entities, actions, and administrative tasks within Connect AI.

You can further control how users connect to each data source by choosing an authentication pattern—either shared authentication, where all users access a data source through a single service account, or per-user authentication, where each user authenticates with their own credentials.

Users

The Connect AI instance administrator invites new users via email. Every user logs onto Connect AI with a username and password. The administrator can then assign the appropriate role or roles to the new user. See Users for details.

Roles

A role is a collection of permissions to access resources. Roles adhere to the following guidelines:

• Any role can be assigned to any user.
• Every role has specific permissions.
• When a role is assigned to a user, the user gets all the permissions associated with that role. A user with multiple roles has all the permissions associated with each of them. If roles conflict, the more lenient role takes precedence. For example, if a user has role_1 and role_2, with role_1 having Select permission for a data connection and role_2 having no access to the data connection, role_1 takes precedence, and the user has access to the data connection.

Connect AI contains four predefined platform roles: Administrator, Connection Administrator, User Administrator, and Query. You can also define custom roles for more granular security.

The following table defines the scope of each Connect AI platform role.

Role	Scope	Log Access
Administrator	Full account access: connections, users, billing, settings	All query logs and all audit events
Connection Administrator	Create/edit/delete connections and workspaces; manage jobs and data warehouse; assign connection & workspace permissions; view users read-only; query all connections	All query logs; connection-domain audit events only
User Administrator	Create/invite/edit/disable users; assign/revoke User Administrator and Query roles; view connections & workspaces read-only; query connections where explicitly granted	User-domain audit events only (invites, user creation, role changes, PAT activity, impersonation, login activity); user’s own query logs only
Query	Query connections where granted permission; authenticate via User Credentials when configured	User’s own query logs only; no audit log access

Permissions

Permissions are more granular levels of access that make up roles. You can assign the following entity permissions:

For the purposes of permissions, an entity is a data connection (for example, Salesforce1) or a workspace (for example, MyWorkspace). Entities are displayed with the connection logo, and workspaces are displayed with a folder icon.

• Select: The user can select rows from tables in an entity.
• Insert: The user can insert rows into tables of an entity.
• Update: The user can update rows in tables of an entity.
• Delete: The user can delete rows from tables in an entity.
• Execute: The user can execute stored procedures in an entity.

Connect AI offers two paths to assign these permissions: by user (one user across multiple entities) or by entity (one entity across multiple users).

Assign Permissions by User

You can grant entity permissions on a per-user basis from the Edit User page, or to multiple users at once by defining a custom role on the Edit Role page.

Click an individual box in the table to toggle a permission for a single entity, or click the box at the top of a table column to toggle that permission for every entity.

Assign Permissions by Entity

You can also assign permissions on an entity basis via the Edit/Add Connection page or via the Workspace page. For example, in the Permissions tab of the Edit Acumatica Connection page, you can grant permissions on the connection to multiple users at once. All users can select data, but only three users can insert data:

Click an individual box in the table to toggle the permission for a single user, or click the box at the top of a table column to toggle that permission for all users.

Authentication Patterns

Service Account (Shared) Authentication

By default, all users on an account can access data from a data source using a service account, or shared authentication. Use service account authentication for read-only data sources that do not contain user-specific permissions or systems that lack per-user authentication.

For example, if you have a connection to Salesforce with a service account (shared authentication), all user accounts can access the data from the Salesforce account created for that Salesforce connection. Query permissions can be customized for each user to restrict available operations, but all users access the same data under these restrictions.

Per-User Authentication

Certain data sources support the ability to force each user on an account to log in to a connection with their own login credentials. Use per-user authentication to comply with regulatory requirements or for data that varies by user. Per-user authentication ensures that users can only access the data from accounts that they need to access. Furthermore, when a connection is configured in this way, it only counts as a single connection slot toward your account maximum.

If a data source supports per-user authentication, an Authentication Model section appears under the Authentication section of the connection settings. Select either Shared Authentication or Per-User Authentication.

If this feature is not available for a specific data source and you would like it, contact our support team to request the feature.

The following restrictions apply to this feature:

• Only Administrators can toggle a data source between Shared Authentication and Per-User Authentication, but users of all roles can log in to a per-user authentication connection with their own credentials.
• Per-user authentication is not supported when using the OData API. To connect a data source to the OData API, you must use shared authentication.
• Caching is permitted only with shared authentication, not per-user authentication. See Caching for details.