Overview

An organizations can choose to share some of its user groups with other organizations. This can be used to allow users in the organization that shared the group (the “source organization”) to visit private worlds that belong to the organization with which the group was shared (the “destination organization”).

Use Cases

Here are two examples of uses cases for this feature.

Visiting Private Worlds in Other Organizations

Suppose there’s an organization called “Acme University”, and another organization called “The Egyptology Center”. Acme University wants its students to visit Egypt-themed worlds that belong to The Egyptology Center. These worlds are not open for public visits, so Acme University has to ask The Egyptology Center for permission to visit them. This is done as follows:

• Acme University (which is the source organization) creates a user group called “Students”. It adds the students to this group.

• Acme University sends a share request to The Egyptology Center (the destination organization).

• The Administrator of The Egyptology Center receives the share request by email, and accepts the request.

• The Egyptology Center gets a new group in its group tree, called “Students @ Acme University”. This group is automatically synchronized with the source group in Acme University so that it always contains exactly the same users.

• The Admins of The Egyptology Center add permissions to the group “Students @ Acme University”, allowing them to visit its Egypt-themed worlds.

• Users belonging to this group can now visit these worlds.

Allowing Contractors to Work on Your Worlds

Suppose there’s an organization called “Stark Industries”, and another organization called “SuperDesign”. The admins of Stark Industries want to hire the services of SuperDesign to create virtual worlds for them. This means that the users of SuperDesign need permission to view and modify the worlds. This is done as follows:

• SuperDesign (which is the source organization) creates a user group called “Stark Industries Team”. It adds to this group the users that need to be able to work on worlds in Stark Industries.

• SuperDesign sends a share request to Stark Industries (the destination organization).

• The Administrator of Stark Industries receives the share request by email, and accepts the request.

• Stark Industries gets a new group in its group tree, called “Stark Industries Team @ SuperDesign”. This group is automatically synchronized with the source group in Stark Industries so that it always contains exactly the same users.

• The Admins of Stark Industries add permissions to the group “Stark Industries Team @ SuperDesign”, allowing them to visit and modify the worlds that they’re supposed to be building.

• Once the work is complete, Stark Industries deletes the group “Stark Industries Team @ SuperDesign”. Then, the users in that group can no longer visit Stark Industries’ worlds.

Details

A shared group in the destination organization (e.g., “Students @ Acme University”) is called an External Group, because it comes from a different organization. The users in an external group are called Authorized External Users.

A source group can be shared with up to ten destination organizations.

How to Share a User Group

Go to the Permissions tab of the group you want to share, and click the highlighted button:

Open

The following dialog will open up. Enter the destination organization’s “short name”, and optionally a message. You should get the organization’s short name from your contact at that organization (the short name appears in the organization’s Settings page).

Open

Once you click “Send request”, an email will be sent to the destination organization. When an Admin in that organization accepts your request, the group will become Shared.

In the source organization, a shared group looks like this (in this example, the destination organization is called “Acme Corp”):

Open

In the destination organization, a shared group looks like this (in this example, the source organization is called “Moon”):

Open

Either organization can choose to unshare the group by clicking on the “X” button shown above.

Subgroups

Subgroups in the Source Organization

A source group is allowed to have subgroups. These subgroups aren’t visible in the destination organization, but their users are included in the destination group. This lets the source organization organize its groups without revealing them to the destination organization. For example, perhaps the source organization has a group called “Students”, with subgroups called “Class A” and “Class B”. The destination organization will not know that the subgroups “Class A” and “Class B” exist, but their users will still be included in the destination group “Students @ Acme University”.

Subgroups in the Destination Organization

External groups always appear in the groups tree of the destination organization under a group called ”Authorized external users”.

The destination organization is allowed to create its own subgroups under the “Authorized external users” group. This is useful for organizing its external groups. For example, suppose the destination organization accepts students from many other organizations, and the organization’s Admins don’t want to have to configure the permissions for each of these groups separately. So they create a group called “All Students”, and give that group the necessary permissions to visit its worlds. Then, whenever the Admins accept an external group they place it under the “All Students” group, and it automatically gets the necessary permissions.

What Can Be Done with Shared Groups

The source organization and the destination organization have different capabilities with regards to the shared group:

Both the source organization and the destination organization can add and remove permissions in the shared group. However, they can add different permissions:

How the Source Organization Can Limit Permissions in the Destination Organization

Notice that the table above doesn’t show a way for the source organization to control what its users can do in the destination organization’s worlds. Usually such control isn’t necessary: it’s enough that the destination organization can control what the external users do in its worlds.

However, sometimes the source organization might also want to exert control. For example, perhaps it wants its users to be able to visit external worlds, but not to modify them (even if the destination organization would allow the users to modify its worlds). This level of control is possible as follows:

When a shared group is created, the source organization automatically gets a new world group named “Authorized worlds @ Destination Organization”. By default, the shared group gets full permissions over this World Group. But the source organization can choose to remove some of these permissions, thus limiting what its users can do in the destination organization’s worlds.

In other words, a user only gets those permissions that both the source organization and the destination organization agree upon. Since by default the World Group described above gets full permissions, this means that normally it’s only up to the destination organization to choose which permissions the shared users get. But if necessary, it is possible for the source organization to control (remove) these permissions as well.

“Authorized External Users” vs “External Users”

These two terms appear similar, so to prevent confusion here’s how they are different:

Authorized External Users are users who belong to shared groups, as described above. They are called “Authorized” because they belong to the organization (temporarily), and they have received explicit permissions to visit the organization’s worlds.

External Users are random users who have visited the organization’s worlds. They do not belong to any of the organization’s groups. They were able to visit one of the organization’s worlds because it has the permission that allows all External Users to visit it.

The Admins of an organization can view its Authorized External Users in the regular users table. In contrast, non-authorized External Users don’t appear in the users table. They can only be seen if they visit one of the organization’s worlds. Then, they appear in the Visits and History tables.

Viewing User Details

In the Organization Admin Console, you can click on any user’s name to get more information about the user. One of the details that is shown is the user type: “Organization user”, “Authorized external user”, “External user”, etc. But note that the user type that you see is the current type, which means that it can change over time.

For example, suppose an Authorized External User visits one of the organization’s worlds. When you view the user's information, her type will say: “Authorized external user”. But if later the user’s group is unshared and then you view her information again, the type will change to say: “External user”. That’s because the user isn’t affiliated with the organization anymore.