Skip to Main Content
HCL Connections Ideas Portal

Welcome to the HCL Connections Product Ideas Lab! The place where you can submit product ideas and enhancement request. We encourage you to participate by voting on, commenting on, and creating new ideas. All new ideas will be evaluated by the HCL Product Management & Engineering teams, and the next steps will be communicated. While not all submitted ideas will be executed upon, community feedback will play a key role in influencing which ideas are and when they will be implemented.

For more information and upcoming events, please visit our HCL Connections page.

Status Needs Clarification
Created by Guest
Created on Aug 30, 2019

Allow seamless switching of users from being external to internal and vice versa

The current use case for external users does not allow seamless switching from internal to external users and vice versa, unless one switches from ID.
We would like to use the " external" attribute for internal users that do not actually use connections, but who's contact information needs to be in the profiles directory as this functions as the central directory for contact information.
When such user switches from external to internal (which happens rather often) he/she needs to keep it's ID and access should be set accordingly. This is what currently does not happen, in several components access is stuck on external-level access.

  • Attach files
  • Guest
    Reply
    |
    Sep 24, 2019

    Agree with Rene, that this might be a current violation of the current license agreement. Anyway, the described use case above could be better implemented by restricting access to Connections via a group membership (configured in WebSphere). Only group members would be able to access/use Connections and therefore count towards the Authorized User licenses. Creating profiles for all employees in Profiles via TDI would be not affected, so that you can still use Profiles application as your corporate directory. However, it could be accessed/used only by users who are member of the specific authorization group.

     

    Regarding the idea, a more concrete use case is switching external users which have become internal after employment. At the moment, you would have to create a new account/internal profile for the same user. Finally, the user has to be re-added to all communities, loosing access to previously created content. Or if employee has been created as external user by mistake, switching her to internal profile is not an easy task with default Connections tooling (without ICXT or CAT)

  • Guest
    Reply
    |
    Sep 12, 2019
    Hi Peter, do you mean that a user with an org domain email would be set to external? Currently this could violate the license agreement. Typically I’d say a PVU license would probably makes this go away - maybe we need an offline discussion for me to understand the issue better.