How to display email of Group Access Requestor to Owner

We have a lot of Private Listed and Public Closed groups. In those two types a person needs to request access to a group. We do not display emails anywhere in our system but in this case the Owner needs to see the email the Requestor is using to request access.

There are 2 moments an Owner is notified

  1. Notification bar (Live alert)
  2. Notification mail

The owner then goes to the request page and sees the request

So we have 3 touch points where it should be possible to expose the email.  In the past we used ON PREM and we were able to trick some backend process exposing the email during the request and show it in the Request Page but only to the Group Owner.

Now we are Cloud based an I am looking for help/tips on how to expose the email to a group owner. Preferably on the Request Page but otherwise in the Notification(s)

Parents Reply Children
  • I have to agree with @Wilfried Rijsemus that there should be a way for group owners to see the email address of a user requesting access. You just have to make sure you confirm with the user that they know they are sharing their registered email address with a discrete list of group owners at most. This new functionality would allow for a happier set of group owners on my community...

    We run beta groups for new products and set them to private so we can be selective about who posts in the group. We make the beta manager the group owner. Normally the beta manager emails a set of people about the beta from another system. For example, something as simple as Outlook using the BCC line to keep the recipients from seeing who else has been emailed. It depends on the size and complexity of the beta and EAP.

    Note:

    • The beta manager will have decided who to invite using the person's email address as the key to identifcation.
    • This set of people may not have registered on the community yet.
    • The beta participant's email address is the unique identifier the beta manager *wants to use* to confirm the requester is the same person they originally emailed.

    When a beta participant requests access, and the beta manager sees only the username, the manager cannot make a decision as to whether or not the user should be allowed access. If the manager is expecting 'john.smith@example.com' to join but only sees 'Wookiee74' (cool, but not helpful right now) the manager cannot confirm the access and the process stalls - it's not smooth.

    1. Option 1 could be to change the beta process and have the beta manager email all beta participants and ask for their username and then add or invite these users to the group as members. This lowers adoption and creates a barrier. The set of email addresses may total hundreds. The beta manager has a thousand things to do at this phase and needs the system to help them.

    2. Option 2 should be to change the request access page and insert a confirmation prompt that their email address will be shown to the current set of group owners (listed for inspection by the requester). The user positively selects 'I agree' and the button to request access is enabled. This would allow the beta manager to do whatever they want as a process to get the beta participant to request access. They then only have to approve the requests as them come in by comparing the email address to the list of recognizable addresses they originally emailed. To the manager this process makes more sense to them.

    If Telligent implemented an unticked checkbox then the customer must actively confirm their consent and, if they do, sharing is OK. Example (picture always helps):

  • That is a very elegant solution. That would REALLY solve the problem. Big kudos for this idea. Right now I have hard won Group Owners abandoning Telligent because they cannot judge who is requesting access.

  • Note in the scenario where a user is invited by email address and it is known, that the group owner should not have to approve the user any further even after they have registered for the community, unless the user abandons the flow.  

    For additional feature requests however, I would suggest posting the idea here with full use case defined:
    community.telligent.com/.../

  • This is only when requested access, not when invited, because the email is known then already. One case excludes the other.

  • To be fair  it has been there for less than a year at the time of this posting (posted May 2017).  We review this when planning for releases and many factors go into our decision to take features.  Placing an idea here does not guarantee a feature will be taken and that it will be taken in the next or even subsequent release.   It does not mean we find the contribution less valuable or unimportant, we simply have a process, this being one part of that process.

  • To clarify when I wrote...

    The beta manager will have decided who to invite

    ...'invite' is outside of the Telligent system.  They may have to email a complex HTML email or attach a pack of information to the email.  They may very well not be using (and unable to use) an email client.  They generally want to use whatever they are currently using to do the 'inviting' and only come to the group, and hence Telligent to confirm the requests as/when/if they arrive.  All outgoing correspondence is from another system.

  • That is correct. The topic was on the table for quite some time but I posted it as an idea last year. We struggled at SDL with this topic as early as 2014. Just talked to on some on a related topic called GDPR in which we need to deal with the same deadlock of User Consent and Owner Trust. This is why I liked the proposal in this thread from . it is elegant and solves this part of the problem. The second part of the problem comes if the Owner decides to deny access.

    I added in the idea the dialog that needs to happen when an owner decides to deny access. A harsh decision that would need clarification otherwise your hard won member will leave the community. That is currently not possible since the owner is not prompted a dialog box to explain the denial. Usually it is the wrong email domain (like hotmail) being used that cannot be granted since a company email is required. (Before becoming too technical, we are anticipating federated identities. This effectively means that if this person is no longer working at a certain company, access is automatically not granted to your community hence, the group because the authentication is done against the company's identity provider).

    This solves a major account/access problem which occurs over time when you run a community in a B2B context. Access granted to private customer groups are automatically revoked if YOUR identity broker asks THEIR identity provider if this person still works at this company. This can only happen if you granted access on the right email in the first place.

    So, although this idea may seem trivial, the reason why we need it is not. It is a real achilles heel of the Telligent platform. We are using Ping Identity BTW