Skip to content

Brief Connect v2.5.x New Dashboard Infrastructure Release Notes

Release date - 12th January, 2026 (Updated 4th May)

Supported package versions: >=2.5.6 and <2.6

This release introduces a new MongoDB-powered backend infrastructure for the Dashboard and Search pages, enabling near-instant record visibility. This infrastructure upgrade stream is separate from point-release notes and can be deployed with any 2.5.x Brief Connect application package.

New features

Dashboard powered by MongoDB

A new MongoDB-powered backend is available for the Dashboard and Search pages, providing near-instant visibility of record changes.

Key benefits:

  • Near-instant updates: Changes to records appear typically within seconds, instead of waiting for SharePoint Search to recrawl
  • Improved performance: Dedicated database infrastructure for search and filtering operations

Work with the E2 Support Team

Please complete this phase in collaboration with the E2 support team. Our team will guide you through each step and ensure a successful migration.

Change Window Required

Deployment requires a change window of several hours due to infrastructure changes and data migration. The change window begins when you start database migration as the database and ends when application is switched to new MongoDB database. Plan to perform this upgrade outside of core usage hours.

Maintenance mode must be enabled before migration started and remain active the whole deployment process.

Atlas prerequisites

MongoDB Atlas is the recommended primary database configuration. Ensure your Atlas organisation and OAuth service account (client ID/secret) are ready before starting deployment.

Alternative MongoDB options are available (Azure DocumentDB). Please contact the E2 support team if you need this option. Our team will guide you through alternative options, if available.

The following instructions apply to environments already running Brief Connect v2.4.x infrastructure with v.2.5.x application package.

Overview

Deployment consists of the following steps:

  1. Deploy MongoDB Infrastructure
  2. Enable Maintenance Mode and Migration Mode
  3. Run Data Migration
  4. Swap to MongoDB
  5. Update Power BI Models
  6. Verify Migration Success (admin verification while in maintenance mode)
  7. Disable Maintenance Mode
  8. Run Full Smoke Tests (includes rollback procedure if needed)

Maintenance mode must remain active from step 2 until step 7 is complete.

Step 1: Deploy Infrastructure

This step updates your existing Azure Resources release pipeline to deploy the current shared topology:

  • Main database: Atlas or AzureDocumentDb
  • Replica database: Azure SQL

Prerequisites

Before starting the infrastructure deployment:

  1. Confirm your Azure Subscription contains the resource type Microsoft.DocumentDB. If it doesn't, this resource type will need to be added.

  2. Ensure you have the MongoDB Atlas prerequisites in place:

  3. An Atlas organisation (direct in Atlas, or via the Azure Marketplace offer)
  4. An Atlas OAuth service account with Organisation Owner role
  5. The Atlas Organisation ID, plus the service account Client ID and Client Secret
  6. When Atlas organisation created, toggle off Require IP Access List for the Atlas Administration API network setting for it. (more details: Get Started with the Atlas Administration API: Require an IP Access List)

If you are provisioning Atlas via the Azure Marketplace SaaS offer, you may also need the Azure resource provider Microsoft.SaaS registered in your subscription.

  1. Create the Power BI connector Entra ID app registration:
  2. Name: [EnvPrefix] Brief Connect PBI Connection
  3. Single-tenant app registration with no redirect URI
  4. Create a client secret and store the secret value in a secure location for later Power BI setup steps

  5. Save the app Application (client) ID for infrastructure parameter generation (pbiApplicationClientId)

  6. Contact the E2 support team to request an updated Azure Resources repository containing:

  7. Updated Bicep templates
  8. Provisioning scripts (e.g. Scripts/ProvisionInfra.ps1)

Non-Standard Infrastructure

If your environment uses hardened infrastructure with VNets, private endpoints, or was deployed using alternative Infrastructure as Code tools (e.g., Terraform, Pulumi), please work directly with the E2 support team for tailored deployment support. The steps below apply to standard Brief Connect deployments only.

