Imported from previous forum
When logged in as group admin of a member to maintain the list of affiliated employees, it is important to have access to the email address independent of this user's privacy settings. Our internal employees must use their company address and not their private email such as gmail. We allow external employees to be affiliated with Deutsche Boerse as long as they use the temporary company email address they have received from us. The new website data model foresees a single affiliation per user I believe. The external employee can change his affiliation and email when he works for another company as an external. This is relevant for all consultants.
The information should already be visible on the list page where currently only the name and employer are displayed. It is too tedious to click on every employee to find out if he/she complies with the policy.
Need to speak to FPL programme Office to agree an approach to this. They have no discretion to disclose e-mail address publically at present without explicit consent from the user, due to data protection rules. It is technically trivial to expose this (just a very simple config change) but the issue is what is permitted to be disclosed, and to whom.
The site actually allows affiliation with more than one firm, but as you say users can amend their e-mail address. The e-mail address that can be disclosed within the Profile is a narrative field, and independent of the one that is formally tied to system identity (which can also be edited by the user). At the moment, only site adminstrators can see that e-mail by default, and the user needs to change their settings to make it visible to anyone else. Any deviation to this approach would require a change to site Ts&Cs to make consent to disclosure explicit.
One approach would be to make disclosure of e-mail details an explicit condition of the Member Affiliation request, but we would need to make this explicit in the workflow. Will discuss and revert.
Ken,
I would think that if an individual claims that they are affliated with a member company, in order to get that privelige of being associated with FPL member the firm's group admin must be able to verify the information the individual input including their email as part of the "approval" process of accepting that the individual indeed works for the firm. This is not suppose to be an "open" social netwoking site therefore in order to be given the access rights that information should be visible to the firm's group admin(s). Hanno's request is not about changing it to be displayed publically, but to the group admin.
I agree with Lisa and Hanno.
I was hugely disappointed to see that when the new website went live a large number of people were added to the NAB group without ever actually being verified by a NAB group admin. I removed them from the group but this was a very poor decision by FPL to add people to closed groups without discussion with the group administrator.
Lisa,
Agreed in principle that this would be of value. The issue is making sure it is addressed in a compliant fashion, and in a way that does not subvert deliberate data-protection policy controls that are engineered in at system level. This would be an explict deviation from the original spec, and require a new feature to explicitly mandate Employee Group Owners/Admin to have access to the relevant data. Since group admins are not a system-level "role", just a user with a defined role WITHIN a specific group that the applicant is not yet part of, it is non-trivial to procure access to data that is deliberately "locked down" behind data protection features. It would require custom workflow, unique to FPL. We need to change that in conjuction with potential changes to FPL Ts&Cs, the possible inclusion of additional explicit dispensations within the sign-up process, and careful implementation to avoid violating core platform-level policy constraints, since it would need to very surgically "punch a hole" in features designed to prevent FPL breaking the law, for a specific use-case, without exposing a resultant data security vulnerability. The capacity is also contingent on prior resolution of the legal issue, so this needs to be doen carefully and in coordination.
My understanding of the legal issue (which may be incomplete) is that this cannot be addressed via generic Ts&Cs dispensation, as case law in both US and EU regimes has shot-down attempts to use this legal defence- so it may require an EXPLICIT consent on each individual occasion..... but thats one for the lawyers to resolve before we can code anything, and by its very nature, it will be FPL-specific, as the core platform constraints enforce universal conformity.
So irrespective of the merits of the requirement, FPL needs to first ensure a proposed approach is compliant, then we need to work out the best way to implement it, and prioritize accordingly in the light of resources and competing claims.
John
As discussed before with yourself and Daniella, that was done by FPL prior to the migration to the new site, not as part of it, and was not an issue with either the site itself or the data migration. I appreciate that the distinction may be moot from your perspective and relate to an issue of principle, but the issue you raise is entirely independent of the narrative above, and more a matter of operational practice relating to changes to firm data by the Programme Office.
As far as I can tell from the data, NAB is unique amongst FPL Member firms in not conferring "affiliated" status to every user who can be established as being currently employed by them, as that restricts the capabilities and data/file access of those individuals. The proccupation for most Members is full inclusion of their affiliated personnel, and the general data-quality problem for most member firms is over-generous inclusion of people who should strictly not be members, through failure to catch leavers, rather than the other way round (which clearly would be of concern to FPL in terms of ensuring membership benefits are confined to those entitled to them, rather than restricting them to people to whom FPL would quite happy for such benefits to be bestowed). Many firms also serially neglect the process of administering their users, and expect the PO to do it for them and take responsibility for data quality on their behalf, so its a tricky balance to get right. I fully accept that that is your prerogative to specify as you wish, and the outcome isnt one the system (or migration) would have generated on its own.
I am also sensitive to the day-to-day operational reality the Programme Office face in that many firms lean on the PO to make data changes that perhaps properly should be made directly by themselves, so its a fine line to walk between the rigour of not making any changes "on behalf" vs always making changes with formal consent (or desisting from making them at all). One of those "all of the people all of the time" scenarios.
Well, I am not an admin of other firms so I don't know how other firms operate. But you tell me how you "know" that the people who were added to the NAB group actually worked at NAB? Your point "unique amongst FPL Member firms in not conferring "affiliated" status to every user who can be established as being currently employed by them" is meaningless if there is no validation - did ANYONE validate those users? Who "established" they worked at NAB?
The answer is no-one and people who did NOT work at NAB were added to the group.
This website was put live with nowhere near enough testing and it's disappointing.
With the exception of 4 users, I believe of the original 27, they were all under either nab.co.au (22) or eu.nabgroup.com(1) e-mail domain addresses that responded positively to an SMTP ping validity test as a valid e-mail address in that domain.
The other 3 were other e-mail domains, (1 singmail.com and 3 gmail.com) but (I can only presume?) known to PO personnel.
I must emphasise I only know this because I tested it when you first raised the issue as part of trying to work out what happened before the PO explanation manifested, at which stage I stopped looking as it was evidient it wasnt a system problem. This is regulalry tested as part of e-mail list data quality maintenance. I cannot speak to FPLs process, just my own forensic investigations.
Also John, I seem to recall that after our earlier discussion on this you reduced the number back to 5-7 or so, but if I look at your Employee Group now, there are 19 (20 including the entity itself), and substantially the same people. Have you since added them back, or maybe they never got removed and my recollection is flawed? We havent done anything with the data that could cause them to revert in the intervening period, although there was a script run to reconcile Profile Type with the associated member type. All this did is make sure that the Profile Type of each user affiliated with a Member corresponded to the member tier of the member firm.
No, I think your recollection is incorrect. I said that there were 5 people I had validated on the old site. Another 20 or so arrived on the new site and I removed 5 or 6 that were not valid people to associate with NAB.
Let's be realistic - did anyone at FPL "know" the gmail/singmail account users? No. It was a simple "path of least resistance" change to add all of these people to a group without bothering to ask the group administrator.
Hence my point - a website put live without enough testing and without buy-in from member firms.
Ok that explains the 19. But the migration brought over 27 from the old site, meaning 28 on the new site to include the entity. I cant speak to how they got into the old site, just that they passed muster when we checked them, and reconciled perfectly with the source data as to composition, group role, and "ping test" as valid e-mails.
And that's the point isn't it? These people on the old site were NOT associated with NAB. I have been the admin for that group from inception since it was my idea for NAB to join FPL. Someone at FPL then decided to just add people to the NAB group without my permission.
Therefore - not enough testing and without buy-in.
I think we need to accept that the new website cannot make a difference between public and non-public user groups. The requirement was apparently missed in the original spec and would now only be possible with custom workflow for FPL and associated cost. Personally, I do not think it is worth the investment of FPL to go down that path. The consequence for me is that as a group admin I can no longer accept externals as members affiliated with Deutsche Börse. If they need access to content protected through FPL membership they will have to ask their internal colleagues to provide it to them. This approach still does not prevent internals from using their private emails and continuing to have access after they leave the company. That simply means I have to compare the member list with our employee directory from time to time to see if anybody has left the company. That does not work for larger companies with hundreds of members or more but it currently still works for us.
Hanno thats not the case at all. User Groups can be configured to be restricted in tems of visibility to their membership, and if their membership is available only by invitation, they are completely invisible too anyone else. This is the case for Employee Groups, and so long as you retain the original settings, no one can even ask to join, other than by a request being generated by virtue of their "claimed" affiliation to your firm as part of registration, or by a site Admin initiating the process.
Alternatively, other groups cn be made public and ipen to external registration, so for example, by default, a Member Listing is open to membership by anyone interested in your firm as means to be kept in touch with anything you post in it- along the lines of LinkedIn Group or facebook "Page".
Content dependent on FPL membership requires that the user is affilaited with a Member Frirm in order to secure access.
In terms of your earlier request for visibility of the e-mails as a Group Admin- thats a different issue. Daniella actually came up with a suggestion that might work, namely we might be able to make the domain visible without the prefix, so you could see whether someones e-mail ended in the appropriate domian:- e.g @deutsche-boerse.com in your case.... We are looking into this. And even if it cant be done at the moment within the legal restriction, that doesnt mean we wont be able to find a way to do it, just that we will need to work out some way of obtaining explicit consent as a pre-condition- it just involves a little more than just making it accessible.
The issue with people leaving has always been present- on the old site, most member firms had a data problem with people no longer being present, so nothing new here- the Membership needs to be periodically reviewed to keep it current.
Site admins can download a query containing various data about Employeed Group (or any other group-type for that matter) and review for the consistency of the data, so any e-mail addresses that are subsequently changed stick out like a sore thumb. The new site also provides for a member leaving one firm and joining another without the need to register again, and this will proboke a new Member Firm affiliation, which could serve as a trigger to alert the company admin as to a potential issue.
I dont think there is any issue with you bilaterally requiring access to an e-mail address as a "connection" or as an expicitly permissioned user (via a custom Access Control List, which is something every user can create and apply), as a "condition" of membership of your Employee Group. The issue described above only applies to the data being disclosed programmatically as part of the automated application process, as at that stage there is no prior contact. You can also contact (via site message from their profile, or any other accessible means) any user who requests affiliation, before and as aprerequisite to accepting their request.
I think we now understand the objective you are seeking, and we are actively discussing and exploring a means to address it.
My comment was triggered by your answer to Lisa above. I have marked the key elements in red below that led to my conclusion. I am sure anything is possible but FPL has make a cost/benefit analysis of website changes compared to the current offering. Specialities and unique features for FPL increase complexity and reduce ease of maintainability from my point of view.
The issue is making sure it is addressed in a compliant fashion, and in a way that does not subvert deliberate data-protection policy controls that are engineered in at system level. This would be an explict deviation from the original spec, and require a new feature to explicitly mandate Employee Group Owners/Admin to have access to the relevant data. Since group admins are not a system-level "role", just a user with a defined role WITHIN a specific group that the applicant is not yet part of, it is non-trivial to procure access to data that is deliberately "locked down" behind data protection features. It would require custom workflow, unique to FPL.
You say "Site admins can download a query containing various data about Employeed Group (or any other group-type for that matter) and review for the consistency of the data, so any e-mail addresses that are subsequently changed stick out like a sore thumb.". I do not think it is realistic for the FPL Program Office to accept requests from member group admins to draw such a list and point out deviating email addresses.
The data problem with people leaving is indeed not new but the old website had an automatic "feature" of implicitly preventing access because the member firm ensures that the email address is no longer available to the person that left. A person could change his email address but this was visible to the group admin when checking and that is now no longer the case. Data privacy rules apply to all users in the same fashion in the new website, only site admins have access and group admins do not. Conceptually, admins of employee groups are equal to site admins in my view, only difference being that they do not have the right to see anything beyond the group they administer. However, within the group they should have the same rights as a site admin has across all groups.
There are a couple of different issues here:-
"Open-ness" of Groups:-
The system allows groups to be configured in a variety of ways. In the case of Employee Groups, they are (by default) both "Closed- Members Must Apply/Be Invited", and "Visible to Members Only", since membership of them represents the mechanism by which affiliation with the firm, and the extension of any member provilieges to the individual users is managed. This significance is unique to Employee Groups, and indeed is there primary purpose. This has the implication that anyone who is not a member cannot even see them (unless they are a site admin). This also means users cannot casually request membership, as they cannot see the group in ordert to initiate the request. Allowing the group to be visible to logged-in users, or publically, would allow join requests to be made, but individual content items can still be posted such that they are only visible to Employee Group Members. The access controls applied to the content apply even when the content is "contained" within a groip with more open access.
Other types of group can be configured to allow users to join without any pre-screening by setting them to "Open-Any member May Join/Follow). This is the default setting for Member Listings, where "following" is intended merely to express an interest in being kept in touch with any content or updates posted by the member firm for the purpose of informing interested parties, which may be internal or external. This is very much along the lines of a LinkedIn Group or Facebook "page" and does not have any operational impications for the management of affiliation with the firm.
The registration / Profile edit process contains a field whereby users "claim affiliation" with a Member firm which references the Firm GUID, and thereby provokes (automatically, although the scrip is currently manually initiated) a request to join the Employee Group. This also triggers notification to the group owner, admins and user moderators, that request is pending.
Visibility of Profile Data:
That request appears in the group Owner/Admin/Moderator's "Join Request" console, and includes a profile 'avatar', which is hyperinked linked to the individual's profile. The Profile menu includes various options, including the ability to message the user to request further information, and also provides a display of various user data, which consists of a few mandatory elements, plus whatever information the user has elected to share. Currently, the "registration e-mail" is never displayed (except to site admins, and the user themselves), but the users "visible" e-mail contact address CAN be, if the information is shared by selection of the appropriate access controls- this is just a narrative field that displays (mandatory) text supplied by the user, and has default access control setting of "Private", which the user can override. This ensures the personal data respects Data Protection, and any decision to display it more widely is explicitly the user's own.
Group Admins are not officers of the legal entity operating the site, so are explcitly outside of the operators limited formal discretion to share personal data. This means consent to the sharing of e-mail data would need to be obtained from users, and FPL cannot "assume" such permission can be applied to group admins from across the membership, as in law, they are third-parties.
FPL needs to take an informed view as to whether obtaining such consent to share this data with group Admins could be adequately secured by inclusion of a relevant provision within the Ts&Cs, or whether an explicit consent is required in each individual case, or for each individual party to whom the information is disclosed. The answer too thatt question ahs fundamental impact on how it coudl be approached in implementation terms.
With the conclusion to this opinion in hand, we could construct a corresponding method to make it accessible, but to generalise the soloution to encompass all permutations of these would be a much more substantial task than creating a specific workflow, so I think the first step is to get this clear, then we can consider the best way to approach it.
If the objective is clear and simple, the implementation is likely to be so too, its covering every conceivable permutation that represents a challenge.
In the meantime, Daniella's proposed approach of showing the e-mail domain, but not the whole address, gets us a long way I think, since group Admins can then either approve when its clearly "in domain" (which should cover most instances) or message the user to obtain any additional information where it doesnt tell you what you need to know.
On the old site, Group admins could see the list of users, but not navigate through to their e-mails. These were reserved for site admins, however since you had the privileges of a site admin, so you could see them. Your experience would have differed from that of member group admins in general, and not differ much at all from what it is on the new site.
A group admin is not a system-level role, its just a user who owns/administers a group, since potentialy any user could own a group of some kind, so extending a role-based perspective on data access is not currently an option, but that doesntt mean we cant extend the function of the employee group or the Join Request workflow to do what you suggest, providing its an explicit case we are dealing with.
So I think the issue is how do we best address your (very legitimate!) functional requirement, and I am confident that if we base out the legal issue, and take it steadily, we will be able too do so. A custom workflow isnt too daunting if its very clear and specific, its a generalised solution thatt would always respect data protection that represents the conceptual challenge.
Let me discuss this with Courtney and get a clear cut policy statement, and we can them take if from there.