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.

Thank you!

Hi @jongdae.won , brainCloud 6.0.1 has been deployed. The Campaign Analytics feature - as well as the APIs for updating the campaign and scenario JSON, are now live! Paul.

Unfortunately, our notification templating system is very simple and currently only supports simple text notifications. It does not currently push a template id. We do have plans to revamp the system on our "to-do" list - but it has not been scheduled yet. We recommend folks use the "raw" template calls - they give devs the most control over what gets sent to the various notification systems. Paul.

Hi, Apologies for the slow response. We don't have any calls that could directly handle a "file" of profileIds. We do have a few "toBatch" calls that are callable from S2S though - so you could probably have an offboard system make those calls - and call braincloud to send the notifications in batches. Where are these profileIds coming from? An offboard analytics system of some sort? To answer your questions: We are planning a revamp of our notifications system and it's APIs. I'll add this conversation so that it will be considered as we're planning that. As mentioned above, using one of the "Batch" calls would make the most sense - and keep your API counts reasonable There's an API call to call the SendRichPushNotificationWithParams, plus a second api call for the sending the push notification itself. So that would be <numReceivers> x 2 for API costs. Less if called from within a script. But the *Batch() calls would be Substitutions and custom metadata/custom data - the current APIs don't - so you'd probably need to handle those client side. Are the substitutions highly personal - like player's name? I hope that helps to clarify things, Paul.

Hi, API calls triggered by the backend DO count towards API usage -- so using the API Explorer to make calls do get counted as API calls. So - if you use API explorer to trigger a user batch job that then runs scripts on all of your users - yes, yes that does get counted as API calls. Also - uploads of files to and from the portal do get counted in the file transfer costs. Other normal portal operations - like viewing users, viewing logs, editing scripts, etc - do NOT get charged in API counts. So to clarify - using the API explorer to view a leaderboard is going to add an API count - but using the leaderboard viewer at App > Global > Leaderboards > Leaderboards does not! To be honest - in general - usaging of the portal is negligible. You won't really notice the usage added by what you're doing in the API explorer or working through the portal. It's only if you use the API Explorer to kick off a large job that API counts would be noticable <-- as you'd expect! I hope that helps! Paul.

Thank you for your detailed and courteous response. It fully answered my questions.

Ah - great to hear @jongdae-won . Thanks for the update!

@Paul-Winterhalder Thank you!

My question has been answered. Thank you for your kind and detailed explanations every time.

Thank you for your helpful response. Unfortunately, since this feature does not align with the specifications we are currently planning, we have decided not to use it for the time being. We will contact you again if we need it in the future. Thank you.

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

Thank you for your response. We used the automated promotion without making any changes to it. However, we confirmed that it works correctly in the production app. It seems that the issue may have been temporary, or that there was something incorrect in our configuration at the time. If the issue occurs again, we will contact you again with more details. Thank you for your help.

Thank you for your kind response.

@gyutaelee I will investigate the Per Promotion Deployment option you requested. As I was working on this I thought there may be a workaround for you that you would like. This could work for your team with minimal effort and on your current version of brainCloud portal. My solution hides the promotion so that only users you flag as TESTERS will see it. This would let your PROD testers gain the benefit of the no-ads promotion without disrupting your monetization. Within Automatic Promotions, there is the option to Target members of any of these segments. [image: 1779474011850-cb1f4861-16f8-432a-bb22-4b71dc0b0ce1-image.png] Within Scheduled Promotions, there is the option to Offer this promo to: Only users in: [image: 1779472315918-2a5f3a28-91ba-4f2c-bb1c-5a2c04ead1e5-image.png] Advancing to App > Design > Segmentation > Segments we can create a segment that filters to players that are flagged as Testers. [image: 1779472502119-59f8d7bc-3640-450f-ab67-086af9b8acdd-image.png] Now, segments need to have at least one more criteria, so let's choose something like has logged in at least 1 time. [image: 1779472567232-d86e5f6d-ded8-4c7e-ab26-1c07f9813f0e-image.png] Save this Segment IMPORTANT! Add the segment to your Promotion This will limit the promo to only eligible users. Noone else sees it! [image: 1779474059997-7aca6582-cff3-4469-ae98-6339b341ba06-image.png] Next we will need to flag some users as Testers. For a DEV app, the easiest way to do this is to go to the User Browser, RECENTLY ACTIVE and pick players (your testers) with recent activity. [image: 1779473025782-ec366981-f641-4833-87f2-64798766555c-image.png] GO TO USER to bring up their user summary and check the IsTester checkbox. [image: 1779473098382-d1094afd-ca63-4ce6-8070-477c879fb1d4-image.png] Testers get a special icon [image: 1779473149842-e02b71bc-db5b-4127-a6a7-1528697aee6f-image.png] Next, we will return to Segments. Segments are automatically processed overnight, but you can Refresh Segments immediately with the REFRESH SEGMENTS button. Please note: refreshing segments processes every player so this process can take a while and preferably left to low-traffic times of day. [image: 1779472658705-e306d8e0-553d-475c-a780-43fbed29a271-image.png] After processing completes, we can check the cohort of testers by returning to the User Browser choosing BROWSE, and Browse Within A Segment. [image: 1779473489489-43a330f6-e572-4b0b-a8ca-c0d631e63240-image.png] These are my Testers, so everything worked. [image: 1779473539999-a8b56bbb-536c-447b-9e7d-a8d8236ff165-image.png] Since only testers are eligible for the promotion, you are free to deploy it to PROD without affecting your monetization. And the PROD Testers you select will be able to gain the workflow benefit of no ads. Could you let me know if this solution solves your problem? Let me know if you have any questions, Regards John -Design

Hi @gyutaelee I am bringing this to the dev team for further discussion. thank you for suggesting it.

Thank you for your helpful response. I will proceed as you suggested.

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

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.

The aggregation that counts new users is not real time, it runs at hourly granularity, so there can be a delay before the stats reflect the actual number of users. At the time of checking again, the numbers had updated as follows [image: 1776208016406-9e98453d-669c-427b-8cce-1152267fd864-image.png]