1.1 Update DevOps App Role Assignments

The deployment pipeline requires an additional roles. Update the Role Based Access Control Administrator role assignment for the "[EnvPrefix] Brief Connect DevOps" Entra ID app to include any missing roles.

  1. Open the Azure Resource Group for the related environment in Azure Portal
  2. Go to Access Control (IAM) -> Role assignments
  3. Find the existing Role Based Access Control Administrator assignment for "[EnvPrefix] Brief Connect DevOps"
  4. Edit the assignment to update the conditions:
  5. In the Conditions tab, click on + Select roles and principals
  6. Click Configure in the "Constrain roles" section
  7. Ensure the following roles are selected:
    • Storage Account Contributor
    • Key Vault Secrets User
    • Key Vault Secrets Officer (new)
  8. Save the assignment

1.2 Update Your Release Pipeline Variables

  1. Open Azure DevOps and click on "Library" left menu item
  2. Update Variable group with Environment/Stage name
  3. Create/Update required variables according to Admin Guide * Configuration Management * Application-Settings guide.
  4. Ensure pbiApplicationClientId is set to the Application (client) ID of [EnvPrefix] Brief Connect PBI Connection.
  5. If deploying with -MainMongoDbType Atlas, add MongoDB Atlas variables:
  6. AtlasOrganizationId (Atlas organisation ID)
  7. AtlasDevOpsAppId (Atlas OAuth service account client ID)
  8. AtlasDevOpsAppSecret (Atlas OAuth service account client secret; mark as secret and preferably source from Azure Key Vault)
  9. If deploying with -MainMongoDbType AzureDocumentDb, Atlas variables are not required.
  10. Save
  11. Open Azure DevOps and navigate to Pipelines -> Releases
  12. Open the Deploy Brief Connect Azure Resources release pipeline
  13. Click Edit
  14. Add next environment variables:
  15. Name: infrastructureRootDirectory (artifact-relative root folder; usually _AzureResources). Scope: Release

1.3 Update release pipeline steps

  • Open "Deploy Brief Connect Azure Resources" release pipeline. Click on "Edit" button.
  • In Stages section add a new Stage, select "Empty job" template.
  • Open stage tasks.
  • Delete all existing tasks from this stage.
  • Add new task. Select "PowerShell" task template. Set props to:
  • Display name: Bicep param File
  • Type: File Path
  • Script Path: $(System.DefaultWorkingDirectory)/$(infrastructureRootDirectory)/Scripts/Environments/Generate[EnvName]Params.ps1

  • Working Directory: $(System.DefaultWorkingDirectory)/$(infrastructureRootDirectory)/

  • Add new task. Select "Azure CLI" task template. Set props to:

  • Display name: Deploy Azure Resources
  • Azure Resource Manager connection: select previously created service connector
  • Script Type: PowerShell
  • Script Location: Script Path
  • Script Path: $(System.DefaultWorkingDirectory)/$(infrastructureRootDirectory)/Scripts/ProvisionInfra.ps1

  • Script Arguments:

    • Atlas topology: -MainMongoDbType Atlas -AtlasDevOpsAppSecret (ConvertTo-SecureString "$(AtlasDevOpsAppSecret)" -AsPlainText -Force)
    • Azure DocumentDB topology: -MainMongoDbType AzureDocumentDb

  • ErrorActionPreference: Stop

  • Working Directory: $(System.DefaultWorkingDirectory)/$(infrastructureRootDirectory)/
  • Access service principal details in script: checked

1.4 Update Infrastructure Parameters generation script

In the Azure Infrastructure repository, add or update an environment-specific wrapper script in /Scripts/Environments/Generate[EnvName]Params.ps1 to generate the parameter files consumed by the deployment pipeline.

