Release 2.14.0.0

Keep your secrets in your own Azure Key Vault (Recommended)

#7756

The SchedEx access token, the time-phasing access token and the Hangfire dashboard password can be read from a Key Vault you already own, instead of being deployed as plain text application settings.

Off by default. Leave useKeyVaultForSecrets = false and nothing changes.

New parameters — add them to your .bicepparam file after the existing keyVaultParams param.

param useKeyVaultForSecrets = false

// The vault must be in the same Azure subscription as this deployment.
param applicationKeyVaultName = ''
param applicationKeyVaultResourceGroupName = ''

// Portal: Key Vault > Settings > Access configuration > Permission model.
// Set to true if the permission model is "Azure role-based access control (RBAC)".
param applicationKeyVaultUsesRbac = false

// Marks which secrets in the vault belong to ILAP Analytics. Leave it alone unless asked.
param applicationKeyVaultPrefix = 'Secrets'

Before deploying the apps, create one secret per value in your vault, named with the prefix you set in applicationKeyVaultPrefix:

Secrets--FlowAPI--AccessToken                          (SchedEx service token)
Secrets--TimephasingServiceConfiguration--AccessToken  (time-phasing token)
Secrets--HangfireCredentials--Password                 (only when the background job hangfire dashboard uses a password)

Permissions

• Grant on the whole vault, not on individual secrets.
• On an RBAC vault, whoever runs the deployment needs Owner, User Access Administrator, or Role Based Access Control Administrator on that vault. Contributor is not enough and the deployment fails.
• Use a vault dedicated to these secrets. Do not reuse the vault holding your custom-domain certificates.

Networking

If the vault has its firewall enabled or is reachable only through a private endpoint, it must allow traffic from the Analytics API and the Background job app. In the portal: Key Vault > Networking. The "allow trusted Microsoft services" option does not cover this. Add the apps' outbound IP addresses, or use a private endpoint with the apps on the same virtual network.

Also worth knowing

• Secrets are read when an app starts. A change in the vault needs an app restart.
• A value in the vault overrides the same value in your parameter file.
• A secret that cannot be read leaves the app running and serving traffic. /health reports "Degraded" and names the secret and why it could not be read.
• /health can be read without signing in. It shows the vault address and secret names, never values. Restrict who can reach the app if you would rather not have that visible.

Resource Impact

New Resource creation: Yes, when useKeyVaultForSecrets is true - two permission grants on your existing key vault, one for each app. Nothing is created when the parameter is false, which is the default. Resource config change: Yes (two new app settings on the API and the Background job, both empty unless the feature is switched on) Impacted resource: Analytics API, Background job

The Analytics web app is not granted access to the vault.

Significance

Secrets no longer have to live in a parameter file that sits in source control or gets emailed around. You can adopt this one secret at a time with no downtime, and switch back at any point.

Excel export for the Project Summary Report

#8012

To support large export file for the Project Summary Report we have used background job and blob storage.

The storage account is now always deployed. Before, it was deployed only when moveIlapFileToBlobStorage = 'true'. That parameter now only decides whether ILAP files are also kept in storage.

Check main.sample.bicepparam file

• storageAccountParams now creates a storage account if not exist already. If you had moveIlapFileToBlobStorage = 'false' and left this block at its sample value, set the name you want: 3 to 24 lowercase letters and numbers, unique across Azure.
• Optional: export files are deleted 3 days after they are created. To change that, add:

param reportExportRetentionDays = 3

Also worth knowing

• If the storage account is closed to the internet, the Analytics API and the Background job must reach it through a private endpoint.
• Reference security sample: storageAccountName is now required.

Resource Impact

New Resource creation: Yes

Storage account	Created if you had moveIlapFileToBlobStorage = 'false'. An existing one is kept.
Blob container	project-summary-reports, no public access.
Lifecycle rule	Deletes files in that container after reportExportRetentionDays (default 3).
Role assignments	Analytics API gets Storage Blob Data Reader on the project-summary-reports container. Background job gets Storage Blob Data Contributor on the storage account, now in every installation.

Resource config change: Yes (new app setting ReportExportConfiguration__StorageUri on the API and the Background job) Impacted resource: Storage account, Analytics API, Background job

Significance

Without the storage account, users cannot export the Project Summary Report to Excel.

SchedEx rebranding: rename parameters and update URLs

#7791

