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:

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:

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:

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).

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”):

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

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:

The source organization can…

The destination organization can…

Add and remove permissions in the group

Add and remove permissions in the group

Add and remove users in the group

Create and delete subgroups

Rename the group

Unshare the group

Delete the group

Delete the group (this just unshares it: the source group is unaffected)

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

Possible permissions in the Source group

Possible permissions in the Destination group

Permissions for the source organization’s worlds

Permissions for the destination organization’s worlds

Permissions for generic “External worlds”

Non-world permissions, e.g. “Upload assets”

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 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.