Hello, thank you for the clarification.

Based on your answer, I understand the following:

GetSocialLeaderboard returns the full set of friends + self + pacers, and there is no hidden max result limit. GetMultiSocialLeaderboard can return only the Top N results using leaderboardResultCount, after social filtering and score sorting. However, there is no page/offset-based pagination API for social leaderboards like GetGlobalLeaderboardPage. leaderboardResultCount is limited by the app property maxMultipleLeaderboardScoreLimit, whose default value is 10. Friend IDs are stored as an array in the UserProfile, so very large friend lists may affect read/write performance.

I have two follow-up questions:

How can we increase the maxMultipleLeaderboardScoreLimit value?
Is this app property something we can change directly in the Console, or does it require a request to brainCloud Support?
If a Support request is required, could you let us know what information we need to provide and whether there is a recommended maximum value?

We are planning to build a friends-based social leaderboard for up to around 10,000 friends.
In this case, is the recommended approach to call GetSocialLeaderboard, retrieve the full friends leaderboard, and then handle paging on the client/server side?
Or, at this scale, would you recommend using a separate Custom Entity, Cloud Code, external ranking cache, or another leaderboard structure instead?

To clarify, our requirement is not just to fetch the Top 50 users.
We want to continuously page through a friends-based leaderboard like this:

rank 1–50 rank 51–100 rank 101–150 ...

Based on your previous answer, I understand that social leaderboard pagination is currently not supported.
Could you please advise on the recommended architecture or best practice for implementing this kind of UX with a friends leaderboard of up to 10,000 users?

Thank you.

Added the additional details to 13660

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.