For the complete documentation index, see llms.txt. This page is also available as Markdown.

Global Settings (v1.6.30) - Monthly Release Notes

Release Details - Global Settings - v1.6.30 - September 11, 2026

For Salesforce administrators and IT teams responsible for managing Flosum Cloud Apps tenant configuration, organizations, users, and roles.

Release Type

  • Monthly

  • Applies to Flosum-hosted and self-hosted

Prerequisites

  • A registered and configured Flosum Cloud Apps tenant

  • Appropriate Flosum user permissions (SystemAdministrator or equivalent)

Summary

This article documents the monthly release for Global Settings (v1.6.30). This release updates token refresh behavior for connected Salesforce orgs so that a refreshed Sandbox can be re-authenticated in place. Previously, a Sandbox refresh assigned a new Salesforce Org ID, which meant the org failed validation on Update Token and had to be reconnected from scratch. Because a connected org is shared across the Flosum Cloud Apps, a warning now explains what happens to historical data before you authenticate with a different Salesforce organization.

Update Token for Refreshed Sandbox

What Changed

Token refresh behavior for connected Salesforce orgs has been updated to support Sandbox refreshes.

For Production and Development orgs, the behavior is unchanged. When you click Update Token, the system validates that the Salesforce Org ID matches the currently connected org. If it does not match, the token is not refreshed, and an error explains that a Production or Development organization cannot be refreshed with a different Salesforce Org ID.

For Sandbox orgs, re-authentication with a different Salesforce Org ID is now allowed since a new Org ID is expected after a Sandbox refresh. If you authenticate with a different Org ID, the org record is updated to match.

Why It Was Done

Refreshing a token previously required the Salesforce Org ID to match the org that was originally connected. A Sandbox refresh assigns a new Org ID, so the connected org could not be re-authenticated and had to be removed and reconnected from scratch.

What You Will Notice

A connected org is shared across DevOps, Backup & Archive, Data Migrator, and Audit & Compliance, so authenticating with a different Salesforce organization can affect data in more than one app. A warning modal now appears before you are redirected to Salesforce, letting you know that data loss is possible in some of those apps.

Effect on Historical Data

Refreshing a Sandbox org with a different Salesforce Org ID impacts each app as follows.

App
Effect on historical data

DevOps

No data is affected. Job history and previously retrieved components remain visible, and the next retrieval runs as a full retrieval, which may take longer than usual.

Backup & Archive

All backup history and related data for the org is deleted, and the org is treated as a new organization going forward. However, configured templates and schedules are preserved and transferred to the new org, so backups can continue without setting up the configuration again.

Data Migrator

All migration history and ID mappings for the org are deleted, and the org is treated as a new organization going forward.

Audit & Compliance

All history and related historical data for the org are deleted, and the org is treated as a new organization going forward.

From a data standpoint, an org that returns with a different Salesforce Org ID is a new organization. Any backups, migrations, or audit data collected under the old Org ID no longer correspond to it. That historical data is removed in the apps where keeping it would mix records from what are now two different orgs.

Last updated

Was this helpful?