Alias for End User in CommunityCompleted
We need to have an Alias for End-users added to Community!
Or at least a viable solution that solves the "anonymous/alias" user private identity requirements of communities like ours.
We chose to use Zendesk for our private end-user community. Because the majority of our end-users want the ability to be known in the community via an Alias or at least be anonymous not revealing their full name we worked with both Zendesk support team members and an approved Zendesk partner to create a work around. Unfortunately our work around failed on a few counts. See disadvantages listed below.
Currently there is no way to have an Alias. But we want and need to if we are going to use Zendesk for our customers to engage with one another.
Here is what we implemented after working with Zendesk and a Zendesk authorized provider Help Center design expert.
ZD initial proposed possible workaround:
Create a custom field for user real name and make their ZD username the alias.
- Profile name changes so that requester name becomes the alias in all ticket communications, views and reports.
- This isn't ideal as the customer would be addressed by their alias instead of their user/profile name. User management would also be a challenge.
- This won't work for us as we need tickets to come in with the end users current name format of FirstName_LastName-OrganizationName
First Name only for Community:
Note: Public Profiles must be turned off for this solution.
- Privacy settings were enabled and Private profiles selected so that users would not be able to see anyone's profile. Unfortunately this does not stop users from seeing full names of the community members. So our work around for Alias and anonymous users failed due to the disadvantages listed below.
- We went to a first name only basis. We had a customization implemented that removed all information following the user's first name in the Community. Tickets remained as the full profile name. (We also removed Avatar for the Community).
- For users who requested an Alias instead of their first name we added a short "alias" name at the beginning of their user profile. Not ideal. But as a SAAS solution that does serious project and account work for our customers we can't change their true identity to an alias.
This solution failed due to the disadvantages listed below.
Unique User for Community:
- The other solution we implemented was to set up a separate unique user with the Alias name
- We created a custom user profile field called "Alias" which we used to cross reference the "real name" in the Alias User and the "alias name" in the Real User.
- We added the Alias column to our Customer lists for reference and reconciliation
- Not ideal. Not only is it confusing, it creates organizational chaos and is not scalable especially for our 500 customer base in a fast growing company.
- In addition we already had one user accidentally post to the community from his Real user and raise an emergency request to delete it noting with resigned despair that his identity had already been exposed.
- If users accidentally started raising tickets from their Alias users we create further user management confusion. We are not making this option available to more than a select few users as a temporary work around.
This solution did not fail per the disadvantages listed below. But it fails as a viable solution as it introduces serious user management challenges.
- Full username shows up in the Community search results. This can be removed in the code so that Community search results to not show author.
- Full username shows in the email notifications sent to any user following the post or comments. There is no way to remove or modify this currently. The only possibility to avoid this would be to remove the "Follow" button from the Topics and Posts pages so that users could not subscribe to email notifications for updates to posts or comments. This of course removes a very valuable function of community so is a huge trade off to ensure user identify privacy.
- Full name can also be seen in the page code. There is no way to cloak or alter this.
We would love to have an Alias solution for End-users added to Community! We truly need this!
In the meantime, if anyone has a more functional workaround I'd love to hear.
We want to announce that this product feature is now live and a part of Gather! Thanks to everyone who helped drive us to this launch with your feedback, testing, and suggestions. If you have any feedback on this or features unique to Gather, please feel free to post in our new Gather Product Feedback forum. For more information on this live feature, feel free to look into this article detailing all of the new features and capabilities!
Hey Dru - Good news! Not only has development on the community platform resumed, but aliases is one of the first features the team is looking into. We don't have a set ETA yet, but will keep you posted!
We are having the same problem here. Any effective workaround found?
Unfortunately no. We discovered that even with our workaround of cloaking the users last name and organization there is no way to turn off the auto subscription to emails that displays the full user name and organization. As a result users who wish to remain anonymous (which in our case is most) simply do not comment or contribute to the community. It has caused an unfortunate impact which virtually killed our launch.
There is possible a solution that might be worth mentioning if you are interested. It still has some shortcomings that made us rule out it's worth, but is the best work around we encountered thus far. Zendesk could create a private app for setting up user profiles.
Here's what the Zendesk solutions engineer was able to come up with.
There is a potential solution for using the
aliasattribute within end-users, which can't be directly set within the agent interface, but is able to be updated via an API call. In looking at the SSO specifications for both SAML and JWT, neither appears to support the manipulation of that value via SSO. If SSO is being used that leaves us with two general paths:
/api/v2/incremental/users.jsonendpoint of our API periodically to keep track of user creation. If a user is created, make sure their alias is set. The downside of this approach is that if the API call to update the alias fails for whatever reason, the user's regular info would be displayed, which isn't acceptable.
- Create a custom app that would facilitate user-creation (and updating), insuring that the alias is set & updated correctly in each of those cases. In talking to some of our services & success folks, this seems like it would be a fairly low level of effort. The off-the-cuff number that they suggested was something in the neighborhood of $2,000 to build such an app, but I would want to have you sit down with one of them to discuss the details before providing an exact number.
If you come up with something better I'd love to hear. We are in a holding pattern with a community that is not getting any traffic due to this inability to have a secure alias.
- Poll the
Thanks for the update.
I can't understand why there is no Alias or username management in ZD ???. It seems to be a basic for any public forum.
We can try to force our end users to create an Alias when creating their account and try to map it to a custom field in ZD however I am not sure that it would get passed through the JWT SSO.
Not the best customer experience in any case. I have raised a ticket with support before seeing your post here but now I am not optimistic.
I found it surprising that there was literally no post of other Zendesk users desiring an alias. I suppose the majority of those using Community have members who are building relationships while networking. In the truest nature of community there is a collaborative element that definitely fuels growing the community. In our case however it is a deal breaker for most of our customers. They won't participate if they can't keep their identity private.
The first recommendation by Zendesk was to create the users with their alias and add a custom field of "Legal Name". As you said, it would require mapping and all the requester names on all tickets would be the alias name instead of the actual name. Not acceptable for our business model.
Let me know what you find out.
Our customers are not able to change their username due to other integrations we have that need to use their full name, but many of our customers don't want their full name shown on our forums. Would love to see this feature implemented. Thanks!
Hey Laura -
Thanks for the feedback. Unfortunately, development on the Community product has been suspended indefinitely, but we'll keep this thread open in case it gets picked up again in the future.
"Unfortunately, development on the Community product has been suspended indefinitely, "
Too bad :-(( The privacy issue was the reason we disabled our community after some time. We got too much complaints from our customers about privacy. People really want to communicate about our products in a forum, and help others, but not with their names being indexed by search engines.
The utterly clean look and feel and simple one-stop-shop approuch for our customer service agents whas the reason we did not bother to install another 'heavy' community package.
The real issue with a community is: you will need less agents if people help each other :-) That is also what we saw happening. People started asking and answering questions among themselfs, we had 'product experts' from our wholesale suppliers answering customer directly, it worked pretty well.
Now we are looking for another clean solution wich we can integrate with our e-commerce platform and Zendesk, but without all the clutter, usually associated with online forum software.
I am happy to say that I have an update for you. The product team has resumed development on the community platform, and aliases are one of the top features they're looking into. Thank you for sharing your feedback on this; you have helped to influence our products in their new direction.
We'll continue to keep you posted as things progress!
+1 for this feature. We're in a similar situation where our end users would prefer some anonymity.
Thank you for letting us know that you're looking into it, at least.
Post is closed for comments.