Use next scripts as a starting point, but update them to emit the current parameter names.

  • Atlas Non-prod params script: /Scripts/Environments/deploymentParams.Atlas.nonProd.ps1
  • Atlas Prod params script: /Scripts/Environments/deploymentParams.Atlas.prod.ps1
  • Azure Document DB Non-prod params script: /Scripts/Environments/deploymentParams.AzureDocumentDb.nonProd.ps1

  • Azure Document DB Prod params script: /Scripts/Environments/deploymentParams.AzureDocumentDb.prod.ps1

  • Use the current scripts from infrastructure/Scripts/Environments as your baseline for the selected topology.

  • The generated files should include:
  • Bicep/parameters-1.bicepparam
  • Bicep/parameters-2.bicepparam
  • ProvisionMongoAtlas.parameters.json (Atlas topology only)

Bicep/parameters-1.bicepparam (for main-1.bicep)

Parameter Name Description Type Default Value
region The Azure region where the resources will be deployed. string (none)
deploymentNamesPrefix Prefix used in deployment resource names. string (none)
mainMongoDbType Main Mongo-compatible provider: Atlas or AzureDocumentDb. string (none)
userAssignedIdentityName The user-assigned managed identity used by the deployment. string (none)
keyVaultName The Azure Key Vault name. string (none)
mongoAtlasPasswordSecretName Key Vault secret name for the MongoDB Atlas admin password. string (none)
mongoAzDocumentDbPasswordSecretName Key Vault secret name for the Azure DocumentDB for MongoDB password. string (none)
mongoPasswordLength Length for newly generated passwords. int 32
mongoPasswordMinExistingLength Minimum length required to accept an existing secret without rotation. int 16
forceUpdateTag Force update tag for password generation scripts. string utcNow()

Bicep/parameters-2.bicepparam (for main-2.bicep)

Review and update these key parameters:

Parameter Name Description
serverAppRegistrationClientId Server App Registration application ID.
clientAppRegistrationClientId Client App Registration application ID.
pbiApplicationClientId Power BI reports connector app registration application ID ([EnvPrefix] Brief Connect PBI Connection).
appTestClientId Optional API test client app registration ID (if used in your environment).
region Azure deployment region.
deploymentNamesPrefix Prefix used in deployment resource names.
dataStorageRegion / dataDocumentDbMongoRegion Optional region overrides for storage and Azure DocumentDB for MongoDB data resources (defaults to region).
mainMongoDbType Chooses the operational database: Atlas or AzureDocumentDb.
existingApiAppServicePlanResourceId Optional existing API App Service Plan resource ID.
existingFunctionAppServicePlanResourceId Optional existing Function App Service Plan resource ID.
useApiAppServicePlanForFunctionApp Reuse the API App Service Plan for the Function App when appropriate.
apiAppServicePlan / apiServicePlanName API App Service Plan SKU and name if creating a new plan.
functionAppServicePlan / functionAppServicePlanName Function App plan SKU and name if creating a dedicated plan.
redisCacheSku / redisInstanceName Redis deployment settings.
userAssignedIdentityName Shared user-assigned managed identity name.
azureSqlAccessIdentityName User-assigned managed identity name used by apps to access Azure SQL via Microsoft Entra authentication.
apiAppName / functionAppName API Web App and Function App names.
keyVaultName Key Vault name.
logAnalyticsWorkspaceName / applicationInsightsName Monitoring resource names.
storageAccountWebName / storageAccountFuncName / storageAccountDataName Storage account names.
mongoAtlasPasswordSecretName Key Vault secret name for the Atlas password.
mongoAtlasConnectionStringSecretName Key Vault secret name for the Atlas connection string.
mongoAzDocumentDbClusterName Azure DocumentDB for MongoDB cluster name.
mongoAzDocumentDbAdminUsername Azure DocumentDB for MongoDB administrator username.
mongoAzDocumentDbPasswordSecretName Key Vault secret name for the Azure DocumentDB for MongoDB password.
mongoAzDocumentDbConnectionStringSecretName Key Vault secret name for the Azure DocumentDB for MongoDB connection string.
mongoAzDocumentDbServerVersion Azure DocumentDB for MongoDB server version.
mongoAzDocumentDbComputeTier Azure DocumentDB for MongoDB compute tier.
mongoAzDocumentDbStorageSizeGb Azure DocumentDB for MongoDB storage size.
mongoAzDocumentDbStorageType Azure DocumentDB for MongoDB storage type.
mongoAzDocumentDbShardCount Azure DocumentDB for MongoDB shard count.
mongoAzDocumentDbHighAvailabilityMode Azure DocumentDB for MongoDB high availability mode.
mongoAzDocumentDbPublicNetworkAccess Azure DocumentDB for MongoDB public network setting.
mongoAzDocumentDbAllowAllIPs Development-only "allow all" firewall toggle for Azure DocumentDB for MongoDB.
mongoAzDocumentDbAllowAzureServices Allow Azure services firewall rule for Azure DocumentDB for MongoDB.
azureSqlServerName Azure SQL logical server name.
azureSqlDatabaseName Azure SQL replica database name.
azureSqlConnectionStringSecretName Key Vault secret name for the Azure SQL replica connection string.
azureSqlDatabaseSkuName / azureSqlDatabaseSkuTier / azureSqlDatabaseSkuCapacity Azure SQL database SKU settings.
azureSqlPublicNetworkAccess Azure SQL public network setting.
azureSqlAllowAllIPs Development-only "allow all" firewall toggle for Azure SQL.
azureSqlAllowAzureServices Allow Azure services firewall rule for Azure SQL.
defaultLogsRetentionInDays Default application log retention.
auditLogsInteractiveRetentionInDays Interactive audit log retention.
auditLogsTotalRetentionInDays Total audit log retention.

