I’ll forward your request to the team for review...

Yes, the behavior you’re describing is expected with the current implementation. RefreshMySegments, RefreshPromotions, and login will not attach the promotion to users who are already in the segment, because the system is designed to only grant automated promotions when the user enters the segment (i.e., when it shows up in enteredIds). The fact that Reset Segments or Re‑evaluate All Segments fixes it is also expected, because those actions force the user back through the segment‑entry logic.

We’re working on a fix to make this smoother. The practical effect going forward will be that, when a new automated promotion is created or attached to an existing segment, the next segment refresh will automatically apply it to all currently‑eligible users in the background, without you needing to reset or re‑evaluate segments manually. This should make the behavior more predictable, especially when you have a large number of existing users already in that segment.

Our automated promotions were designed to pull members of a segment into a promotion, which is why they can trigger notifications. When an automated promotion fires for a user, they can be notified, and that notification is intended to draw them back into the game. So startTime is effectively the wall‑clock time when the batch job processes that user, not when the user logs in. A user who never logs in will have their promotion silently expire in the background.

I’ve forwarded your request to our team to see if we can look at adding a flag that lets developers specify that an automated promotion should only trigger on login, which would likely align well with the kind of “starter‑package” use case you described.

Thanks for the suggestion and the explanation of the workflow benefit. I’ll bring this request to our team for review and follow up here...

@noah The team is working on this, and we’ll share any progress here once there’s something concrete to report.

Hi, thanks for the detailed report. At the moment, there isn’t a per-promotion exclusion toggle for deployments; the currently recommended way is to keep Preserve Products+Pricing & Promotions in the target environment. Your request for selective promotion exclusion makes sense. I’ll pass this along as a feature request for the team to consider.

Hi @gyutaelee,

1. For one-way follow: brainCloud doesn’t have a built-in one-way “follow” graph, so you’ll need to implement your own follower/following system using one of the user data mechanisms (e.g. global or entity data) to track who follows whom. This keeps it independent of the Friends API, which is designed around mutual relationships. GetPresenceOfUsers() works with any valid profile IDs, it does not require a Friend relationship between the players to return presence info.

2. For the referral rewards question: I’m going to forward this to our team to review the best server-side approach for triggering rewards for both the referrer and referee once the milestone (like reaching level 3) is reached.

Thanks for the detailed explanation of your use cases.

Did you call CachePurchasePayloadContext() with the promotionId before calling verifyPurchase() ? That’s the piece that passes the promotion ID through and should trigger an increase in the maxPurchases counter.

If your promotion is for a cash product and the promotional product is set to Not for Sale, you need to complete the flow by calling verifyPurchase in brainCloud with the purchasePayload from the store.

As long as that payload contains the promotionId you received from GetEligiblePromotions, the promotion will be correctly attributed and the server-side flow will reach the counter increment logic.

Also make sure you set maxPurchases on the promotion configuration page so the system knows when to stop returning that promotion for the user.

As for your feature request to allow promotions without requiring a discount, I will forward this to our team for review.

Hi, GetEligiblePromotions is snapshot-driven, not fully real-time. It relies on a cached promotion-eligibility snapshot stored on the UserProfile, which is only refreshed at specific points.

• GetEligiblePromotions does not reevaluate Automated Promotion segment conditions (like experienceLevel >= 4) against the latest player state on every call. Instead, it uses the last calculated promotion snapshot that was written to the UserProfile. That snapshot is normally refreshed at login, or when you explicitly call the RefreshPromotions CAPI.

• Because of that, the “delay” you are seeing is essentially “until the next snapshot refresh.” In your current flow, that refresh happens on the next login, which is why restarting the app makes the promotion suddenly appear. There is no fixed time-based delay; it is purely tied to when the snapshot is updated.

• To make the promotion available immediately mid-session, add an explicit refresh step to your flow. After your CloudCode call to incrementExperiencePoints (once the player has reached level 4), call RefreshPromotions on the client, and then call GetEligiblePromotions. That will force an immediate refresh of the promotion snapshot so the level-4 promotion is returned without requiring a new session.

API details for RefreshPromotions:
https://docs.braincloudservers.com/api/capi/appstore/refreshpromotions.

Thanks for the suggestions, we will look into 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.

No, RemovePlayerScore() does NOT handle reward reversals. You need to handle that manually. Also note that if the leaderboard is configured for a tournament, it will throw an exception and refuse to remove the score. Call LeaveTournament() for a tournament-based leaderboard, but it does not reverse rewards either.

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

Also, there’s an option on the deployment page to exclude push notification certificates—“Do Not Overwrite Push Notification Certificates.” Did you enable this option during your deployment?

FYI, you can use the Report service APIs to retrieve this data: https://docs.braincloudservers.com/api/capi/report/

You can safely delete and update these push certificates after deployment if they’re no longer needed in another environment.

We’re planning some major changes to our push notification system, it’s more than just adding a few titles and content fields to the templates. It's not a near-term, stay tuned!

We will review it.