Like what you see? Have a play with our trial version.

Group visibility in multi-organization environments

From Yellowfin 9.4, groups can be set to be visible at both the primary organization and all of its client organizations. This tool is best suited to independent software vendors (ISVs), who provide Yellowfin functionality to their own clients, and who may benefit from using standardized group names. It may also be useful for primary organizations with many client organizations, where client orgs are administered centrally from the primary org. 

Note that this functionality is not available in Yellowfin instances without any client orgs: the functionality by its nature needs at least one client org.

Roles, groups and sub-folders

A user can be assigned only one role within Yellowfin, which may be restrictive when roles are used to assign content. One of the benefits of having groups visible at client orgs is that a user can be assigned to multiple primary org groups, allowing a more granular result for content access. By making primary org groups visible at client orgs, a user can be given access to sub-folders at the primary org level and the client org level.

The key to using client org-visible groups at the primary org is to add roles rather than users. Take the example diagrams below, where a primary org and its client orgs use roles such as Executive and Sales. By creating groups (‘Execs only’ and ‘Sales’) which can combine these roles from the different orgs, these groups can be used to assign content access at the sub-folder level.

In this example, only users with the role of Executive have been added to the ‘Execs only’ group, whereas users with the roles of Executive and Sales have been added to the Sales group. The next diagram reflects the visibility of information, based on the above group memberships.

Ash at Client Org 1, who has been assigned the Sales role, has access to the Sales subfolders at both her Client Org 1 and at the Primary Org. However, Ash cannot see any of these folders at Client org 2 because she is not a user at Client org 2. 

In comparison, Kim at Primary Org can’t see any of the sub-folders in any client org because she is not a user at those client orgs. She can, however, see both sub-folders at Primary Org because she’s a member of both the ‘Execs only’ and ‘Sales’ groups.

Managing client-visible groups

At the primary org

Groups visible to all client orgs are first created within the primary org. Yellowfin administrators can add:

  • individual users (only those created at the primary org will be visible, and if they are members of any client orgs, their membership to this group will only give them visibility to content at the primary org);
  • user roles (including users from client orgs if they’re members of the primary org roles); 
  • other user groups (from the primary org only); and,
  • LDAP groups with access to Yellowfin.

A group visible to all client orgs is created, managed and deleted from the primary org. In addition, group member usernames are only visible within the org where they were created. For example, the name of a user created at client org A is not visible when viewing the group in the primary org; and the username of a user created at the primary org is not visible when viewing the group in any client org.

At the client org

Groups visible to all client orgs cannot be managed in any way from a client org. Client org administrators can view the group members, which, from their client org Admin panel, will only display the usernames of users created within that client org or via LDAP.

Client org users can assign these groups as recipients for broadcasts, alerts and sharing, as well as add them to sub-folders at the client org. Only users from the same client org will be added as recipients.

Functionality overview


Primary org administrators

Client org administrators

Primary org typical user

Client org typical user

Create a group visible to all client orgs


Delete a group visible to all clients orgs


Add users to a group visible to all client orgs


Only users created within this primary org can be added

Add LDAP groups to a group visible to all client orgs


Any LDAP groups can be added

Add roles from the primary org to a group visible to all client orgs


Roles that include users from client orgs are included 

Add roles from the client org to a group visible to all client orgs

Add primary org groups visible to all client orgs to other primary org groups visible to all client orgs


Add groups from the client org to a group visible to all clients orgs

View group members


Only users created within this primary org, or LDAP users with access to this org, will be displayed


Only users created within this client org, or LDAP users with access to this org, will be displayed

View group members from other orgs (ie, view entire group membership)

*Add group as recipients to broadcasts, alerts etc.





*Content within a client org will only be shared with users who have access to that client org, regardless of group membership. A user from client org B who is a member of a group shared with client orgs A and B will never see content from client org A — unless the user is a registered user at client org A as well. 

Make a group visible to all orgs

Making a group visible to both the primary org and all clients orgs is straightforward. However, we recommend you prepare your user data first, using the information above as a guide, then check that the group is working as expected for users at client orgs. You might also like to read more general information about user groups, including descriptions of each of the options described in the instructions below, on the User Groups wiki page.

  1. Login to your primary org as an administrator
  2. On the left-side navigation pane, click on Administration, then Admin Console
  3. Click on the User Groups section to expand it

  4. Open an existing group or create a group using the Add button
  5. Fill in the group details, then click on the check box for Group Visibility
  6. Add any primary org roles, including any that are used as client orgs
    In the example below, we’ve added a role called ‘HR’, which includes members from each client org with an HR role
  7. Add any primary org users and primary org groups to give them access to content visible to this group at the primary org (and remember that adding primary org users and groups to a client-visible group does not grant access to content at client orgs)
  8. Add any users, roles or groups to exclude
    In the example below, we've excluded the 'Executive' role to uphold HR content privacy: anything visible to this HR group will not be visible to anyone with the Executive role, even if they're added as member of this group.

    Note that in the example above that we've added the user, System Administrator. If we were to add a group to the list which included the same System Administrator user, and then we excluded that group from viewing content, the System Administrator would lose access to this content too. Make sure you structure your user groups carefully!

Always check the group results are what you expect to see in your client orgs.

  • No labels