The integration between your Association Management System (AMS) and your Higher Logic Online Community site drives object creation from the up-to-date member data that you already track in your AMS. The integration pulls data (contact info, membership status, and database-managed demographics and communities) from your database and populates them on your community site via a synchronization process. This AMS-and-community integration ensures that your members interact with the most current data, thereby boosting member participation, collaboration, and retention.

After the integration is set up, you don't need to perform any additional work to ensure that the data reflected on your community site remains synchronized with your AMS. Given that Higher Logic is only a consumer of data from your AMS, a periodic check (Periodic Refresh) for changed records in the AMS, coupled with a comprehensive refresh of each updated record (Member Refresh), yields a robust integration.

NOTE: See the View Your Data Sync Details article to learn more about viewing your Higher Logic site's integration data details.

Periodic Refresh

To ensure that data on your Higher Logic community site remains synchronized with your AMS, our Periodic Refresh synchronization application will query your AMS with a predetermined frequency with the date and time of the last successful periodic refresh that returned changed records. The AMS will return a list of records that have changed since the passed date-time by unique identifier (e.g., customer key, member key / id). The Periodic Refresh application will insert these records in the Refresh Queue to be processed by the Member Refresh.

The frequency of the Periodic Refresh can vary, but thirty (30) minutes has proven to be a successful interval in creating a constant load on the member refresh. This frequency prevents redundant refreshes stemming from multiple changes to a record completed in a single session.

Additionally, if you have licensed Event Calendar or Event Manager, there should be a method implemented on the client side to allow Higher Logic to periodically fetch changed Events for populating your Community Calendar.

NOTE: Sample responses for these two methods are available in Sample A: GetChangedMembers Response and Sample B: GetChangedEvents Response.

Member Refresh

The Member Refresh is at the center of the entire integration: It ensures all AMS-managed objects on your Higher Logic site remain synchronized and up to date. The Member Refresh occurs in three instances:

1. Asynchronously via the Periodic Refresh
2. A member’s record is also refreshed asynchronously if a member logs out and back into the community site
3. A member is refreshed serially when a member logs in and is either found not to have a corresponding record on the community site or has a disabled record. This prevents members from being able to participate in the community due to information the Periodic Refresh hasn’t been able to identify as updated.

The Member Refresh has three parts:

• Refresh Member Details
• Refresh Member Community Groups
• Refresh Member Security Groups

1 - Refresh Member Details

Refreshes basic demographic information:

• Name Prefix
• First Name
• Middle Name
• Last Name
• Nickname
• Suffix
• Name Credentials
• Up to four (4) phone numbers by type (e.g., Home, Primary, Fax, Work, Mobile)
• Email address
• Address (three street address lines, City, State/Province, Postal Code, Country Code)
• Custom search and/or network demographics
• Personal Website URL
• Social Media Sites

2 - Refresh Member Community Groups

The Community object on your Higher Logic site drives membership and access to many of the features on the site, including Discussions, Libraries, and Microsites. Each AMS-integrated community has a unique identifier, display name, and limiting logic on the Higher Logic side that controls which users can view and access community content. Only the members of a community, as determined in the AMS, can view its associated Library and Discussion (unless Super Admins expand access).

Communities are driven by Community-Memberships determined at the time of the Member Refresh, and should have a term component to manage who is a member and for what specific period of time. Each Community Membership has a begin date, end date, and community role.

Communities are of a certain Community Type (e.g., Committees, Chapters, Special Interest Groups) and integration logic is implemented per Community Type.

Implementations vary broadly as far as what type of AMS objects translate well to Higher Logic Communities, and it is highly dependent on your business needs, but you should consider any relationships stored in your AMS that may provide value to your members (e.g., communicating directly with each other, sharing best practices, and resource files are good examples for a community). Additional examples are Sections, Divisions, Registered Events, and even the purchase of specific items / publications where the buyers obviously share a common interest in a topic.

For future extensibility, we recommend sending as many communities as you envision ever needing in the future and allow us to limit communities by Group Type and Group Sub Type on the Higher Logic side as your business needs dictate at any given time. This filtering is configurable by a support member on our team, and allows you to change what objects are brought over by the integration as your business needs evolve without requiring that code be changed; this also means you will not incur any task order charges.

3 - Refresh Member Security Groups

You can think of Security Groups as “Roles” your members belong to. They are a powerful tool for limiting viewing of and access to navigation and content items on your Higher Logic site.

Your users are broadly batched into Security Groups, and can even belong to multiple Security Groups. By default, your site includes the following four Security Groups:

• Authenticated - Any logged-in user (they may or may not have Member status).
• IsMember - An aggregate of AMS-managed security groups. Content and functionality is routinely protected to Members as a benefit of membership. Those with IsMember privileges also belong to the “Authenticated” Security Group.
• Public - Any user who is not logged in.
• Higher LogicAdmin - Global administrators (Super Admins) with universal access and editing privileges.

If your organization has membership types that don’t fit into these default Security Groups, you can add additional Security Groups, designating IsMember status as needed. The most common additional Security Group is “Staff,” which is assigned to employees of the organization. Others include “Associate Member” or “Student Member.”

Keep in mind, though, that it’s not necessary to create specific Security Groups for your communities, as only members of a particular community can access its associated Discussion and Library, by default. For example, it’s not necessary to create a “Board of Directors” Security Group if the aim is to restrict access to a Discussion that’s already a feature of the “Board of Directors” Community.

Appendix A expands on this concept and provides a flow for how Security Groups can be used to both limit access to the site and define the aggregate “IsMember” Security Group.

Single sign-on and authentication

Higher Logic has developed standard SSO methodologies with many different AMSs.

Keeping in mind that there is broad variability in SSO implementations, stemming from the fact that we strive to use your existing third-party enabled SSO and Authentication solutions whenever possible, the most common solutions include:

• Credential Authentication - A user control on your Higher Logic site accepts a user name and password that are resolved to the same member key used by the data integration. You will provide the resolution method (most often a web service method). Higher Logic does not store passwords; the credentials are passed through to your authentication service. This method provides authentication on the Connected Community site only and is therefore not a cross-asset SSO.
• Browser Session Variable - The Login link on your Higher Logic site redirects to a login page on your main organization website where authentication is performed, and either a domain cookie is dropped and the user is redirected back to the community site or a query string parameter is added upon redirection back to your Higher Logic site. The query string parameter is required if your Higher Logic site and your login page are on different domains, and is recommended if you are licensed for our Microsites module. This method allows for cross-asset SSO. This process must adhere to the following specifications:

1. The login page must accept a Return URL parameter
2. Your Higher Logic site and the login page must be on the same domain if using a cookie
3. The value of the variable should be the unique identifier (member key / id) used by the data integration or be able to be resolved to the same, whether through pre-shared-key encryption/decryption (implementable through .NET on our side) or a web service method that can be called to resolve the value of the variable to the member key.

If your account licensed for any of our mobile app options, a basic credential authentication must be implemented on the client's side, even when your Higher Logic site is implementing SSO.

Again, since there is so much variability in how clients implement SSO and / or Authentication, our product is very flexible in this respect and we would be happy to further discuss alternative implementations.

Determining access & member status

Sample A: GetChangedMembers response

Sample B: GetChangedEvents response