ILAP Data Exchange (IDE) is rebranded as SchedEx. Four parameters are renamed and the URLs change.

Renamed parameters. Move your current value to the new name. Keep the token and the true/false value as they are.

Old name	New name
ideApiBaseUrl	schedExApiBaseUrl
ideApiAccessToken	schedExApiAccessToken
SendJobStatusToIDE	SendJobStatusToSchedEx
publicConfigurations.ideUiBaseUrl	publicConfigurations.schedExUiBaseUrl

New URL values

Parameter	Production	Test
schedExApiBaseUrl	https://schedex.com/api/api	https://test.schedex.com/api/api
publicConfigurations.schedExUiBaseUrl	https://schedex.com	https://test.schedex.com

Also worth knowing

• If your network restricts outbound traffic, allow schedex.com and test.schedex.com.
• The old names still work in this release, but support for them will be removed later.

Resource Impact

New Resource creation: NO Resource config change: Yes (app setting values, when the URLs change) Impacted resource: Analytics API, Background job, Analytics Web UI

Hangfire dashboard credentials are required

#7756

hangfireCredentials no longer has a default value, so your parameter file must set it. The sample has always set it.

The sample password is now a placeholder. If your file still has the old sample password, replace it with your own.

param hangfireCredentials = {
  Username: 'admin' // provide your desired username
  Password: 'Enter_a_strong_password_of_your_own' // provide your desired strong password. Do not ship the sample value.
}

Custom domains: declare each certificate once

#8360

Only if an app uses a custom domain (useCustomDomain: true).

Certificates now go in a new customDomainCertificates parameter, one entry per certificate, not per app. Each app's certificateName in webAppParams names an entry in this list. Apps sharing a certificate, such as a wildcard, name the same entry. Leave the list empty when no app uses a custom domain.

param customDomainCertificates = [
  {
    name: 'Azure resource name for the certificate, e.g. cert-<org>-wildcard'
    keyVaultSecretName: 'The certificate name in the key vault'
  }
]

Existing installations: until now, certificateName was both the certificate's Azure resource name and its name in the key vault. Add one entry per certificateName you use today, with that value as both name and keyVaultSecretName, and leave webAppParams as it is. Any other name fails the deployment: Azure allows only one certificate per key vault certificate, and yours already exists.

Also worth knowing: Azure must be able to verify you own each hostname before the deployment runs, through a TXT record asuid.<hostname> holding the app's custom domain verification ID, or an A/CNAME record pointing at the app.

Resource Impact

New Resource creation: NO (certificates are created once from this list instead of once per app) Resource config change: No Impacted resource: Analytics API, Background job, Analytics Web UI (only apps with a custom domain)

Event Hub sample block fixed

#8257

The sample's eventhubConfig block did not compile: both values were commented out, leaving two keys with no value. The whole block is now commented out. eventhubConfig is optional and defaults to empty.

If you copied the broken block, comment out the whole block, or fill in both values if you send operation completion notifications to an Event Hub:

// param eventhubConfig = {
//   NamespaceUrl: 'your-namespace.servicebus.windows.net'
//   EventhubName: 'name-of-your-eventhub'
// }

SQL Server firewall rules (optional)

#8256

New optional parameter sqlServerFirewallRules. Leave it out and you get the AllowAllWindowsAzureIps rule the template has always created.

To let a database admin connect from their own machine, for example to run the CREATE USER grants, keep the first entry and add their address as a second one:

param sqlServerFirewallRules = [
  {
    name: 'AllowAllWindowsAzureIps'
    startIpAddress: '0.0.0.0'
    endIpAddress: '0.0.0.0'
  }
  {
    name: 'Allow-DbAdmin'
    startIpAddress: 'your.ip.address.here'
    endIpAddress: 'your.ip.address.here'
  }
]

• Keep the first entry as it is. 0.0.0.0 means "allow Azure services", which is how the apps reach the database before a private endpoint exists. Changing it cuts the apps off from the database.
• Removing an entry here does not delete the rule in Azure. Delete it yourself once it is no longer needed: az sql server firewall-rule delete -g <rg> -s <server> -n Allow-DbAdmin

Resource Impact

New Resource creation: Only the extra firewall rules you add Resource config change: No Impacted resource: SQL Server

Resource naming convention (new installations only)

#8291

The sample now builds every resource name from four values: org, workload, env and region.

Existing installations: no action. Keep your current names. Most Azure resources cannot be renamed after they are created.

