This article gives a brief explanation of the Exalate user types, how they interact with the app and your task management systems, and how to configure them.
There are 2 main types of users in Exalate: a Proxy user, and an Exalate Administrator. Check out detailed information about the main user types for your task management system.
Exalate Proxy User
A proxy user is a work management system user, who will be used by Exalate to make changes, such as:
- Creating entities
- Updating data
The proxy user impersonates external instances. All changes on local issues are performed on behalf of this user. You can use an existing user account or create a new one, specifically dedicated to Exalate.
Note: For more in formation, check out detailed information on Proxy User configuration.
Exalate Administrator
The Exalate administrator is the user that has access to the "Exalate Console". With the Exalate Console, it is possible to configure and manage connections and the overall synchronization operation.
There are 3 types of Exalate administrators:
The Local Exalate Admin
Local Exalate Admin access is required to configure and maintain all connections in all configuration modes from the local side. Such admin access is required due to the distributed architecture of Exalate. Since each side is autonomous, a local admin will ensure all connections and configurations are working as intended on the respective task management systems.
Admin on both Systems
This admin access is required to configure a connection using the Visual configuration mode. It means that the user has administrative rights on both systems. As a first step in the configuration of the Visual connection, a verification process is started to ensure that the user has the correct access to both systems.
The Project Level Admin
(Available currently since Sep 2021, only on Jira Cloud - version 5.2.0 and higher)
As a project administrator, it is possible to set up Basic connections without having system administrator rights.
The Basic configuration is fixed, and initiating/accepting such a connection is the only allowed configuration. Given this restriction, the configuration can be set up by a non-system administrator as well.
Delegated Admin Access for Non-System Admins
In some situations, you may need to grant non-system admins access to the Exalate Admin Console without giving away system-wide admin permissions. This would allow you to delegate admin maintenance tasks, such as adding, editing, and deleting Exalate configurations, create connections for all projects in Jira Cloud, Jira on-Premise, Salesforce, and Zendesk as well as view and manage Errors, Sync Queue, Triggers, Clean-up, and Bulk Connect.
Note: Setting up delegated admin access varies from platform to platform.
The delegated admin user must fulfil the following requirements:
- be a member of the exalate_console_admin group
- be a project admin
Note: For Jira On-Premise users who are in the Exalate console admin group but are not regular admins, the Exalate menu is found on the top menu bar:
Note: For Jira On-Premise the delegated admin user does not have to be a project admin.
Note: In Zendesk, there are two ways to grant access to the Exalate admin console without granting full admin permissions:
- Create a Custom Role to grant an agent with limited permissions
- Use the agent role with minimal permissions (Contributor)
Note: For Salesforce, it is possible to install the app for specific profiles and the system admin can configure a specific profile to access the app configuration.
Important: The system tracker admin must create the exalate_console_admin group.
Note: A project admin who is also a member of the exalate_console_admin. group cannot accept Public Basic and Visual connections which have been initiated from the remote side.
Why are Administrator-level Permissions required?
The Visual and Scripted configuration mode provides the possibility for deep integration with the underlying task management system through Groovy scripting. This flexibility also has the consequence that any data can be retrieved and modified. Users able to configure Exalate will have the capability to retrieve and/or modify any data. Access to the Exalate Console must be handled in the same way as access to the administration modules of the tracker itself. It is therefore necessary that the authentication to the platform is handled by the platform, and Exalate has no internal user directory.