Managing Users and Groups

Generally speaking, when you add user and group accounts using the admin console, you're adding that data to the same database used to store content. By default, even if your community uses an LDAP or Active Directory database (or some custom solution), the users you add through the admin console will be added to the application's database and not the external data source. (For information on connecting an external LDAP or Active Directory system, see the LDAP and Active Directory Guide.)

A user account represents a person using the application. Each user account has associated content, including the person's profile. For all users, you can use the console to change their user name and password, view and delete the content they've created, and view and edit their profile information. You can also disable a user, such as when they're no longer involved, but you want to hang on to their content.

A group account collects user accounts, typically in order to make it easier to grant all of the collected users certain permissions. For example, you might create a group of human resources workers so that you can give them (and only them) permission to view potentially sensitive information about employees in a "Benefits" space.

You can manually add new user and group accounts. When you go to add a user account, you'll enter basic information, including user name, "friendly" name, email address, and password. You'll also specify whether to send the new user a welcome email. (For more on the template a welcome email is create from, see Managing Email Templates.)

By default, if your community uses LDAP or Active Directory to manage users, new user accounts you create from the admin console will go into the local application database (where content is stored). You will be able to edit user account properties for LDAP-managed users if your LDAP provider allows it (by default, it isn't allowed).

You might define the user groups you'll need before launching the space. For example, group users according to employee job function or department. User and Group permissions can be assigned on a space or sub-space basis.

If you've set up the application to allow people to register on their own, you can moderate those new registrations. (A system administrator enables both user registration and moderation for new registration requests.)

When someone registers (usually by filling out the registration form defined by the system administrator), you'll get a chance to approve or decline their request. In the end user UI, click Your Stuff > Items Awaiting Approval. On the Pending Approvals tab of your profile, view the list of requests. You can click the person's name to view a profile page with the information they entered. Click Approve or Decline for each request. If you decline, you can enter your reason before finishing.

Jive SBS includes a database for storing data about people and groups you add. But you can use another system instead, including LDAP, Active Directory, or a custom system. You choose a user data system when you're setting up the application with its setup tool; you can't specify or configure a system in the admin console.

You'll find a full guide for connecting to a user data system in the LDAP and Active Directory Guide.

You can also set up the application to synchronize data between its database and your external user database. On the User Data Synchronization Settings page, you can enable synchronization and set how synchronization is done. This feature helps you ensure that the local application database only contains data related to users who are in your external (LDAP or Active Directory, for example) database. For example, you can disable the account of a person whom your external database shows as no longer enabled.

You can edit information included in a user or group account.

For user accounts, you can also list and delete a person's content through the admin console. The User Summary page will list user accounts. You can also use the User Search page to find them (which is helpful if your list of users is very large). Once you've found the user account you want to edit, click the account name to view its properties. You can change profile information, password, even view and delete the person's content.

By default, if your community uses LDAP or Active Directory to manage user and group accounts, you won't be able to edit the account properties that the external database manages. At a minimum, this is the account name and password, but could include others as well. The properties you can edit are the ones stored in the local database.

When you want to remove access for a particular person but keep their content in the system, you can disable their account. When you disable someone's account, Jive SBS will replace their former avatar with a special avatar that features a strikethrough; the word "Disabled" will appear on their profile. The person will no longer be able to log in or receive notifications, but their content will remain viewable in the application.

You can define relationships between people in your user database. The relationships you define will be visible in people's profiles. Using these relationships, people can stay on top of what certain people in the community are doing, including their changes to content, status messages, and so on.

People can be part of two kinds of relationships:

• organizational relationships, such as a reporting relationship at work.
• "friend" or "following" relationships that they create themselves. The difference between those two depends on user relationships have been configured to be unidirectional or bidirectional:

  Direction	Description	Example
  Unidirectional	A unidirectional relationship is one in which one person declares a relationship with another person, but the other person isn't invited to reciprocate (although they can separately create a similar relationship with the first person). Unidirectional relationships might be suited to situations where a reciprocal (bidirectional) relationship would be inappropriate or burdensome for the second person.	Someone working in a particular area is interested in keeping up with the work of another person who is doing research in that area. The first person clicks a link to "follow" the researcher. The researcher has no particular interest in following the person following them, so they needn't be prompted to follow the first person. If approval is required, the researcher receives the request and decides whether to approve it and let the first person follow them; otherwise, the unidirectional relationship is created automatically.
  Bidirectional	In a bidirectional relationship, one person's relationship declaration creates (or at least invites) a relationship that goes the other way. Bidirectional relationships might be useful for communities in which people's personal relationships are less hierarchical, or are less specialized.	Someone with a particular interest notices that another person has similar or complementary interests. The first person clicks a link to "add as a friend" the second person. If approval is required, the second person receives the request and decides whether to approve it and become a friend of the first person; otherwise, the bidirectional relationship is created automatically.

Depending on your user relationship settings, people can also help to create the relationships using the end user interface. For example, a manager can add other people as direct reports through a link in each of those people's profiles.

Click Retire to break the connection between two people.