Galaxy Link is a new technology that enables two or more Connect platforms to share data with each other. Platforms can choose to share (or not share) the following types of data:
- Content: agencies, needs, events, advanced-event needs, and users
- Response Content: agency fans, event RSVPS, and need responses
- Reporting Data: information that shows up only in the Reports area
The Galaxy Link can be used for a variety of sharing relationships, including:
- A state site and local sites
- A volunteer center and various local nonprofits
- A United Way and local corporations
- A volunteer center and local campuses
As long as both parties have Connect software, and as long as both parties are in agreement regarding the nature of the sharing relationship, they can share information so that volunteers have a variety of opportunities that are catered to their needs and preferred causes.
This article covers data sharing from three different perspectives: how a shared site might look like to a volunteer, how sharing works for agency managers and how shared data looks to site managers. For information on how initiatives and user groups are shared across sites, see this article.
A Note on Terminology: This article uses the term remote when referring to an agency, need, or event that originated on one site but is being displayed on another. It uses the term local when referring to an agency, need, or event that is being displayed on the site on which it originated.
How to Turn On the Galaxy Link
If you wish to share data with another Connect platform, contact Galaxy Digital's Support Team. You and all other sites in question will be asked to provide documentation (such as a data-sharing agreement) confirming that all parties agree to the data-sharing relationship.
Once we have received this documentation, one of our Customer Care agents will turn on the connection for you.
A volunteer who is using a site with shared data will be able to see whether a need, event, or agency originated from another site. The volunteer can respond to any remote need or event, or fan any remote agency, as long as it's displayed on their site. The steps involved in that response may vary, depending on the settings; see Responding to Remote Content.
If a volunteer is using a site that receives content from another site, they will see a "Brought to you by ..." message on any remote agency, need, or event.
This message appears at the end of the Details area for needs and events, and below the "Who We Are" and "What We Do" section an an agency's profile page.
The phrase "responding to remote content" refers to fanning a remote agency or responding to a remote need or event. When a volunteer responds to remote content, one of two things will happen, depending on the site's sharing setup: The volunteer may be redirected to the remote site, or the volunteer may be able to respond to the remote need on their local site.
Responding on the Remote Site
If a site is not set up to open remote opportunities locally, a volunteer who responds to a remote need will be redirected to the site where the need originated. To respond, the volunteer must first log in to (or sign up for) the new site.
Note: The volunteer is first asked for permission to be redirected. They are taken to the new site only after they have clicked Yes to be redirected.
Because the volunteer is responding to a need on a new site, they will see any custom questions that have been added for that site. Because they are no longer on the local site, they won't see any local custom questions.
Responding on the Local Site
If a site is set up to open remote needs locally, the volunteer remains on the local site and completes the need response there. They will see the “Brought to you by …” message, but the experience will otherwise "feel" as if they are simply responding to a local need.
If the local site has added custom questions for needs, the volunteer must answer the local custom questions, even if the need itself is from a remote site. Any custom questions added by the remote site will not be visible to the volunteer who is responding on a local site.
A volunteer must log their hours on the same site where they responded to the need. So, if a volunteer responded locally to a remote need (i.e., they responded to a remote need without leaving their home site), they should log their hours locally (i.e., on their home site).
An agency's needs, events, and profile can "flow" from the originating (local) site to other sites, so long as:
- a Galaxy Link is in place, and
- a site manager does not opt to block the data from being displayed on a remote site.
Once a site is publicly displayed on a remote site, any remote user can respond to it. Below are the things an agency manager can and cannot do regarding remote responses and hours submitted for their agency's needs.
If an agency manager has a special request that a need or event be displayed (or not displayed) on a remote site with a Galaxy Link, they may need to communicate that with the other site’s manager.
Note: In most cases, all agency profiles, needs, and events are shared by default with remote sites.
An agency manager can delete their agency's need responses, regardless of where the response originated. An agency manager cannot, however, add a response on behalf of a volunteer from another site; they can only do so for users whose accounts are registered on the same site as the agency.
An agency manager can delete, approve, or decline any hours submitted for their agency’s needs, regardless of where the need response originated. An agency manager can also add hours on behalf of any volunteer who has responded to a need, regardless of where the response originated. In other words, if a remote user responds to a local need, that local agency manager can add hours on behalf of the remote user.
When viewing data from the site manager panel, a site manager with a Galaxy Link can easily see which agencies, needs, events, advanced events, users, responses, and hours originated on the local site, and which are flowing in from a remote site. The site manager can also see the other sites' data in reports (accessed on the Reports page) if the site is set up to aggregate reporting data. A site manager has some ability to manage remote data—but not to the degree that they have with local data. The rest of this article outlines the site manager's ability to view and manage remote data shared via the Galaxy Link. It also touches on how the Email Blast can be used to communicate with both local and remote users.
In the tables of data in the site manager panel, a site manager will see specially colored rows to indicate which items are flowing in from another site. For example, a site manager viewing needs (Volunteerism > Needs) will see its site’s needs with a white background and all other sites’ needs with a blue background.
If the site manager does not want to display a need from another site, they can click on the need and select not to share it. The need will then show up with a red background.
Continuing with this example, if a site manager does not want to share a certain need (or agency or event) with another site, they can mark it as such. The need (or agency or event) will not show up on the other site at all—not for the volunteers, and not on the manager panel.
Note: Another site's users do not appear in the user-management area (Volunteerism > Users); however, another site's users will appear as applicable in the responses-management area, the hours-management area, the lists of event RSVPs, and the lists of agency fans.
Site managers are limited in how much they can manage data that is flowing into their site from another site. They can block certain data from being displayed on their site, and they have some control over need responses, event responses, and volunteer hours submitted from another site.
Blocking Data from Another Site
To block a remote agency, need, event, advanced event, or advanced-event need from being displayed on your site:
- From the admin panel, open the item you want to block.
- For the Show the ... need on my site setting at the top of your screen, toggle to OFF.
- Click Submit.
Once an item is blocked, it appears in the applicable table with a light red background.
In this example, "Amazing Test Agency," which is flowing from a remote site, has been blocked from the local site. (In contrast, "Awesome Test Agency" has not; anyone who visits the local site can see that remote agency.)
Note: By blocking a remote agency's profile from appearing on your site, you also block all of its needs and events.
Note: If the site manager of the remote agency opts to block the agency from flowing to your site, you will not see it (or its needs or events) anywhere on your site manager panel. The same goes for any remote needs, events, advanced events, or advanced-event needs that the remote site manager has blocked.
If your site is set up to aggregate reporting for multiple sites, you will be able to see users from all site in your user-management area (Volunteerism > Users). Users from other sites will be shown with a blue blackground, while users from your sites will have a white background.
While you can view the name, email address, and other basic user information for users from other sites, you cannot edit their accounts, and you cannot use the Assume Identity feature to log in as them.
You can, however, filter users by domain, which means that you can export a spreadsheet of users from other sites, and you can email users from other sites with the Email Blast tool.
To filter users by domain, run a filter on User Data > Domain > is and then select a domain and click Submit.
A site manager can view remote events but cannot edit those events (beyond selecting to block an event from being displayed on the front end). Depending on the source of the event and the RSVPs, the site manager has some ability to edit and delete RSVP data.
Remote Event, Local RSVPs
When viewing a remote event from the site manager panel, a site manager can scroll down to see all RSVPs submitted by local users (i.e., the users who are registered on that site manager's site). Not visible are any RSVPs to the remote event that were submitted from the remote site.
A site manager can delete and edit all local RSVPs to a remote event. Because remote RSVPs are not displayed, the site manager has no ability to edit or delete RSVPs submitted from the remote site.
Local Event, Remote RSVPs
If an event originated on your site, you can view, edit, and delete any RSVP to that event, regardless of where the RSVP was submitted from. All RSVPs from remote sites appear with a blue background, while all RSVPs from the local site appear with a white background.
A site manager can view remote needs but cannot edit those needs (beyond selecting to block a need from being displayed on the front end). Depending on the source of the need and the responses, the site manager has some ability to edit and delete need-response data.
Remote Need, Local Responses
When viewing a remote need from the site manager panel (Volunteerism > Needs) a site manager can scroll down to see all responses submitted by local users (i.e., the users who are registered on that site manager's site). Not visible are any responses to the remote need that were submitted from the remote site.
From Volunteerism > Responses, a site manager can delete or add hours for any local response to a remote need. Because remote responses are not displayed, the site manager has no ability to edit or delete those.
Local Need, Remote Responses
If a need originated on your site, you go to Volunteerism > Responses and delete or add hours for any response to that need, regardless of where it originated. All responses from remote sites appear with a blue background, while all responses from the local site appear with a white background.
From Volunteerism > Responses, a site manager can add a response for any volunteer, so long as that volunteer is registered on their local site. The site manager can add responses for both local needs and remote needs that are shared with the local site.
A site manager cannot add a response for a remote volunteer (one who is registered on a different site) to any need, local or otherwise.
A site manager can approve or decline hours for both local and remote users.
- The site manager can add, approve, or decline hours for any local user, even if those hours are for a remote need.
- The site manager can add, approve, or decline hours for any remote user, so long as the hours are related to a need response for a local need.
Approving or Declining Hours
The table in Volunteerism > Hours lists all previously submitted hours from both local and remote users. To approve or decline a remote user's hours, find their name in this table and select the applicable status from the Status column.
Note: All hours submitted from a remote site have a blue background in the table.
Adding Hours for a Remote User or a Remote Need
A site manager cannot add hours for:
- a remote user who responded to a local need
- a local user who responded to a remote need
A manager from the associated agency, however, can add hours for any user who has responded to the agency's need.
If your site aggregates reporting data for other sites, your reports will have multiple sections, one for each site. In addition, you will have access to Connection Report data, located in the Reports area of your manager panel.
A site that is set up to aggregate reporting data for other sites will also have access to the other sites' users, both in their user-management area (Volunteerism > Users) and in any reports where volunteer data appears (such as "Top 50 Visitors" and "Details of Individual Hours" reports).
Note: It does not matter if this site is a hub or a portal (as in the setup for certain state sites), where the state site is the "portal" receiving data from the local sites, which serve as the "hubs."