SmartConnector Permissions
Audience: Administrators, Solution Architects, Developers
Purpose: Understand how permissions govern access to SmartConnectors at both the configuration level and at runtime.
Overview
SmartConnector permissions work at multiple levels:
SmartConnector-level permissions control who can configure and operate a specific SmartConnector.
Bulk run permissions control whether a user can trigger SmartConnectors against a specific Object.
Runtime behavior governs how the SmartConnector itself reads and writes data when an execution runs.
Each of these layers is configured separately and operates independently. For more details about how permissioning works in Kizen, see Permissions.
SmartConnector-Level Permissions
Access controls govern who can view, edit, activate, and run a SmartConnector. These controls are configurable per SmartConnector, which means different SmartConnectors can have different access rules even within the same business.
SmartConnector permissions are configured using two sliders, each representing a separate permission area:
All SmartConnectors: sets the baseline permission level that applies across all SmartConnectors in the business.
My SmartConnectors: sets the permission level for SmartConnectors owned by the user. This value must be at least View/Use and at least the maximum permission set on All SmartConnectors.
Each slider moves across four permission levels for All SmartConnectors: None, View/Use, Create/Edit, and Delete/All.
For My SmartConnectors, there are three permission levels: View/Use, Create/Edit, and Delete/All.
SmartConnector-level permissions control access to the SmartConnector itself. They do not govern what data the SmartConnector can read or write when it runs.
Bulk Run Permissions
To control whether a permission group can run a SmartConnector against Contacts or an Object in bulk, locate the Start SmartConnector toggle under Perform Bulk Actions (Set All) in the Permission Group settings for that Object. This setting uses two permissions levels: None and Delete/All. It is configured per Object type, and only applies to Bulk Action SmartConnectors.
Runtime Behavior
SmartConnectors do not run in the context of a specific user. Records created or updated by a SmartConnector are not attributed to a running user for permission-filtering purposes. The load step writes data based on the SmartConnector's configuration, not based on who initiated the run.
A SmartConnector's access to Kizen data is controlled by the Reference Data made available to that SmartConnector. Any field from any Object can be added as Reference Data, so administrators should be intentional about what data is surfaced to a SmartConnector at configuration time.
Within a SmartConnector execution, the SQL Execution step cannot write data back to Kizen. Only the Load Step can write data to Kizen, and when it does, it can write to any field on any entity regardless of the initiating user's individual field permissions.
Note: Because SmartConnector executions do not run as a specific user, a SmartConnector can write to fields and Objects that the initiating user may not have permission to access directly in the UI. Account for this when granting run access to SmartConnectors that write to sensitive data.
What's Next
With permissions understood, the next consideration is how SmartConnectors can be packaged and moved between environments. SmartConnector Export, Import, and Duplication covers how SmartConnectors can be exported as portable packages, imported into the same or a different business, and duplicated within a business for iterative development.
Last updated
Was this helpful?