Version 6

    Document open for any updates by fellow members.


    Note:  The following information pertains to Jive v4.5 and below. There might be some subtle differences in Jive 5.0 that may affect decision matrix (e.g. in 5.0 there is a membership element in Spaces as well where anyone following a Space shows up on the People tab). Updates from any 5.0 users would be great!



    Decision approach from functional perspective:





    Primary Function

    B2E (business to employee)

    With the purpose of “publish and tell”

    E2E (employee to employee) with the purpose of collaboration, Q&A, document sharing, and topical conversations.

    Who can create?

    Only Jive administrators can create top-level spaces.


    Then, the designated Space Owner for a space may be given the ability to create further sub-spaces under the top level spaces.

    Group creation can be set up as 'self serviced' or 'governed'.


    Governed: The program office pre-governs and monitors the creation of new groups to prevent duplication/redundancy.


    Self-Serviced: In this model, End Users gain the ability to create Groups and own the group created. This model allows emergent patterns in an organization with little bit of 'gardening/weeding' intermittently. Program Office can monitor the emerging patterns. If some groups are not adopted well they can be disbanded. If there are groups  with  similar interest they can be linked together or merged depending  on  the  needs and objectives.

    Typical Purpose

    While users may occasionally have cross-functional needs that require them to visit a variety of spaces, they will generally spend most of their time in the space dedicated to their functional area.


    Although Spaces can be used to replicate organizational/departmental hierarchy, this is not a best practice, since it promotes siloes of information. Having said that, we found it helpful in some cases to increase adoption by driving users into their own hierarchical spaces.


    Best Practice: A space can be used for high-level crosscutting topical areas of collaboration. The can be used as an entry point or a 'lobby' (thanks to Gia who coined the term "lobby" or "lobby approach") for a certain area of interest or community. Space structures can reflect enterprise knowledge domains or strategic topics. They key driver is openness and enterprise reach.


    Such 'lobby' spaces can then have links to other smaller "Groups" or even other "Spaces" in Jive that might be talking about related topics. Think of such 'lobby' as a homepage or landing page for an enterprise wide knowledge domain.


    In some cases Space use can be beneficial if you need to 'integrate' collaboration in your business process. Jive provides web services that can allow external systems to automatically create secure access controlledspaces for certain stages in business processes.

    Groups can be used to bring people together in the kind of informal networks that form spontaneously within an organization (This can be better achieved by using the 'self serviced' approach described above).


    Groups can also be used to create departmental collaboration, functional areas, topics, projects, team based collaboration, communities of interest, practice groups, etc. Groups can also be used for ad hoc gathering around a particular topic - achieve the goals in short amount of collaborative time and then disband.


    Groups do not have a hierarchy (no sub-groups within groups). Community managers can create links to relevant groups inside the broader enterprise level Space.


    Best Practice: Groups are typically used for

    • Teams
    • Committees
    • Departments
    • Units
    • Project Collaboration
    • Communities of Interest dedicated to sharing knowledge around topics
    • Communities of Practice dedicated to sharing best practices and support


    Best practice is to keep the number of top-level spaces small. Proliferation of spaces leads to a confusing UI and the inability to figure out where exactly to place new content.


    However, if you must replicate your organizational departmental structure you can create as many sub-level spaces as you want.

    Best practice is to let users create as many groups as they want and actually allow overlap! Overtime, the active groups come to surface and allow visitors to discover the knowledge and conversations in them. The inactive ones sink to the bottom and can be disbanded by the Program office quarterly or annually.


    Another benefit of allowing end users to create as many Groups is that Group Membership appears in a person's profile, and facilitates expertise location and the discovery of similar people.


    There aren’t many differences between the features in Spaces and Groups. For example, Discussions, Documents, Blog, Categories, Projects, Polls, Announcements, Events etc.

    Groups have all of the functional tools of a Space e.g. Functionally, there's hardly any difference.


    One minor difference is that Groups have the 'group email' feature where you can send a broadcast email to all group members.


    There is no membership element to a Space. They are usually open to everyone in the organization.


    Although Spaces can be restricted for access it is not generally recommended due to a lot of maintenance overhead and complexity. If you are creating a Space hierarchical structure for a department, it is very natural for the units to ask for a 'sub space with restricted access'. This can mushroom into a lot of private/public mix and hard to maintain and monitor as people come and go. If there is a certain group of individuals in a department/unit that would like to discuss things privately, it is best to create a Private or a Secret "Group" instead of a "Space".

    Group Owner can invite or remove members from a Group.


    Groups have a strong membership component, unlike spaces – there is a Members tab, in fact. Members can feel 'belonging' to a group.  Because of this, groups are a great way to uncover pockets of like-minded people within the organization, and provide an opportunity  for them to discover one another.


    There is membership for all four Group Types, including Open, Members Only, Private, and Secret (details here).  There is always a 'Members' tab in a Group that shows members of that group.


    Members can join or leave groups. Everyone can join or ask to join a Group depending on privacy settings of the group. For secret/restricted groups users don't see them in general listing or search, the group owner must invite a user to join.

    Permission Control

    Permissions control in a Space is very much granular. Program Office/Admins can specify who can do what in a Space. E.g. who can Read, Write, Comment/Reply etc.


    If the requirement is to create a private area for collaboration with very specific granular level permissions settings then a Space would do the job.

    Permission control is not as granular as in Spaces. A designated Group Owner has the ability to invite or remove members from that group. All members in the Group will be able to read/write/comment etc.





    Here's another decision approach primarily from permissions perspective:


    Collaboration type


    Public collaboration


    (with concepts like 'invite', 'join', 'can view but not contribute etc.)



    Use group types like Open or Members Only.


    (with heirarchy)


    Public + Private

    (With heirarchy and some privacy needs among some sub areas/units/teams)

    Space + Group


    Lobby approach i.e.

    • Top level Space as entry point.
    • Some subspaces, but make sure to keep all subspaces as Public. Subspaces should be used for some main themes/topics in the community.
    • Use Groups to create private areas for teams/units or managers who may want to have private discussions
    • Use  "Social Groups" widget or "Lobby Widget" to show aggregated contents  from the related groups in the community lobby (i.e. 'bind' the related Groups with the community lobby page)




    (with very granular permission requirements)



    Use the granular permissions available in the admin console.

    (Note: May be rarely used. We haven't experienced granular permissions so far)