17 Replies Latest reply on Feb 22, 2015 9:29 PM by kmehnert

    Contractor access to your internal community?


      Hi! We're working on our first launch of Jive to our beta testers in a couple of weeks and to the entire company at the beginning of March. I'm curious on how some of you have managed access for contractors in your Internal Communities?

      Some background

      - We're an oil & gas company so we have a variety of contractors who work on our projects

      - Contractors are assigned a company email address


      Are you creating special permissioning groups? How are you training your group moderators when and if contractors should be invited to join private/secret groups?


      Any feedback is appreciated!



        • Re: Contractor access to your internal community?

          We do allow contractors in, and follow two different paths:

          • Treat some contractors like employees and give them general access
          • Treat some contractors with care, and restrict their Jive access to specific spaces using permission groups


          We aren't currently using the external contributors feature because we've been working around the lack of that feature for a long time and don't currently have the resources to change how we approach this.


          There are several different threads in here about the external collaborators feature and important considerations, if that is a route you are looking at. Hopefully, that works for you, as I can tell you that our workaround is high-touch, confusing to staff, and cumbersome at best.

          • Re: Contractor access to your internal community?

            Lanie - we can fence them in/off if they are in a group in AD.

            • Re: Contractor access to your internal community?



              Some lessons we have learned when turning on the External Contributor feature.


              1. You mentioned that your contractors are assigned company email accounts. That could be an issue as you need to define a list of domain(s) in the admin console which is then used against the email address when you invite someone to the community. If the email domain is not in the list you defined then they are treated as external contributors.  This is from the Admin Console:  "...When users are invited by email address to an externally accessible group, email addresses that don't match the list will be invited as external contributors, with access only to groups they've been invited to...."

              Our contractor use their personal or respective parent company email addresses for registration.


              2. Once you turn the 'External Contributor' feature on ALL users will be prompted to choose whether they are employees or External Contributors.  This sets a cookie so they are not prompted to make this selection again - that is until the cookie expires (I think 30 days).  Not a big deal but it does add another layer before your employees can login.



              • Re: Contractor access to your internal community?

                Hi Lanie - I'm in oil & gas as well, and as it happens, we (Nexen/OOGC) are in a JV with Chesapeake as well...we should talk I bet we could do some interesting things...


                In short, yes we absolutely do allow contractors in. However, we do distinguish at times some that require secure access to specific information only, as per legal agreements, joint ventures, etc. We use External Users for those purposes. Contractors that are provisioned a user account, also sign off on our internal confidentiality policies, and specific terms are written into their contracts. This is not specific to Jive, but instead, outlines ownership of information created as a contractor, as well as confidentiality of information obtained while working here. As an additional measure, acceptance of our internal privacy and confidentiality policies are spelled out in the terms & conditions that must be accepted upon first login to Jive.

                Once in Jive with a Nexen account, they are treated as a regular user. No special permissions groups. However, external users are provided access only to the specific groups that they require.

                As for training group owners of private groups - the same discretion is required whether they are a contractor or an employee. Verify that there is a legitimate business reason for requiring access to a group containing sensitive information.


                1 person found this helpful
                  • Re: Contractor access to your internal community?

                    Chris Dittrick This is perfect feedback! Our EVP/General Counsel had some questions. We have a variety of groups with active directory now and our contractors with Chesapeake accounts - but I think I'll follow up with him regarding the language in the confidentiality agreements, etc. and make sure that we address it properly in the TOS/User Agreement as you have done.


                    External communities may come in the future but we have no specific plans at this time as we're deploying for knowledge sharing but first anticipate accommodating an expansion of the "communities of work" through Spaces/Groups first.


                    And we definitely need to talk! I bet we could share some good stories and set the bar for business partner collaboration in O&G! But we should probably launch our internal instance first...


                    Thanks again for this feedback. It's GREAT!

                      • Re: Contractor access to your internal community?

                        No problem at all. If you would like, I am sure I could share some of our Terms & Conditions. In some of my discussions with legal, we have had to take extra care around the term "employee" and "employment relationship." We had to make sure ours applied to employees, contracted staff, and 3rd party contractors. If you can think ahead to external users, that will save some time in revisiting the user agreement in the future. We had to update ours when we enabled external groups.


                        However yes, a question we are often asked is who else is doing this in our industry - if there's anything I can do to help you make your case, or share some of our success stories, I'd be happy to.


                        BTW I like how you think! Setting the bar for O&G collaboration - no small feat! Why not! 

                      • Re: Contractor access to your internal community?

                        Lanie and Chris


                        Thinking we need to start an Oil and Gas / Energy group.  I'd love to talk with you more about your use of Jive.  We have JiveX and go live in 2 weeks.  I'd love for you to share us with your employees.  We're open to the industry.  www.pinkpetro.com

                      • Re: Contractor access to your internal community?

                        All of our contractors have access to our Jive instance. Heck, our two (awesome) developers are contractors, so we couldn't do it without them! I am at a Fortune 500 Bank/Finance industry company.

                        • Re: Contractor access to your internal community?

                          Anyone with a Lexmark username has access to our instance, which includes contractors.  Once they are in the environment, we don't wall off any areas.  Their access to content is the same as regular employees and decided on by the space/group owner.


                          Contractors sign an agreement when they are brought in which pretty much covers all our IT systems.  I can't think of any it doesn't cover, actually. 

                          • Re: Contractor access to your internal community?

                            Hi Lanie! I'm in the middle of implementing this exact same use case at AGS. Right now, we're utilizing the external user/externally accessible group indicators, and am training the external group owners to establish a cadence of exporting the group member list to excel and sending it to HR at the supplier/client company to confirm current employment.


                            I don't think I'm going to go down the permissions group road, because I would end up with 100+ permissions groups that would only be used in one case, and only makes sense in spaces.