New installations: set the four values at the top of the file. The sample imports the naming functions from ../Modules/naming.bicep, so keep the file in Azure.IaC/Params.

var org = 'contoso'   // your tenant or customer code, lowercase, 9 characters or fewer
var workload = 'ia'   // leave as 'ia'
var env = 'test'      // dev | test | qa | stage | prod
var region = 'noe'    // noe, now, cid, weu, eus2

The key vault in keyVaultParams is not derived. It already exists, so give its real name.

Note on enableFieldImport (no action required)

#8245

Leave enableFieldSyncronization and enableFieldImport at 'true' unless you want the feature off. With enableFieldImport = 'false', the list of ILAP terms to import fails with "Field import feature is coming soon!" without contacting SchedEx. That means the flag is off, not that the network or token is wrong.

Release 2.13.0.0

Parquet export (optional)

#7862

Planning and reporting data can now be exported to Parquet files in a dedicated ADLS Gen2 (hierarchical namespace) storage account, so the data survives the SQL retention purge and can be consumed from Fabric / Power BI via a OneLake shortcut.

The feature is off by default. If you do not want it, add just useParquetExport = false and skip the rest — nothing is provisioned and nothing changes for you.

New parameters — add them to your .bicepparam file after the existing storageAccountParams param.

// Set to true to provision a dedicated ADLS Gen2 (hierarchical namespace) storage account for Parquet data-lake export
// and turn the feature on. Off by default. If false, the parquet account is not created, parquetStorageAccountParams
// below is ignored, and report schedules cannot enable parquet export / planning data deletion.
param useParquetExport = false

// Only applicable when useParquetExport is true.
// Parquet is the sole copy of the data after SQL retention purge, so zone-redundant storage (Standard_ZRS) is the default.
param parquetStorageAccountParams = {
  name: 'Enter any storage name for parquet export'
  kind: 'StorageV2'
  sku: {               // Feel free to adjust based on your need.
    name: 'Standard_ZRS'
    tier: 'Standard'
  }
}

// Container (filesystem) name inside the parquet account — this is the name data-lake consumers (Fabric / Power BI)
// see when they shortcut into the storage. Default 'ia-export'; change only if you need a different name.
// Azure container naming rules (an invalid value fails deployment at container creation):
//   - 3 to 63 characters long
//   - lowercase letters, numbers and hyphens (-) only
//   - must start with a letter or number, and cannot end with a hyphen
//   - no consecutive hyphens
// Treat as set-once: renaming after snapshots exist leaves the old data stranded in the old container.
param parquetExportContainerName = 'ia-export'

Significance

Without useParquetExport = true, report schedules cannot enable parquet export or planning data deletion, because there is nowhere to write the Parquet snapshots.

Resource Impact

New Resource creation: Yes, only when useParquetExport is true

New resource	Storage account (StorageV2, hierarchical namespace enabled, HTTPS only, TLS 1.2 minimum, public blob access disabled) with one blob container named by parquetExportContainerName. Blob and container soft delete are enabled with a 14 day recovery window.
Role assignments	Background job app identity gets Storage Blob Data Contributor, API app identity gets Storage Blob Data Reader, both scoped to the parquet storage account.
App settings	ParquetExportConfiguration__Enabled and ParquetExportConfiguration__StorageUri are added to the API and background job apps.

Impacted resource: Analytics API, Background job

Note on parquetExportContainerName: treat this as set-once. Renaming it after snapshots exist leaves the old data stranded in the old container, and any Fabric / Power BI shortcut pointing at the old name breaks.

Longer default retention for unreferenced planning schedules

#7862

The sample default for planningScheduleDeleteConfiguration.PlanningScheduleRetentionPeriodInDays changed from 7 to 30 days.

This is a sample default only — nothing is forced on you. If you already set this value deliberately, keep it. If you copied the sample as is and want the longer window, update your .bicepparam file:

param planningScheduleDeleteConfiguration = {
  // Existing items .....
  PlanningScheduleRetentionPeriodInDays: 30
}

Resource Impact

New Resource creation: NO Resource config change: Yes (app setting value only) Impacted resource: Background job

Reference security infrastructure sample (optional, no action required)

A separate, self-contained example deployment was added under Azure.IaC/Reference-Security (its own main.bicep and main.sample.bicepparam). It shows one way to put Analytics behind a private network — VNet with private endpoints, app VNet integration, and optional Application Gateway / Azure Firewall / Bastion.

