@Ali-Raza could you let me know your Team ID and the AppIDs you would like this increase for? thanks

Hi @Omar-Alzayed When apps have millions of users, browsing all users can have poor performance.
If you have a smaller number of users, it can be useful.
There is a way to create a segment so you can browse all your users.

Go to App > Design > Segmentation > Segments
Create NEW SEGMENT
656b32ad-94e5-4314-a79a-f7a8cf201536-image.png

There's a couple different ways you can return ALL users. The one I like is to use the criteria A/B Testing ID 0-99 which will return all your users.

28d945d5-1fb5-4606-b8be-c220291a763e-image.png
9a146d95-9e93-4944-a695-68844bb4fd53-image.png

Looks something like this:
e37eea64-557d-4eca-91d0-2dff0699479e-image.png

Segments are automatically run nightly at around 3am but you can press REFRESH SEGMENTS to run it immediately.

Note that the refresh will take time to complete according to your user count, you may wish to do this during low player traffic.

In the case of this particular segment, I believe the Refresh will need to run TWICE to capture all your users. (I think the AB code needs to be initialized in the first pass, and then it can be read in the second pass, capturing all of your users.)

Please take care not to launch the second Refresh before the first one completes. (If you have 10,000+ players then wait about 30 minutes or so)

c4785150-2e0a-489d-8a47-d330c7c09d80-image.png

Once you have players in the Segment, you can browse by Segments. Go to
User > User Browser

Choose BROWSE, then check the box to browse within a segment. Choose the segment.
fd6b9af5-b4b1-47d1-bc05-d43180e8e621-image.png

Reminder, once you have millions of users, this can be very slow. But you can create more refined Segments to filter to just the interesting users, such as Has Bought Something, Is at Least Level 10, and so on.

Segments allow compound conditions so you can really filter to exactly who you want.

Segments can also be used to target Sales and Promotions to specific player groups. For example you could create a $0.99 one-time, loss leader promo that is available to only those players who have not bought anything in your game yet. It's a very powerful system.

Could you let me know if this helped you?
Thanks
John

Yes, your current design matches the recommended pattern: Redemption Code is a one-way gate for “has this user consumed this shared code?”, while your claim entity is the authoritative state machine for fulfillment, retries, and audit (Redeeming → Redeemed → Granting → Granted / GrantFailed), with Granted as the idempotency guard for duplicate grants. The main thing to watch is call ordering: it’s preferable to write the claim to Redeeming first as an intent record, then call redeemCode(), so any Redeeming with no further progress is detectable and recoverable by your server without depending on the Redemption Code record.

Consolidating the brainCloud-side claim init + redemption into a single CloudCode script is a good fit, provided the script is strictly idempotent and fulfillment stays in your server pipeline. The script should read the claim state, upsert to Redeeming if needed, call redeemCode() (skipping if already Redeemed or beyond), update the claim to Redeemed, and return rich state (claimState, claimId, rewardDataId) so your server can then perform fulfillment and issue a final Granted / GrantFailed update. This gives you a clean two-call pattern from the server to brainCloud on the happy path, while the script’s state checks make retries safe even though CloudCode itself is not transactional.

Hi @moondory77 ,

Yes, you observed correctly.

During the data migration portion of the deployment (which occurs after the system has done a bunch of validation and consistency checks), the system temporarily disables your app to do the actual data migration.

This is to protect the data integrity of your app - as your app's metadata, reference data and cloud code scripts are all changing underneath it. So we disable the app, make the changes, and re-enable the app.

All of this normally takes just a few seconds - though it does depend upon the number of changes being made.

I hope that helps to clarify things!

Paul.

Submitted case 14062, case 13344

Thanks @noah I will keep you updated

hi. @Paul-Winterhalder
yes, permissions to call specific scripts and access control for Services and Operations regarding the generally provided functions are required.
For example, there may be management tools that call specific scripts and use certain functions (CloudData...),
and there may be administrators who only manage items.
If possible, each API Key should be a function with permissions tailored to the situation.

Let me give you an example. A company utilizes a mix of office and remote work. While the internal network can be protected to some extent by IP ranges, it is difficult to identify specific IPs because multiple operators work from home. Therefore, it is currently somewhat difficult to handle this situation using only IPs.

@JasonL At the time I reported this, that field was locked too, so it couldn't be edited — but I've now confirmed that it's editable.

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.

@Paul-Winterhalder Thank you!

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

Added case 13932

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.

The SDK is just a plain C# source library you can drop into any .NET project (not Unity-only). You can find usage examples and the source in our GitHub repositories at https://github.com/getbraincloud.

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

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

Added the additional details to 13660

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.

cb1f4861-16f8-432a-bb22-4b71dc0b0ce1-image.png

Within Scheduled Promotions, there is the option to Offer this promo to: Only users in:

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.

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.

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!
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.

ec366981-f641-4833-87f2-64798766555c-image.png

GO TO USER to bring up their user summary and check the IsTester checkbox.
d1094afd-ca63-4ce6-8070-477c879fb1d4-image.png

Testers get a special icon
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.

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.

43a330f6-e572-4b0b-a8ca-c0d631e63240-image.png

These are my Testers, so everything worked.
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