@Paul-Winterhalder
Thank you! Supporting this feature would be a tremendous help in maintaining the stability of our live service.

Could you please leave a comment once a decision is made on how this will be handled?

As soon as the feature is supported, we will make sure to implement it into our live service immediately.

Hello @Paul-Winterhalder

I apologize for the repeated questions, but I am following up on this again because our live service experiences a temporary outage every time we attempt to deploy only data to our production environment.

Even when the operation is strictly intended to deploy only customEntities, as shown in the payload below, the temporary "App is disabled" state still occurs:

{
...
"allowLiveUpdate": true,
"components": {
"meta": true,
"scripts": false,
"files": false,
"customEntities": true,
"legacyFiles": false
},
"options": {
"meta": {
"excludes": {
"itemCatalog": true,
"productPricing": false,
"pushCertificates": true,
"integrations": true,
"myServers": true,
"lobbies": true,
"leaderboardsTournaments": true,
"independentLeaderboards": true,
"divisionSetConfigsOverride": true,
"migratableGlobalEntities": true,
"migratableCustomEntities": false,
"selfServiceBranding": true
}
}
}
}

We would like to know the exact scope of deployment conditions where the "App is disabled" state does not occur. While we understand that it might not be possible to prevent the disabled state across all deployment processes, we would like to at least define and narrow down the conditions.

We are hoping there is a way to migrate at least customEntities between environments without triggering the app disabled state. It would be even better if there were a way to specify and migrate each collection individually.

@moondory77 brainCloud 6.0 is releasing this month (June 2026). I am really excited about the headline features for it, hope you love it!

Q1: The removed player is completely excluded from reward calculation, so if the deletion happens before the job runs, that player is never iterated over and receives no rank or rewards.
Q2: Yes, the modified score will be used. The job always reads live state. Note that whether the score actually gets modified depends on the leaderboard type (e.g., for the LOW_VALUE type, only updates if the new score is less than the existing)
Q3: No backfilling, the next joiner goes to the latest instance, not the freed spot in ^2. No loop over earlier instances (^1, ^2) ever happens. The next joiner goes to ^3 (or ^4 if ^3 is full). The freed spot in ^2 stays empty permanently.

@moondory77 - why would you need/want to update a tournament in progress?

We consider the tournament to be a contract between the player and the game dev. You enter this tournament. You have <X> hours to compete. And you can win <Y> in prizes.

Changing the rules half-way through the tournament seems unfair? You are changing the duration? The prizes? These are both things that the player did not agree to.

Anyway - that was the assumption of the system - and it's why once a tournament is started any changes you make to the tournament get queued up for the NEXT tournament cycle, not the current one.

That said - divisions are even more complicated - as even if we wanted to there would be potentially thousands of records to update to make the change.

I need to better understand your use case to consider this request.

Paul.

Hi @noah ,

This support has already been added to the Builder API. The new options can be specified when importing app configuration data OR when deploying an app.

When importing app configuration data, there is a new optional 'preserveDivisionSetConfigsOverride' parameter that can be specified. If not specified, it will default to whatever the value is for 'preserveLeaderboardTournamentConfigs'.

When deploying from one app to another, there is a new optional 'divisionSetConfigOverrides' parameter that can be specified in the 'options.meta.excludes' section. If not specified, it will default to whatever the value is for 'leaderboardsTournaments'.

I will endeavour to get our Builder API docs updated with these new parameters. Let us know if you encounter any issues using them.

Thanks!
Greg

Yes, the link provided in that article is automatically updated. For your reference, here is the actual embedded link behind it:
https://portalx.braincloudservers.com/dts/cloudcode_dts_files.zip