# Admin The Admin panel is where organization administrators run Yres: users and roles, announcements, security (firewall, secrets), updating environments and — per environment — the DWH settings, health checks and data warehouse logs. The Admin section has two levels: - **Application-wide** — applies to the entire organization and all of its environments (e.g. users, roles, announcements, firewall, application settings). - **Environment admin** — settings and overviews that differ per environment (dev / test / acc / prod) (e.g. DWH settings, health checks, DWH logs, Azure resources). Switch environments with the environment switcher in the top right. :::note Permissions Not every user sees all Admin screens. Visibility depends on the role permissions (see [Users & Roles](#panel--users--roles)). Organization admins always work within their own organization. ::: :::tip All screens & routes The full list of app screens with their route and fields is in [Webapp screens](https://yres.eu/en/wiki/referentie/webapp-schermen). ::: ## Panel — Users & Roles Route: `/admin/panel`. The central management screen with a **Users** table on the left and a **Roles** table on the right.  The screen consists of: 1. **Users table** — shows `name`, `email`, `role` per user and whether SSO is active (`sso`). 2. **Add user** — create a user with an email, role and the choice of whether Microsoft Azure single sign-on (SSO) is required. New users receive an email with a default password, which they (together with their name) change themselves in [Account settings](https://yres.eu/en/wiki/frontend/account). 3. **Roles table** — alongside the default roles you can create your own roles. 4. **Permissions** — roles usually follow a CRUD structure (Create / Read / Update / Delete) per permission type. Permissions that don't fit CRUD (such as building ADF code) live under **"Other"**. You link a role you created to a user via the role dropdown. ### Users - Create with an **email**, **role** and whether **SSO** is required. - The new user receives an email with a default password.  *Creating a new user: email address, role and whether Microsoft Azure single sign-on is required.* ### Roles - Default roles plus your own roles, typically **CRUD per permission type**. - Permissions outside CRUD live under **"Other"**. You create your own role with the **Create role** wizard in three steps:  *Step 1 — Name: give the role a recognizable name.*  *Step 2 — CRUD: tick Read/Create/Update/Delete per resource (Users, Settings, Datasources, …).*  *Step 3 — Other: permissions that don't fit CRUD (release changes, run pipelines, build, …).* ## Announcements Route: `/admin/announcements`. Send messages to all users or only to those of a specific organization (organization admins reach only their own organization). Announcements appear on the homepage and are handy for, for example, scheduled maintenance or an upcoming release.  1. **Create** — open the form to compose a new announcement. 2. **Body (Markdown)** — the text supports Markdown (headers, lists, links). 3. **Start and end date** — both optional. Left empty = immediately visible until the announcement is deleted. 4. **Notify Users** — also shows the announcement in the notification tab at the top of the topbar. 5. **Priority** — sets the color of the announcement's megaphone icon (low / medium / high); the list is not sorted by it. ## Audit Logs Route: `/admin/auditlogs`. Monitor actions of organization users: user-agent, client IP and extra properties per log type. Filterable by date range, severity or user.  At the top are the filters (Date, Events, Users); below them a table that logs the **Causer**, **Organization**, **Action**, **Subject**, **Description**, **IP** and timestamp (**created**) per action, so user actions across the whole organization are traceable. ## Database overview Route: `/admin/databases`. View all databases that the organization uses. If you have added a custom database, you update it here directly.  *The Azure SQL databases per environment, with host, port, server and database name.* ## Firewall Route: `/admin/firewall`. Allow or deny access per IP address, so admins decide from where Yres may be accessed. This improves security by restricting network access.  1. **Create** — add an IP rule. 2. **IP address / CIDR + label** — record the range and give it a recognizable name. 3. **Allow or Deny** — decide whether the range gets access or is blocked. ## PowerBI Models Route: `/admin/powerBiCredentials` (and the models view). Manage unified models per environment, so the right models are called — for example during a refresh via the master pipeline.  *Link Power BI workspaces and models per environment via an app registration, for the embedded BI dashboard.* **Setup:** first add a data source of type **PowerBI** (see [data source requirements](https://yres.eu/en/wiki/referentie/databron-vereisten)). After that the tenant appears in the tenants section and you can retrieve the associated workspaces and models. The expiry date is shown per credential set. ## Rebuild Route: `/admin/rebuild`. Reset data to factory settings — for the entire organization or only the Azure Data Factory.  *Two actions: **Rebuild All** resets the whole organization and **Rebuild ADF** resets only the data factory.* Use **Rebuild ADF** when someone manually edited or deleted ADF code: Yres rebuilds the data factory from the known configuration and so repairs the drift. :::warning Irreversible Rebuild **overwrites all configuration that was not done via the Yres frontend**. Use this with great care. ::: ## Settings (entire application) Route: `/settings`. Applies to **all environments** of the organization. Includes, among other things, the number of **parallel processes** with which sources are loaded into the database and/or the Data Lake (an integer between **1 and 50**).  *Organization-wide, tunable values (Label/Value) such as the **Dynamic Workflow batch count** and the **ADF publish filter text**, plus a Danger Zone for destructive actions.* Each setting is a **Label/Value** pair — among others the batch count for the Dynamic Workflow and the publish filter text Yres uses to decide which ADF objects get published. Below the settings is the **Danger Zone**. Here you cancel the subscription by deleting the organization. This does not affect your Azure environment — it only removes the organization from the Yres portal. :::caution Difference from DWH settings "Settings" here is application-wide. The per-environment DWH settings (service tier, schema names, pagination) live under [Environment Settings](#environment-settings) and apply only to the selected environment. ::: ## Secrets Route: `/admin/secrets`. View the secrets in the associated Azure Key Vault, with their scope and any expiry date. With the right permission you can update a value. Yres never stores credentials in the frontend; they always live in the customer's Key Vault.  An expiry overview (calendar) at the top and below it a table of the stored secrets — **Name**, **Expires_at** and **Status** (`valid` / `expires-soon`). These are the source credentials in the Key Vault; Yres warns before they expire. ## Shared integration runtimes Route: `/admin/shared-integration-runtimes` (available from version **1.55**). Manage self-hosted integration runtimes for ADF. An IR requires a **name** and **description**. After creating it, you download the Microsoft IR tool via the info icon and register the runtime with the keys shown.  *Self-hosted integration runtimes shared across environments and sources.* :::warning Irreversible Creating a shared integration runtime cannot be undone. ::: ## Update Environment Route: `/admin/environments`. Update each environment to the latest Yres version. This starts a deployment (CI/CD pipeline) for the selected environment.  Per environment (dev / prd) a card shows the current **YRES DWH version** and, when there is nothing to do, the **"Already up to date"** state. Updating updates the DWH and republishes the data factory. 1. **Card per environment** — each environment (Development, Test, Production) has its own card. 2. **Version + last CI/CD** — shows the current DWH version and the State / Result / Ran date of the last deployment. 3. **Ordering** — update in order: a non-dev environment shows "update the previous environment first" until the earlier environments are up to date. 4. **Deploy confirmation** — when updating, Yres temporarily resets the database service tier to the default tier; after confirmation the deployment status screen follows. :::tip Recommendation Test a new version first on `dev` (and possibly `test`) before updating `prod`. See the [release notes](https://yres.eu/en/wiki/referentie/release-notes) for the contents of an update. ::: ## Theme Route: `/admin/theme`. White-label Yres per organization: upload a custom icon and login background, choose a brand color, set blur and pick the default mode (light / dark / system).  *Upload a custom icon + login background, set a brand color, blur and light/dark/system mode; a live preview of the login page shows the result. Per-organization white-labeling.* ## Environment admin (environment-specific) The following screens apply per environment. Switch environments with the environment switcher in the top right before you change anything. ### Azure Resources Route: `/admin/azure/resources`. Overview of the linked Azure resources: name, type, location and a direct hyperlink to the resource.  The table shows the provisioned Azure resources for the environment — **Data Factory**, **Key Vault**, **SQL Server**, **SQL Database** and **Storage** — each with their type and location. ### Change deployment rules (Change overwrites) Route: `/admin/changeoverwrites` (available from version **1.54**, only for organizations with multiple environments and **not on the dev environment** — the screen sits behind a NotDevEnvironment wrapper). Translate object names between environments, for example `ERP_DEV.Product` (dev) → `ERP_TST.Product` (test) → `ERP.Product` (prod).  *Map object names between environments (OLD → NEW: source/schema/table), e.g. `CRM_DEV` → `CRM_PRD`, so a change targets the right physical objects per environment.* Apply these rules **before** importing a change into the target environment. Often combined with Source/Schema/Table overwrite so the table name stays stable across all environments. ### Data Warehouse Logs Route: `/admin/dwhlogs`. View and filter the logs with step-by-step actions of executed stored procedures, by date range, stored procedure type and severity. The log lines come from `[Config].[ProcessLog]` in the data warehouse.  1. **Date filter** — limit the log lines to a period. 2. **Procedure and log-level filters** — filter on a specific stored procedure and on severity (Information / Warning / Error / System Error / Dump), with an operator `equal` or `equal and worse`. 3. **Clear error count** — clears the red error-counter badge that appears next to "DWH logs" in the sidebar as soon as there are DWH errors. 4. **Info icon** — opens a steps modal with the step-by-step execution of the procedure. 5. **Failed step** — the modal shows the status and the error message per step, with a link to the associated run in Azure Data Factory.  *The Log Steps modal: the status and timestamp per step; on failure a direct link to the ADF run.* :::note Per environment Data Warehouse Logs are part of **Environment admin**: you see the logs of one environment at a time. Switch between Development, Test and Production with the environment switcher at the top right. For the run-oriented view of load failures, also see [Monitoring](https://yres.eu/en/wiki/frontend/load-management). ::: ### Environment Settings Route: `/admin/dbsettings`. DWH settings configurable per environment.  1. **Settings table** — shows the name and a readable value per setting for the selected environment. 2. **Edit modal** — the right input field per setting (combobox for tiers, free text for schema names, number for storage, read-only for versions). 3. **Tier + storage** — the min/max storage (GiB) depends on the selected service tier (S0–P15). 4. **UsePagination warning** — the screen warns on pagination-related settings. :::caution Configure before the first source Set these settings **before you add the first source**, for consistency. The **Stage and HIS schema settings must be in sync between environments** — otherwise changes won't line up with each other. ::: The most important settings. The names in the table are the actual names as stored in `[Config].[Settings]` (the Yres documentation locally uses a different capitalization; that is noted in parentheses). | Setting (stored name) | Default | Meaning | |---|---|---| | `DefaultStore` | `ROW` | Row- (default) or column-oriented storage for STAGE. Row = efficient reading/writing, column = queries. | | `DefaultKeepStage` | `0` | Truncate the staging table after a delta load (`0` = No) or keep the records (`1` = Yes). The load engine reads the column `keepStage` per table; this setting mainly determines the default when adding a table. | | `DefaultOdsMemOptimized` _(doc: DefaultODSMemOptimized)_ | `0` | Intended to store ODS/HIS tables memory-optimized. See the warning below the table. | | `DefaultStageMemOptimized` _(doc: DefaultStageMemOptimize)_ | `0` | Store STAGE tables memory-optimized. | | `DefaultServiceTier` / `HighServiceTier` | `Standard_S0` / `standard_S1` | Base Azure SQL service tier and the tier scaled up to under high load. | | `AutomaticDatabaseScaling` | `1` | Automatically scale the database for managed loads. At `0`, scaling up is skipped. | | `DefaultSurrogate` | `0` | Automatically create surrogate keys for the natural key (stored in `[LoadManagement].[SurrogateKeys]`; overridable per table). | | `UsePagination` / `PageSize` | `1` / `10000` | Process large STAGE→HIS merges in pages. With `PageSize = OPTIMAL`, Yres determines the page size itself. | | `retryCount` _(doc: RetryCount)_ | `1` | Number of times a failed page is retried (in the proc an empty value falls back to 3). | | `SchemaHIS` / `SchemaStage` | `ODS` / `STAGE` | Names of the HIS and STAGE schema. `SchemaHIS` defaults to `ODS`, not to `HIS`. | | `storageSize` _(doc: StorageSize)_ | `5` | Maximum storage in GiB (depending on the service tier). | | `BiDashboardUrl` / `BiDashboardHeight` _(doc: BIDashboardUrl/Height)_ | `NULL` / `400` | Embed URL and height of the PowerBI dashboard. | | `AllowUpdatesInYresSchemas`, `AllowDeletesFromDB`, `AllowSettingsUpdates`, `AllowLogManipulation` | `0` | Whether users may directly change / delete / configure / edit logs in the database. | | `EnvironmentType` | — | DTAP type of this environment (DEV / TST / ACC / SND / PRE / PRD). | :::warning `AllowUpdatesInYresSchemas` is often 1 after the migration chain The intended default is `0`, but the v1.46 migration seeds `'1'` and the v1.47 seed with `'0'` is then skipped (the setting already exists). So after the migration chain this setting is often **1** — this is the known GODMODE remnant. Check the value and deliberately reset it to `0`. ::: :::note Naming of these two settings For these two settings, it helps to know the naming: - **`DefaultOdsMemOptimized`** — the fallback function `fxGetOptimized` also uses this setting for the HIS side. - **`AllowUpdatesInYresSchemas`** was called `AllowUpdatesInIrisSchemas` (with "Iris") in older versions; the upgrade renames the setting automatically, keeping the configured value. See [Troubleshooting](https://yres.eu/en/wiki/troubleshooting#common-settings-checks-90x) for settings-related checks. ::: ### Health Checks Route: `/admin/healthchecks` (available from version **1.51**). Shows the status of the DWH side of Yres from the webapp. The checks are based on the view **`[Maintenance].[vwYresChecks]`** (the source file is still called `vwIrisChecks.sql`). The view contains the expected list of objects and settings and flags common issues, often with an error message and sometimes with a SQL script to fix it.  1. **Status per check** — each check is OK, Warning or Error. 2. **Error message** — on a deviation the check shows a description of the problem. 3. **SQL fix script** — some checks offer a ready-made script to resolve the issue. 4. **Run with care** — only run a script if you understand it. :::warning Be careful with scripts A generated fix script changes the database directly. Only run it if you are sure what it does and **consult a Yres admin if in doubt**. ::: ### PowerBI Dashboard Route: `/admin/powerBiDashboard`. Shows a PowerBI report within the webapp via an embed URL (set with the setting `BiDashboardUrl`). ## More admin screens Besides the above, the Admin section also contains: - **Global type mapping** (`/admin/globaltypemapping`) — the org-wide default data type mapping (`LoadManagement.GlobalTypeMapping`). - **Theme** (`/admin/theme`) — upload logo and background, blur, primary color and the default light/dark mode. - **Power BI credentials** (`/admin/powerBiCredentials`) — manage the PowerBI tenant credentials. See [Webapp screens](https://yres.eu/en/wiki/referentie/webapp-schermen) for the full list of routes and fields.