Admin UI
Public Preview
User Management v2 required
Admin UI requires User Management v2. If you are using single sign-on, see also Microsoft Entra ID Authentication Integration with Multi-Tenant User Management.
Admin UI (https://adminui.saas.agiledataengine.com) enables self-service administration of:
Environments
Deployment configurations
Target database instances including database connection settings and package deployment rules
External API keys
Users
Adding/removing user access
Role assignment
Notification Events
Notification channels
Notification rules
Admin UI access is granted with the ade-adminui-tenantAdmin role, access should only be given to platform administrators. You can request Admin UI to be enabled in your tenant through the support portal. During the public preview, all features might not initially be available.
Environments
Deploy configurations
Environment deployment configurations are set per runtime environment. They control how the deployment process continues after a commit (more details in Deployment Management).
The following settings are available per runtime environment:
Auto-promote
Auto-deploy
Continue on error
Run test-job
Target database instances
Target database instances are configured for runtime environments. Target database instance configuration includes the database connection and package rules.
Database connections
Click Create Database Instance or edit an existing one. Select the General tab.
Database connection settings depend on the selected type:
Amazon Redshift
Azure SQL Database
Azure Synapse SQL
Databricks SQL
Google BigQuery
Microsoft Fabric
Snowflake
See Configuring Target Databases for more details.
Note that you can test a database connection with the connection test feature:

Package rules
Click Create Database Instance or edit an existing one. Select the Package Rules tab.
Select package deploy mode and configure package rules:
FULL - All packages are installed except the ones listed in package rules
PARTIAL - Only packages listed in package rules are installed
Example:
Package deploy mode | Package rules | Description |
---|---|---|
FULL | SANDBOX_%, TEST_% | All packages will be installed to the target database instance except for packages with names starting with “SANDBOX_” or “TEST_”. Useful e.g. if you want to prevent certain packages from being installed to PROD. |
PARTIAL | %_BQ | Only packages with with names ending in “_BQ” will be installed to the target database instance. Useful e.g. if you are running multiple target database instances per environment and want to control where the packages are installed. |
External API keys
External API keys can be configured for both design and runtime environments:
Click Create external API key or edit an existing one.
Configure a name, a valid until date (optional) and allowed CIDRs (IP address ranges in CIDR notation).
It is recommended to limit API access with allowed CIDRs only to the public IP addresses used by the solutions calling the External API. Creating separate keys for different purposes and applications allows for easier access management and better security.
Users
Configure user access and roles on the Users tab. Whether you are using local users or single sign-on with Microsoft Entra ID Authentication Integration with Multi-Tenant User Management, user access is controlled in the Admin UI.
The ade-login role grants access to ADE Core services. See Role-Based Access Control (RBAC) for further details and role descriptions.
Notification Events
Configure alert and event delivery on the Notification Events tab. See Notification Events for more details.
First, set your notification channels:
Email
Event Grid (Azure)
Pub Sub (GCP)
SNS (AWS)
Slack
Note that you can send a test event with the Send test notification button:

Then, define notification rules that trigger sending notification events to the configured channels:
Setting | Mandatory | Description |
---|---|---|
Name | x | Give a name to the notification rule. |
Channels | x | Select which channels are notified when the rule is triggered. |
Content types | x | Select which event types trigger the rule:
|
Levels | Define severity of delivered event. | |
Types | Define type of delivered event. | |
Rule sources | Define which services used as rule sources. | |
Account paths | Define which environments are used as rule sources. |
Example: Configuring workflow alerts to an email address
The most common use case for Notification Events is to get alerts of failed workflows and smoke tests to an email address. This can be configured as follows:
Create a notification channel:
Name | Alert email PROD |
---|---|
Type | |
Email recipient | email.address@domain.com |
Create a notification rule:
Name | Workflow alerts PROD |
---|---|
Channels | Alert email PROD |
Content types | WorkflowFailure SmokeTestFailure |
Account paths | Path type: ALL Environment account: prod |