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.

Hello brainCloud team,

We would like to better understand how billing/API Counts apply to operations triggered from the brainCloud Portal.

Our question is not limited to one specific feature. We are trying to clarify the general rule for Portal actions that execute backend operations, such as:

Refreshing or re-evaluating segments Refreshing promotions/pricing for users Running operations from API Explorer or S2S Explorer Triggering batch/user-processing jobs Other Portal buttons that may cause server-side processing

Could you please clarify:

Are backend operations triggered from the Portal counted toward billable API Counts or other usage metrics?

If yes, is the billing rule the same as calling the equivalent Client API, S2S API, or Cloud Code operation directly?

Are there Portal actions that are considered admin/configuration operations and are not billed as API Counts?

For operations that process many users or records, how is usage calculated?

Once per Portal action? Once per underlying API operation? Once per user/record processed? Or based on bulk-operation rules?

Where can we verify Portal-triggered usage in the brainCloud reports?

Is there a specific service/operation naming pattern we should look for?

Are scheduled/internal maintenance operations, such as automatic segment refreshes, billed differently from manually triggered Portal operations?

We are asking because we want to avoid unexpectedly increasing API usage or costs when using Portal features in production, especially for actions that may process many users.

Thank you!

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.

brainCloud developers have just release several playable builds of our famous examples! See our cool features in action. Find them at https://getbraincloud.com/demos for Windows, Mac, online and mobile.