2 Replies Latest reply on Nov 23, 2011 10:37 AM by sholmk12

    What processes do you use to manage de-registration of users?

      The scenario is an external community that is private to customers (B2B environment), and user registration is managed though a mix of email domain validation and registration moderation in order to verify that the person registering is an employee of that customer, all well and good, but, what happens when an employee of one those customers then leaves their company? their persona on this clients Jive community still exists, and they can still login.

       

      By what means have you addressed this requirement?

        • Re: What processes do you use to manage de-registration of users?
          John Schwiller

          Can we assume the company closes the email account of the employee (?) so that one method is to look at any bounce mails back to Jive. This is clearly not real-time but I use this as a guide that the account on Jive should be disabled. Doesn't cope with the situation when no emails are sent of course but maybe a once a month email ping about 'something' could be forced?

           

          Perhaps Olivia Teich has this in her sights in/for Engage Partners ?  

          1 person found this helpful
          • Re: What processes do you use to manage de-registration of users?
            sholmk12

            Hi Paul, we're running into a similar situation with our newly launched client community. Unfortunately we don't have a single signon solution at the moment, which could make our lives infinitely easier. Right now we're going to have to rely on two ways of disabling user accounts:

             

            1. Do it manually when we hear that someone is no longer with the client (this has trouble written all over it)
            2. Use the user.decay.period system property and hope that, if a member is no longer an employee of a client, they won't access the site for a period of say, three or six months, and the system will automatically disable their account.

             

            The problem with #2 is that we're assuming that someone won't access the site if they don't need to, which won't always be the case. But, we're hoping that this will capture most of the users who no longer need access, but without SSO there is no perfect solution.

            1 person found this helpful