Notes:

  • For object parameters (for example plan SKUs), see Azure documentation for required schema.
  • Parameters that appear in both .bicepparam files must still use matching values.
  • ProvisionInfra.ps1 uses its -MainMongoDbType argument and only calls ProvisionMongoAtlas.ps1 when -MainMongoDbType Atlas is used.

ProvisionMongoAtlas.parameters.json (for Atlas cluster provisioning)

This file configures the MongoDB Atlas cluster provisioned by ProvisionMongoAtlas.ps1.

Parameter Name Description
organizationId Atlas organisation ID.
projectName Atlas project name.
clusterName Atlas cluster name.
clusterType DEDICATED or FLEX.
cloudProvider Atlas cloud provider (AZURE, AWS, GCP).
regionName Atlas region code (for example AUSTRALIA_EAST).
instanceSizeName Atlas cluster tier (for example M10, M20).
electableNodeCount / readOnlyNodeCount / analyticsNodeCount Atlas node counts.
clientId Atlas OAuth service account client ID.
dbAdminUsername Atlas DB admin username.
keyVaultName Key Vault name used for secrets.
dbAdminPasswordSecretName Key Vault secret name containing Atlas DB admin password.
dbConnectionStringSecretName Key Vault secret name where the Atlas connection string is stored.
waitTimeoutMinutes Timeout (minutes) to wait for cluster readiness.
enableBackups Whether backups are enabled for dedicated clusters.
allowCreateProjectWhenMissing If true, create Atlas project when it does not exist.
allowAccessFromAnywhere If true, adds 0.0.0.0/0 to Atlas IP access list (development/testing only).
allowPrivateNetworkWithoutIpAccessList Use the approved private-network path without public Atlas IP allow-list entries.
ipAccessList Optional array of specific CIDR/IP access entries for Atlas when private networking is not used.

Notes:

  • Adjust regionName to match your Azure deployment region. Atlas uses uppercase underscore-separated region codes (e.g. US_EAST_2, UK_SOUTH).
  • organizationId and clientId are typically sourced from pipeline variables (AtlasOrganizationId and AtlasDevOpsAppId).
  • keyVaultName, dbAdminPasswordSecretName, and dbConnectionStringSecretName should align with the Bicep parameter files.
  • If your private-network Atlas path is approved, set allowPrivateNetworkWithoutIpAccessList = true.
  • If private-network path is not available, supply ipAccessList entries or use allowAccessFromAnywhere only for dev/test.

