Idea

Account creation is done via a call from the client to the service. Calls to Cloud Script require a signed-in user to already exist, as the only Client API calls that don't require a Session Ticket are the login calls themselves.

Could you describe the scenario you have in mind in more detail? 

I am using SharedGroupData as clan (team  of players) management,Clan has some characteristics same of player, like money(coin), equipment warehouse, so  when i am creating a clan, i want to  create a virtual(fake) player at same time.

We do plan to add some Clan/Guild specific functionality in a future update, but yes, the best way to manage this right now would be using Shared Group Data. The way you would do this is by storing information on the officer levels in the guild as one data point, and any inventory items or virtual currencies the guild "bank" has. For moving things into and out of that "bank", you would use a single Cloud Script for the full transaction process, to minimize the change of collision between players (bear in mind that it's technically possible for two players with access to the same clan to issue a command to get an item at exactly the same time).

Creating a bogus player account doesn't really get you any significant advantage over just using Shared Group Data, and it would cause some "pollution" of your game data, potentially (you could set a User Internal Data value, to indicate that the user should be ignored in your data analysis, but that would only be effective for custom analyses that you do).

Shared data is a mess indeed and other limitations are problematic to implement clans properly (can't make clan leaderboards cleanly, can't manage the clan shared data cleanly, etc).

We are now forced to consider to switch to a custom web service. This would require us to handle a scalable server infrastructure which sort of defeats the purpose of Playfab.

If you implement a guild functionality it will fix our problems but do you have a timeframe for this? We need a solution within about 3 months from now, can we make it?

Thank you

To be clear, Shared Group Data was designed as a simple place to share data between subsets of players, so I would completely agree that it isn't suited to a fully authoritative clan/guild implementation. It was never meant to be. For titles that have lightweight needs in that space, such as just passing messages between clan members, Shared Group Data can be effective.

However, since it was not designed for actions which by their nature should be atomic (like adding to or removing from a clan bank), there is some risk in using it that way, as I've described. Using Cloud Script to perform the complete action (Grant to the player followed by remove from the clan, or add to the clan followed by Consume from the player, so that you never lose items and have minimal risk of duplication) would be the way to minimize that risk. In general, and assuming your guilds have reasonable limits for the number of players who can be in one, the chances of encountering this issue would be relatively small.

I'm not sure where you saw mention of using Shared Group Data for clan leaderboards, though. That would absolutely not be effective, and I would not recommend it. That feature requires a dedicated solution on the backend for it to work correctly.

Unfortunately, I cannot provide a date for clans as a distinct feature, as our current schedule is focused on work items which were previously prioritized through work with our developer community. We're working on making our backlog more visible, so that developers can have a better sense of how far out things are, but please note that as a live service, we do have to adjust our schedule from time to time to make room for key issues. Because of that, and because we never want someone to take a dependency on a feature that we're not 100% sure will be available when they need it, we do tend to be conservative when it comes to stating dates for upcoming features.