The integration between your Higher Logic Thrive Community (Thrive Community) site and your Association Management System (AMS) or Customer Relationship Management (CRM) system is what drives object creation and ensures data accuracy in your Thrive Community site.
Your AMS/CRM is the database of record (the "authority") for your members' data (such as contact information, membership status, and database-managed demographics and communities). Member data is managed and updated there so that when the integration pulls that data in order to populate your Thrive Community site, you know that the data are current.
AMS/CRM data are pulled via a synchronization process. This synchronization ensures that your Thrive Community members interact with the most current data.
After the integration is set up, no additional work is required; it's all automated. The integration ensures that the data on your Thrive Community site remains synchronized with your AMS/CRM. Given that Higher Logic is only a consumer of your AMS/CRM data, a periodic check (Periodic Refresh) for changed records, coupled with a comprehensive refresh of each updated record (Member Refresh), yields a robust integration.
See View Your Data Sync Details to learn about viewing your Thrive Community site's integration data details.
Periodic Refresh
To ensure that data on your Thrive 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 customer site to allow Higher Logic to periodically fetch changed Events for populating your Thrive 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:
- Asynchronously via the Periodic Refresh
- A member’s record is also refreshed asynchronously if a member logs out and back into the Thrive Community site
- A member is refreshed serially when a member logs in and is either found not to have a corresponding record on the Thrive Community site or has a disabled record. This prevents members from being able to participate in the Thrive Community due to information the Periodic Refresh hasn’t been able to identify as updated.
The Member Refresh has three parts:
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 Thrive Community 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 that your members belong to. They are a powerful tool for limiting viewing of and access to navigation and content items on your Thrive Community site.
Your users are broadly batched into Security Groups, and can even belong to multiple Security Groups. By default, your Thrive Community 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.
Keep in mind 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.
Process: determine access & member status, below, provides a view of how Security Groups can be used to limit access to the site and to define the aggregate IsMember Security Group.
Single Sign-On and authentication
Higher Logic has developed standard Single Sign-On (SSO) methodologies with many different AMS and CRM databases.
NOTE: Are you planning an SSO implementation with Higher Logic? If so, your implementation project may require a one-time fee for configuration and testing. Reach out to us to learn more.
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 Thrive Community 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 Thrive Community site only and is therefore not a cross-asset SSO.
- Browser Session Variable - The Login link on your Thrive Community 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 Thrive Community site or a query string parameter is added upon redirection back to your Thrive Community site. The query string parameter is required if your Thrive Community 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:
- The login page must accept a Return URL parameter
- Your Thrive Community site and the login page must be on the same domain if using a cookie
- 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 licenses any of our mobile app options, a basic credential authentication must be implemented on your side, even when your Thrive Community site is implementing SSO.
Again, since there is so much variability in how customers implement SSO and / or Authentication, our product is very flexible and we are happy to discuss alternative implementations.