1.6 Run the Pipeline

  1. Save the pipeline
  2. Create a new release for your environment stage only
  3. Wait for the deployment to complete
  4. Verify MongoDB instances have been provisioned:
  5. In Azure Function Environment variables confirm the new connection string settings (e.g. TempMongoDb*) exist and resolved as valid KeyVault links

What this deploys

The pipeline deploys the selected main Mongo-compatible provider (Atlas or AzureDocumentDb), provisions the Azure SQL replica, and updates existing Azure resources (Function App, Key Vault, Storage Accounts, etc.) in place. Existing resources are updated, not recreated.

Azure DocumentDB for MongoDB post-deployment note

This note applies only when -MainMongoDbType AzureDocumentDb is used.

After close performance testing with Microsoft, we recommend a Microsoft-managed configuration step for Azure DocumentDB that must be enabled as part of provisioning to activate performance patch to increase cluster performance and prevent cluster degradation under Power BI data load. The patch is currently being deployed by Microsoft globally, but it's not guaranteed that it will be activated on the provisioned instance.

Replica and migration performance

Migration writes to the selected main Mongo-compatible database and, when enabled, to configured replication destinations. This can increase migration duration for large datasets.

For large environments, review temporary upsizing for the selected main database and Azure SQL replica during the migration window, then downscale after validation.

Performance patch for Azure Document DB instance

We do not recommend downscaling Azure Document DB instance until the patch is applied, or further confirmation from Microsoft that the patch is deployed globally across all Azure Document DB instances in Azure Cloud.

Step 2: Enable Maintenance Mode and Migration Mode

Before migrating to MongoDB, place your Brief Connect environment into maintenance mode to prevent data loss during the migration.

Follow the steps in Maintenance Mode to enable maintenance mode:

  1. Open the Function App for the environment
  2. Go to Configuration -> Application settings
  3. Add or update next settings:
  4. MAINTENANCE_MODE: true
  5. SkipAutoApplySharePointFieldsOnSaveConfiguration: true
  6. MigrationBatchSize:500
  7. FeatureFlags__MongoDbWriteReplicationEnabled: true
  8. FeatureFlags__MongoDbMigrationWriteReplicationEnabled: true
  9. FeatureFlags__MongoDbSqlServerWriteReplicationEnabled: true
  10. Remove FeatureFlags__MongoDbSecondaryWriteReplicationEnabled setting if present.
  11. Rename TempMongoDbConnectionString setting to MongoDbMigrationConnectionString without changing the value.
  12. Rename TempMongoDbPassword setting to MongoDbPassword without changing the value.
  13. Save changes and allow the app to restart