It is an example only and is not part of the Analytics deployment. Your existing .bicepparam file is unaffected. Review and adapt it to your own security requirements before using it. Start from Azure.IaC/Reference-Security/PLAYBOOK.md, which gives the steps in a working order; README.md explains what each control does and TROUBLESHOOTING.md covers the failure modes.

Release 2.12.0.0

Simplified IDE connection parameters

#7820

Renamed two parameters for clarity and added the missing ILAP Data Exchange (IDE) UI base URL. Update your .bicepparam file as follows.

Renamed parameters (keep the same values, just change the names):

Old name	New name
flowApiBaseUrl	ideApiBaseUrl
flowApiAccessToken	ideApiAccessToken

New parameter — add ideUiBaseUrl under the existing publicConfigurations param. It is used to build links to IEAs from the report schedule grid.

param publicConfigurations = {
  // Existing items .....
  ideUiBaseUrl: 'ILAP Data Exchange UI base URL' // e.g. 'https://ilaptest.collabor8.no' (test) or 'https://ilap.collabor8.no' (production)
}

Release 2.8.0.0

Use latest NODE version for web application

#7440

Updated NODE version for web application.

Go to the IlapAnalyticsUi.bicep file. In the resource ilapAnalyticsUi, set linuxFxVersion to NODE|24-lts.

Release 2.7.0.0

Operation completion notification for large schedule import

#7176

Send event hub message in chunk so that notification job doesn't fail for large data. Added BatchSize parameter under existing operationCompletionNotificationConfig object parameter. Use appropriate batch size based on your event hub tier.

Event hub pricing tier	Basic	Standard	Premium	Dedicated
Batch size to use	~2000	~6000	~6000	~150000

param operationCompletionNotificationConfig = 
{
// Existing parameters .....
  BatchSize: 2000 
}

Release 2.6.0.0

Warn user if Analytics version is not compatible with IDE

Card #4020

Removed parameter enableApiVersionValidation. So remove that parameter from your .bicepparam file. Also remove the usages from the following files.

1. main.bicep
2. IlapAnalyticsApi.bicep

Release 2.4.0.0

Improvement of health check for Analytics

Card #6712

Change details

Added new item backgroundJobAppUrl under the existing publicConfigurations param.

  backgroundJobAppUrl: 'your-analytics-backgroundjobs-app-base-url'

// Example: 'https://app-ilapanalytics-backgroundjobs-dev.azurewebsites.net'. You can find the URL by clicking browse from azure app service.

Release 2.3.0.0

Sending Completion event log to event hub after completion of import/revert

Card: #5679

Change Details

Added new parameters in the bicep parameter files. More details can be found on the document Configuring Event Hub message sending.

// Operation completion notifications
// Controls whether applications publish a notification to event hub when a report schedule import/revert is completed.
// Notes:
// - If you plan to enable this, configure the "eventhubConfig" block below.
// - If you plan to notify via HTTP callback, set "CallbackHostUrl" to your API host base URL.
param operationCompletionNotificationConfig = {
  // Enable or disable operation completion notifications (true|false)
  IsEnabled: false
  // Notification type: 
  //      1 = Report Schedule Id Only, 
  //      2 = Report Schedule Id With Activity Ids, 
  //      3 = Report Schedule Ids With Activity Fqdns
  NotificationType: 2
  // Optional: Base URL for callback endpoints (used when notification type 3 is selected)
  CallbackHostUrl: publicConfigurations.analyticsApiUrl
}

// Event Hub configuration (optional, mandatory if operation completion notifications are enabled above)
// Provide only if you plan to publish operation completion notifications to an Azure Event Hub.
// - NamespaceUrl: The fully qualified namespace host (e.g., "your-namespace.servicebus.windows.net").
// - EventhubName: The Event Hub name to which events will be emitted.
// Note: Ensure that the application has the necessary permissions to send events to the specified Event Hub.
param eventhubConfig = {
  NamespaceUrl: 'your-namespace.servicebus.windows.net'
  EventhubName: 'name-of-your-eventhub'
}

Significance

If you want to configure event hub notification for each import revert/completion fill up the parameter file values. If you don't want to enable messaging, ignore them.

Resource Impact

New Resource creation: NO Resource config change: Yes Impacted resource: Background job, Analytics API