44 Replies Latest reply on Jun 23, 2017 10:28 AM by nataliashcherbyna

    Guidelines for external collaborators on internal communities

    Edward Ford

      We're preparing to upgrade to Jive 7 and look forward to using the external groups functionality that allows users to invite external parties to participate in groups on an internal community. Has anyone who already has this functionality amended their community rules with guidelines outlining how people should use this functionality? I'm just beginning to think about the guidelines that we should share with people and it would be helpful to hear considerations from others or any specific issues that may have stemmed from this functionality.

        • Re: Guidelines for external collaborators on internal communities
          Libby Taylor

          We are reviewing and testing this functionality right now in Jive 7. I suspect that due to privacy concerns and overall a feeling of wanting to control the extent to which Externally Accessible Groups are used, we will probably only turn-on the ability to create external groups to a few key advocates. We might require that someone who wants to be added to the list of folks with this power present our governance team with the use case/plan for their EAG before we will grant them the power. As it is, there are so many controls on the back end, we could end up only allowing a very specific set of external users into these groups at all. So I guess you could say we are in the process of figuring it all out in order to fine tune how it would work for us. As far as the collaboration guidelines themselves, we will probably leverage what we already have for our users, which includes some clear terms and conditions that have to be accepted before they can proceed in the site. I'll keep you updated here as we know more.

          • Re: Guidelines for external collaborators on internal communities
            lindoty

            Keeping in mind that I lead in a function called Global Sourcing which is about how my company transacts (and interacts) with suppliers, this could be huge for me. I will only speak of it in whispered tones because I can already see the suppliers circling like vultures - how they would love to be able to pick up a bullhorn and speak directly to our 60,000 employees! 

             

            I would say that in addition to developing the internal guidelines, there would need to be an Acceptable Use policy for the external parties you invite to participate.  The little hamsters in my brain are running on Red Bull and adrenaline right now just thinking about it.

            • Re: Guidelines for external collaborators on internal communities
              it2000

              The difference between emails and an external group is not too big. We have contracts with our business partners and it does not really matter how we communicate. If '(email) collaboration' did work before then it should improve within Jive.

                • Re: Guidelines for external collaborators on internal communities
                  lindoty

                  For me the difference between email and access to our employee population is the difference between a whisper and a bullhorn.  I am in Sourcing/Procurement and I know plenty of my suppliers would trip all over themselves to market to the bigger employee population.  And while many are trusted business partners, there are enough of them that just want to sell that they will be making offers of items and services that encourage unnecessary spending ("Book a trip by April 30th and earn triple frequent flyer points!) and we have to be careful because if we've given them that bullhorn, then people will assume we are endorsing whatever they are peddling.  I'm a huge fan of social business but I definitely think opening this door must be done with some manner of agreement on acceptable use.

                    • Re: Guidelines for external collaborators on internal communities
                      nbussard

                      Linda,

                      I think you might be misunderstanding what this feature offers. It does not give external collaborators a bullhorn to speak to all of your employees. It limits them to a specific secret group. When they join the group, they have no access to any other part of your community outside the group. The only way the scenario you describe could happen is if you invited all 60k employees to every group that included external collaborators (assuming you would have a different group for each supplier, each project, etc.) and the 60k people accepted the invitations.

                        • Re: Guidelines for external collaborators on internal communities

                          Linda Doty - 100% how Nikki has broken it out here, you have no reason to be concerned.

                          I like to think about it this way (lets assume internal community):

                           

                          places.jpg

                          Your community is the box.

                          Everything within the box is part of your community. Relative to the people and places interacting - this chart is fairly simple.

                           

                          Spaces are the highly organized areas in the community.. crazy permissions, nesting, all the fun admin console stuff. The portal story. These are the squares, with an associated tree (and spaces can have projects, so we slap a few circles on there)

                           

                          Groups I have here as the circles fully within the community- these can be open, closed, members only, etc... but are entirely within your community. Members have access, non members don't. [Social] Groups fill the gaps between spaces Pretty easy

                           

                          External groups are the ones on the lines - they're accessible to external folks that are invited, and only internal folks invited can have access. Immediately on creation they are either Private or Secret - as the user type "External Contributor" cannot have visibility to the entire community. External users cannot have permissions on spaces (no overrides, no view/create, etc.) - so they are only given access to the groups you allow them in to.

                           

                          That help?

                          There's seriously no reason to be concerned.

                           

                          From experience now, external groups are great for working with contractors or agencies.. amazing. Especially in marketing - we deal with so many agencies on one-off projects, or infrequently.. we wouldn't want them to have access and be created as a "standard user" with weird permissions so they can only see certain things (the old way) - they just get invited to this group, and no problemo, they're in!

                            • Re: Guidelines for external collaborators on internal communities
                              apaddock

                              After working with pur customized external "walled garden" Jive for a few years the one concern I have here is that you can create Private and Secret groups for External Contributors to join. In our platform it was Secret only as we dis not want any of the client group names to show up in the search as although only the Internal users could potentially see the Private groups in a search that might not be appropriate as the client may be in a proposal stage with the company and not common knowledge. Yes, you would expect group owners of such groups to choose Secret but we couldn't take that chance.

                          • Re: Guidelines for external collaborators on internal communities
                            it2000

                            @ Linda: Good point. I already get a lot of 'spam' emails (and snail mail) with offers and invitations - some are really 'annoying' like the JW14 invitations ;).

                            And there are the offtopic e-media conversations with jokes, images, YouTube links, ...

                            Posted in a group they would reach a countable number of employees (eg 40) while when emails are sent and forwarded the number of recipients is unknown.

                            Disallowing ads and off-topic content makes some sense. On the other hand also the partners need an option to promote new products etc. Should they keep sending emails?

                        • Re: Guidelines for external collaborators on internal communities

                          In response to OP -

                          We're preparing to upgrade to Jive 7 and look forward to using the external groups functionality that allows users to invite external parties to participate in groups on an internal community. Has anyone who already has this functionality amended their community rules with guidelines outlining how people should use this functionality? I'm just beginning to think about the guidelines that we should share with people and it would be helpful to hear considerations from others or any specific issues that may have stemmed from this functionality.

                           

                          We're fairly open with our guidelines, but we're a pretty small company. We have a tendency to test our functionality and organic growth first, and govern later - which is great for us, but not necessarily you. Honestly? I think that these groups should not be allowed to be created without CM approval/management - or that they should not be allowed to be secret. I think creating too many secret externally accessible groups like this almost defeats the purpose, as you end up creating another silo.

                           

                          I think if its easy to manage an approval queue, go that route. Otherwise, I would also be very interested to hear any thoughts or feedback around best practices from the rest of the Jive Internal Communities crew

                          • Re: Guidelines for external collaborators on internal communities
                            lindoty

                            Don't get me wrong - I think this is a FANTASTIC new capability and I'm very excited to use it!  My department collaborates with suppliers a lot. In fact, as more and more companies increase their leverage of external talent, this need will only grow.  Two use-cases jump to mind immediately:

                             

                            1) Small collaboration group - when internal and external parties are collaborating on a project, being able to share space like this is valuable.  (Think of mergers and acquisitions and how they use the digital 'safe room' for their work - we'll now be able to extend the value of this well-beyond that group with mainstream tools!)

                             

                            2) Extending the support of employees to the supply-base - there are many strategic supplier partners and programs where companies like mine serve as the middle-man (men) (and women) between the larger population of employees and the account teams that service us.  What if the tools allowed us to get out of the middle?  What if Dell could answer questions about memory modules directly to employees? What if AmEx could answer why a physical copy of identification needs to accompany the card-application in Poland? In a controlled environment, where the terms of engagement are documented and clear, companies like mine could benefit GREATLY by letting suppliers, by invite, interface with the population of employees. 

                             

                            If it sounded like I was resistant to such, then I misspoke.  I think this is a phenomenal movement forward and I know my group will embrace it gladly, but it still does require clarity in the engagement model so it will succeed.

                            • Re: Guidelines for external collaborators on internal communities
                              nbussard

                              Here's a good thread on the logistics of external contributors: Externally Accessible Groups

                              • Re: Guidelines for external collaborators on internal communities
                                Libby Taylor

                                We've moved a little closer to where we want to be with External Access Groups, so I thought I'd give you an update. We realize that this feature will be critical for some groups at our company because 1) we don't have an external community and 2) we really need a way to collaborate with outside partners. That said, we also have very strict privacy rules and want to be very careful with granting access to the ability to create an external group.

                                 

                                The plan we have today is:

                                • Pull together some governance rules about why an external group can be created and what the typical uses cases look like.
                                • Define descriptively what kind of external partner is appropriate for these groups. We can also control some of this system properties side with the defined email addresses (i.e. *partner.com), however the list could be very long and possibly unmanageable so we might leave it undefined for now.
                                • Require the group owners to take/pass some brief training on our internal security requirements, managing an external group, and how to manage the partners access to the group.
                                • Require a signed confidentiality/non-disclosure agreement with the partners (still checking on the details around this one).

                                 

                                Anyone who wants to start an external access group will have to submit an IT support ticket to get routed to our governance team. If their use case is approved, then they would be added to an Active Directory global group which would streamline some of the management aspects if, for example, the person were to leave the company or we didn't want to use the Admin console to add the access for each user.

                                 

                                Finally, we plan on testing this whole concept with one key use case before even letting the rest of our community know this feature is possible. We like to iron out the kinks before turning on the fire hose.

                                • Re: Guidelines for external collaborators on internal communities
                                  dvm

                                   

                                  We are hoping to leverage the 'External Contributor' feature as a means to combine two current yet seperate internal instances. One for employees and the second for contractors/consultants.

                                   

                                  Employees would continue to have their accounts created automatically via an LDAP sync while consultants would be treated as external contributors and required to be invited to specific groups.

                                   

                                  Over time, especially if the number of consultants grows, this could become hard to manage in terms of provisioning/de-provisioning accounts. I am curious if there is a way to maintain all users via LDAP sync-ing but automatically assign them as employee or external contributor based on an LDAP attribute? Is anyone planning to use this in a similar way? If so what are your initial takeaways?

                                   

                                    • Re: Guidelines for external collaborators on internal communities

                                      I think managing external users like this in a community becomes very difficult. Again highlighting my response here - external contributor groups are extremely limited in their visibility both in and out of the group. This hampers the ability for folks who need to be involved in more than a single group, or have access to spaces within your community.

                                       

                                      I think here, for your scenario, you have three easy options:

                                      Option 1: Look at identification of contractors vs. employees and subsets of these groups via permission groups:

                                      • Assignment of access/visibility to spaces
                                      • Ability to create content or containers
                                      • Ability to view reports

                                      you can assign all of this via permission groups. This can be a bit tedious to manage for those not in AD, but allows you more control within Jive. Does not relate to groups visibility (AFAIK) however. Pretty good, solves some issues. I think best when combined with option 2

                                      - - - - -

                                      Option 2: Quick, easy identification of "external users" via profile/avatar overlays and profile fields, possibly badges.

                                      • I know we haven't quite done the best job of this yet on the JC here, but a few great options within Jive using badges from gamification (like:communityemployee75sqpng139d50f27ee.png), overlays on avatars (like: 24.png?a=14790) and profile fields

                                      Maybe the best way to take advantage of these would be to combine these with a light implementation of option one

                                      - - - - -

                                      Option 3: Bridge your two instances:

                                      • It sounds like you're trying to think about how to prepare for the growing consultant community or interactivity between the community of consultants and your own employees. If you already have a separate community, why not connect them via search, and have users created for each person in each community? I don't think this is most ideal short term because it can create headache for user/password management without SSO/AD, but this might be the best way to prepare for two large communities long term.
                                        • Re: Guidelines for external collaborators on internal communities
                                          tmaurer

                                          Max, as you are mentioning, we have situations where there are varying degrees of access needed. Sometimes it is only groups, and so the new feature will be great for that. Sometimes it is to both groups and spaces, and we can use permission groups for that. The hard thing about this is they are two very different mechanisms for providing access, and I'm struggling with how to make it easy for employees to know which option to use.

                                           

                                          We'll be going live on Jive 7 without this feature turned on so that we can figure out how to best manage it. We'll also have the issue of migrating some spaces over to groups in order to take advantage of the new feature once we turn it on. For a customer who's been on Jive for a long time, this is long overdue and thus is going to be painful to migrate (our legacy workaround).

                                      • Re: Guidelines for external collaborators on internal communities
                                        leightgordon

                                        Hi there!

                                        I wanted to get this discussion going again - I'm working with a client who is about to turn on this feature and we are doing some research on what others have done to update their Terms and Conditions/Usage Policy with regards to:

                                        1. those who 'own' an externally accessible group
                                        2. the external users

                                         

                                        If anyone has updated their T&C/AUP reflecting this - I love to know what you can share.

                                         

                                        Thanks!~

                                        • Re: Guidelines for external collaborators on internal communities

                                          This really is an important thread on an important topic that's not being explored deeply enough, IMO. When you start unpacking the External Contributors feature, there are an awful lot of things to consider -- more than we can manage in this thread.

                                           

                                          I set up a project where we can dive deeper into all the issues: Configuring Internal Communities for External Contributors

                                           

                                          Please join in there and let's collaborate further.

                                          • Re: Guidelines for external collaborators on internal communities
                                            dominic.fewster

                                            Hi Edward Ford

                                             

                                            Like you, but some years on, we need to create some guidelines for external collaborators. we have already conducted testing this functionality, and have the results to work with. We needed to make sure that when they join the group, external users have no access to any other part of our community outside of a specific group. We are now looking forward to using the external group’s functionality that allows users to invite external parties to participate in groups on an internal community. Before we are able to turn this feature on, we are looking into the governance side of things: Terms and Conditions/Usage Policy, which would be for both;

                                             

                                            • Those who 'own' an externally accessible group (or want to create one)
                                            • The external users themselves

                                             

                                            We need to create clear terms and conditions that have to be accepted by both, before they can proceed in creating or becoming a member of an externally accessible group.  So we would have internal guidelines, and an Acceptable Use policy for the external parties you invite to participate.

                                             

                                            Did you manage to create new governance documents “rules with guidelines” outlining how people should use this functionality? If so, it would be great to see an example of the how you structured it and what you did to cover all bases before you launched it - with everything you had to consider. Would you have a governance example that I would be able to take a look at?

                                             

                                            Thanks,

                                            Dominic

                                            • Re: Guidelines for external collaborators on internal communities
                                              nataliashcherbyna

                                              Hello,

                                              According to the Jive documentation, there is no limitation on the number of external contributors in the group. So I can invite as many people as I need without license limitation?

                                              Thank you.

                                              Best regards,

                                              Natalia.