Verify maintenance mode is active:

  • Regular users should see a maintenance message and cannot access the application
  • System Administrators can still access the application with a maintenance banner visible
  • System Administrators can see "Database Migration" button in the command bar in Admin Panel (https://[WEB_APP_URL]/#/adminPanel)

Do not proceed until maintenance mode is confirmed active

Proceeding without maintenance mode enabled may result in data loss during migration.

Maintenance mode restrictions

Only System Administrators have access to the system in Maintenance Mode. All user accounts that planned to be used for testing with maintenance mode enabled must be added to System Administrators.

Step 3: Prepare and Run Data Migration

Brief Connect includes a built-in migration tool in the Admin Panel to migrate data from Azure Storage to MongoDB.

Pre-fill Config Replication tables with data

  1. Log into the Brief Connect environment as a System Administrator
  2. Navigate to the Admin Panel (https://[WEB_APP_URL]/#/adminPanel)
  3. In the dropdown list of configurations find and select Active configuration
  4. In the command bar, click Save and wait until the action is completed.

Open the Data Migration panel

  1. Log into the Brief Connect environment as a System Administrator
  2. Navigate to the Admin Panel (https://[WEB_APP_URL]/#/adminPanel)
  3. In the command bar, click Database Migration

Note

The "Database Migration" button is only visible when the required migration environment variables are configured.

Note

Validate all items in Migration checks are green and checked.

Start the migration

  1. In the Selection Panel, select the tables and blob containers to migrate

  2. All tables and containers should be selected

  3. Click the Start button

  4. Review the confirmation dialog showing the number of items to migrate
  5. Click Start to begin the migration

Monitor migration progress

The Data Migration panel displays real-time progress:

  • Migration Summary Card: Shows the current run ID, elapsed time, and overall state
  • Progress Display: Shows tables completed, in progress, and failed, as well as total rows migrated
  • Diagnostics Panel: Shows connection status, performance metrics, and any warnings

The panel auto-refreshes during migration. You can also click Refresh to manually update the status.

Tip

Click Show Detailed Progress to view per-table migration metrics.

Wait for completion

The migration is complete when:

  • All tables show as "Completed" in the progress display
  • All blob containers show as "Completed"
  • The overall migration state shows "Completed"

If any items fail, review the error details in the Diagnostics Panel before proceeding.

Step 4: Swap to MongoDB

  1. Open the Function App for the environment
  2. Stop the application
  3. Go to Configuration -> Application settings
  4. Rename MongoDbMigrationConnectionString setting to MongoDbConnectionString without changing the value.
  5. Confirm MongoDbPassword is present and still points to the same Key Vault secret.
  6. Delete FeatureFlags__MongoDbMigrationWriteReplicationEnabled.
  7. Delete or revert SkipAutoApplySharePointFieldsOnSaveConfiguration to pre-migration value.
  8. Save changes
  9. Open the API Web App for the environment
  10. Stop the application
  11. Go to Configuration -> Application settings
  12. Rename TempMongoDbConnectionString setting to MongoDbConnectionString without changing the value.
  13. Rename TempMongoDbPassword setting to MongoDbPassword without changing the value.
  14. Save changes
  15. Go to Redis Cache instance and Flush all data in Cache
  16. Go back to the Function App for the environment and start it.
  17. Go to the API Web App for the environment and start it.

Step 5: Update Power BI Models

After the data migration is complete and the app is swapped to MongoDB, the Power BI models need to be updated to connect to the new MongoDB data source.

E2 Support Team Responsibility

The E2 support team will prepare updated Power BI models in advance of your scheduled deployment and provide support during the upgrade to complete this step. No action is required from your team * the E2 support team will handle the Power BI model update.

Reporting data source note

The current shared infrastructure provisions Azure SQL as the reporting replica (MongoDbReplicationAzureSqlConnectionString). Power BI model updates should be aligned to that reporting topology for your environment.

The Power BI connector app registration ([EnvPrefix] Brief Connect PBI Connection) created during infrastructure preparation is used for this setup. Keep its client secret in secure storage so it can be applied during the Power BI report configuration process.

If your environment uses a custom reporting path (for example Atlas MongoDB), coordinate with the E2 support team for model-specific guidance.

Step 6: Verify Migration Success

Verification is split into two phases: system admin verification while maintenance mode is active, and full smoke tests after maintenance mode is disabled.

Check migration tool status

  1. In the Data Migration panel, confirm the migration state shows Completed
  2. Review the Diagnostics Panel for any errors or warnings
  3. Click Download Report to download a migration report for your records
  4. Confirm no tables or containers show a "Failed" state

If any items failed, work with the E2 support team to resolve the issues before proceeding.

Run admin verification (while in maintenance mode)

While maintenance mode is active, System Administrators can perform initial verification to confirm the migration was successful.

Test Expected Result
Log in as a System Administrator Dashboard loads successfully
Open the Admin Panel Admin Panel loads with all configuration options available
Open an existing record Record opens and displays all metadata correctly
View the Documents tab on a record All documents are listed and can be opened
View the Activity Log on a record Activity history is displayed correctly
View the People and Roles tab All role assignments are displayed correctly
Search for a record using the search box Search returns expected results
Generate a PDF Pack for a record PDF Pack generates successfully

If any of these tests fail, use the rollback procedure below before disabling maintenance mode.

Step 7: Disable Maintenance Mode

Once admin verification is complete:

  1. Open the Function App for the environment
  2. Go to Configuration -> Application settings
  3. Set MAINTENANCE_MODE to false (or remove the setting entirely)
  4. Save changes and allow the app to restart
  5. Verify that users can access the application normally

Step 8: Run Full Smoke Tests

After maintenance mode is disabled, run the full smoke tests to verify Brief Connect functions correctly for all users.

Be prepared to rollback

If critical issues are discovered during smoke tests, you may need to re-enable maintenance mode and execute the rollback procedure.

Configuration and access

Test Expected Result
Log in as a regular user Dashboard loads successfully with appropriate records visible
As a proxy user, switch to view another user's dashboard Proxy user can see the assigned user's records

Permissions

Test Expected Result
As a regular user, attempt to open a record you have access to Record opens with appropriate edit/view permissions
As a regular user, attempt to open a record you do not have access to Access is denied or record is not visible

Core functionality

Test Expected Result
Apply filters to the dashboard Filters work correctly and display expected records
Change columns visible in the dashboard Column changes are saved and displayed
Export records to Excel Excel export generates successfully
Create or modify a record Confirm changes appear on the Dashboard within seconds (not minutes)

For a comprehensive list of smoke tests, see Basic testing of Brief Connect.

Run customer-specific verification tests

Prepare your verification tests in advance

We recommend preparing a list of customer-specific verification tests before the migration window. This ensures you can quickly verify critical functionality without extending the change window.

In addition to the standard smoke tests above, you should verify any functionality specific to your Brief Connect configuration:

  • Custom workflows: Test that your configured workflows behave as expected
  • Record types and subtypes: Verify records of each type can be opened and edited
  • Custom fields and classifications: Confirm custom field values are displayed correctly
  • Integrations: Test any integrations with external systems (e.g., webhooks, APIs)
  • Reporting: Verify any reporting or Power BI connections function correctly

Document the results of your verification tests.

Rollback procedure

If critical issues are discovered and cannot be resolved, you can roll back to the previous configuration.

Rollback will discard migrated data

Rolling back reverts the environment to use Azure Table Storage. Any data written to MongoDB after the swap will not be available.

Swap Application to Table Storage

  1. Swap Application to Table Storage:
  2. Open the API Web App for the environment
  3. Stop the application
  4. Go to Configuration -> Application settings
  5. Rename MongoDbConnectionString setting to TempMongoDbConnectionString without changing the value.
  6. Rename MongoDbPassword setting to TempMongoDbPassword without changing the value.
  7. Save changes
  8. Open the Function App for the environment
  9. Stop Function App
  10. Go to Configuration -> Application settings
  11. Rename MongoDbConnectionString setting to TempMongoDbConnectionString without changing the value.
  12. Rename MongoDbPassword setting to TempMongoDbPassword without changing the value.
  13. Save changes
  14. Go to Redis Cache instance and Flush all data in Cache
  15. Go back to the Function App for the environment and start it.
  16. Go back to the API Web App for the environment and start it.

Revert Power BI models to the previous configuration:

E2 Support Team Responsibility

The E2 support team will handle reverting the Power BI models to the previous Azure Table Storage configuration as part of the rollback process.

Contact the E2 support team if you need assistance with the rollback procedure.

Provide feedback

As this feature is in beta, we welcome all feedback on your experience:

  • Report any issues with filtering, sorting, or search results to Brief Connect support
  • Note any performance improvements or concerns
  • Share observations about how the new behaviour compares to the previous SharePoint Search-based approach