Higher Logic's MemberClicks integration works through requesting and receiving data from the Memberclicks API.
The integration will iterate between the assigned attribute values for that contact. For example, if a contact has the attribute SCHOOL with the values Maryland, Ohio, and Harvard, it would create three communities: Maryland, Ohio, and Harvard.
IMPORTANT: Make sure that each Contact's data are correct in MemberClicks and that they are not disabled in Higher Logic. This will ensure that your users are in the expected demographic, community, security group, etc. in Higher Logic.
Use the Display Data button on the Sync Backend Database page to see what data Higher Logic is receiving from MemberClicks.
Establishing connections
Higher Logic requires the following information in order to create a connection to a MemberClicks instance:
- OrgId
- Client Id
- Client Secret
Higher Logic service endpoints
Member Refresh pulls all information necessary to refresh of a user.
- https://{MemberClicksOrgId}.memberclicks.net/api/v1/profile/{legacyContactKey}
Periodic Refresh pulls a list of all users who have been modified since the last periodic refresh. Higher Logic searches for users in MemberClicks with a [Last Modified Date] that has been updated since the last refresh.
- https://{MemberClicksOrgId}.memberclicks.net/api/v1/profile/search
Member Refresh & API calls
Member Refresh calls the method on the MemberClicks API at:
https://{MemberClicksOrgId}.memberclicks.net/api/v1/profile/{legacyContactKey}
This returns to Higher Logic all profile data required to sync each individual, including profile info, community groups, security groups, and demographics.
Below are the API calls that each refresh type uses and how often; these are estimates only.
- The Periodic Refresh uses 1 API call every 30 minutes.
- The Member Refresh uses 1 API call per refresh.
- The Meeting Refresh uses 1 API call every day.
EXAMPLE: Assume that a Periodic Refresh returns 5 users that have to be updated in Higher Logic. The Member Refresh has to run for each user to be updated. The Periodic Refresh API call plus the 5 Member Refresh API calls totals 6 API calls.
User base information
In the tables below, the Default AMS Field column contains the standard MemberClicks field we expect to contain the corresponding data value. If the parameter in the HL Configuration Param column exists for the tenant, it override the value in the Default AMS Field.
| Field | Default AMS Field | Higher Logic Use |
|---|---|---|
| Legacy Contact Key | memberKey | The unique identifier for the user |
| Member Id | [Member Number] | the member id for the user. This is a secondary identifier for the user. Legacy Contact Key is the primary identifier and will be used for all refreshes. |
| Is Company | IsCompany | boolean value that indicates whether this is a company account |
| Birthday | Birthday | If the birthday is before the year 1900, it will not be set |
| Age | N/A | this is read from age in Memberclicks if it is set, otherwise if the birday is set, it is calculated based on the birthday. |
| Remove Flag | [Deleted] | A user will their RemoveFlag set to true in HL if one or more of the following scenarios are true:
|
| Prefix Code | [Name | Prefix] | The user’s prefix |
| First Name | [Name | First] | First name of the user |
| Middle Name | [Name | Middle] | Middle name of the user |
| Last Name | [Name | Middle] | Last name of the user |
| Informal Name | Nickname | user’s nickname |
| Gender | Gender | user’s gender |
| Suffix Code | Suffix | user’s suffix |
| Email Address | [Email | Work E-mail] | user’s email address |
| Designation | Designation | user’s designation |
| Ethnicity | Ethnicity | user’s ethnicity |
| Company Name (if Company record) | Contact Name | If the record is a company, “contact name” from MemberClicks is used as the Company Name |
| Company Name (if Individual record) | [Organization] | The primary organization associated with an Individual in MemberClicks |
| Company Legacy Contact Key | OrgId | |
| Company Title | Title | A job title for the user |
| Address.Address 1 | [Address | Work | Line 1] | |
| Address.Address 2 | [Address | Work | Line 2] | |
| Address.Address 3 | [Address | Work | Line 3] | |
| Address.City | [Address | Work | City] | |
| Address.State Province Code | [Address | Work | State] | |
| Address.Postal Code | [Address | Work | Zip] | Looks at the addresses coming over, and looks at the one marked as “primary“. This is postal code for this address |
| Address.Country Code | [Address | Work | Country] | Looks at the addresses coming over, and looks at the one marked as “primary“. This is the country for this address |
| WebsiteUrl | Primary Website | a website URL that is assigned to an Individual in MemberClicks |
| Member Since Date | [Join Date] | This is a timestamp that is saved to the contact object, and not necessarily tied to any specific security groups. This field is often used for Automation Rules. |
| Membership Expires On | [Expiration Date] | This is a timestamp that is saved to the contact object, and not necessarily tied to any specific security groups. This field is often used for Automation Rules. |
| Phone 1 | [Phone | Work] | Work phone |
| Phone 1 Type | Work | By default, the “Work” phone number from MemberClicks will be phone 1 in HL |
| Phone 2 | [Phone | Direct] | Direct phone |
| Phone 2 Type | Direct | By default, the “Direct” phone number from MemberClicks will be phone 2 in HL |
| Phone 3 | [Phone | Fax] | Fax phone |
| Phone 3 Type | Fax | By default, the “Fax” phone number from MemberClicks will be phone 3 in HL |
| Phone 4 | [Phone | Mobile] | Mobile phone |
| Phone 4 Type | Mobile | By default, the Mobile” phone number from MemberClicks will be phone 4 in HL |
| AMS Directory Opt Out | DirectoryOptOut | A boolean (checkbox) field which will opt the contact out of showing in the directory. |
Community Memberships
Higher Logic’s MemberClicks provider adds community memberships by reading in the custom attributes coming over from the Profile endpoint for each user.
Attribute Community Groups
| HL Community Field | AMS Field | Notes |
|---|---|---|
| LegacyGroupKey | {attributeName “-” attributeValue} OR attributeValue | attributeValue by default but it can be configured to be {attributeName "-" attributeValue} Also, any white space will be removed. For example, the LegacyGroupKey for Interest Group would be "InterestGroup". |
| GroupRole | “Member” | group role will always be “Member”. This is hard coded. Group roles do not come over from MemberClicks. |
| GroupName | {attributeName “-” attributeValue} OR attributeValue | attributeValue by default but it can be configured to be {attributeName “-” attributeValue} |
| GroupType | attributeName | groupType will be based on the name of the attribute from Memberclicks which contains this community group value. |
| GroupDescription | {attributeName “-” attributeValue} OR attributeValue | attributeValue by default but it can be configured to be {attributeName “-” attributeValue} |
| SinceDate | null | No since date is set. |
| StartDate | null | Users are in this group until this attribute value is no longer returned in the MemberClicks API response. |
| EndDate | null | Users are in this group until this attribute value is no longer returned in the MemberClicks API response. |
Security Group Memberships
Higher Logic’s MemberClicks provider adds security groups memberships based on member types and attributes received from MemberClicks.
Member Type Security Groups
NOTE: These groups are created by default, but this is configurable.
This group is created based on the attribute [Member Type], which is a standard attribute that comes over from MemberClicks.
| HL Community Field | AMS Field | Notes |
|---|---|---|
| LegacyGroupKey | [Member Type] | Member type of user in MemberClicks |
| GroupName | [Member Type] | Member type of user in MemberClicks |
| GroupType | “MemberType” | The group type will always be “MemberType” for this type of group. This is hard coded. |
| GroupDescription | [Member Type] | Member type of user in MemberClicks |
| GroupRole | “Member” | The group role will always be “Member” for any member of this type of group. This is hard coded. Groups roles do not come over from MemberClicks. |
| SinceDate | [Join Date] | User’s join date in MemberClicks |
| StartDate | [Join Date] | User’s join date in MemberClicks |
| EndDate | null OR [Expiration Date] | null by default, but can be configured to use [Expiration Date] |
Attribute Security Groups
These groups are created based on the configuration parameter MemberClicksSecurityListAttributes, which is a comma separated list of attribute types that contain security groups as their values.
NOTE: An attribute type can contain a list of multiple values that each can be used to add users separate security groups.
| HL Community Field | AMS Field | Notes |
|---|---|---|
| LegacyGroupKey | attributeValue | the value inside the given attribute, minus any white space is set to be the LegacyGroupKey |
| GroupName | attributeValue | the name of the given attribute |
| GroupType | attributeName | the name of the given attribute, minus any white space is set to be the GroupType |
| GroupDescription | attributeValue | the name of the given attribute |
| GroupRole | “Member” | The group role will always be “Member” for any member of this type of group |
| SinceDate | null | |
| StartDate | null | |
| EndDate | null |
Staff Security Group
There are two ways to add users to a staff security group:
- Based on their parentUid/OrgId
- If a match is found between OrgId and the keys in the list, the user will be added to the “Staff” security group.
- Based on email domain
| HL Community Field | AMS Field | Notes |
|---|---|---|
| LegacyGroupKey | [Member Type] | |
| GroupName | [Member Type] | |
| GroupType | “MemberType” | |
| GroupDescription | [Member Type] | |
| GroupRole | “Member” | |
| SinceDate | [Join Date] | |
| StartDate | [Join Date] | |
| EndDate | null OR [Expiration Date] | null by default, but can be configured to use [Expiration Date] |
Custom Demographics
Custom Demographics are pulled from the Memberclicks API using the Profile endpoint. Any “attribute” in the profile response can be treated as a demographics. Based on the type of data in the attribute, it has to be added to one of the corresponding configuration parameters.
Field type
- Standard
- Free Form
- Collapsed Check Box
Standard (Pick List)
| HL Community Field | AMS Field | Notes |
|---|---|---|
| Demographic Value | Attribute.Value | This is the value of the Attribute. HL allows for multiple values to be sent for one standard type demographic (picklist) |
| LegacyDemographicTypeKey | Attribute.Name | Name of the Attribute in MemberClicks (with spaces removed) |
| Demographic Name | Attribute.Name | Name of the Attribute in MemberClicks |
Free Form
| HL Community Field | AMS Field | Notes |
|---|---|---|
| Demographic Value | Attribute.Value | This is the value of the Attribute. Free form demographics are usually unique string values being sent from MemberClicks. |
| LegacyDemographicTypeKey | Attribute.Name | Name of the Attribute in MemberClicks (with spaces removed) |
| Demographic Name | Attribute.Name | Name of the Attribute in MemberClicks |
Collapsed Check Box
| HL Community Field | AMS Field | Notes |
|---|---|---|
| Demographic Value | Attribute.Value | This is the value of the Attribute. Collapsed checkbox values allow from multiple separate demographic types to be created based on a single Attribute sent from MemberClicks. |
| LegacyDemographicTypeKey | Attribute.Name | Name of the Attribute in MemberClicks (with spaces removed) |
| Demographic Name | Attribute.Name | Name of the Attribute in MemberClicks |
Periodic Refresh
The periodic refresh works through Higher Logic calling MemberClicks API Profile endpoint and getting returned a list of users that have had changes since the last periodic refresh. These keys are then taken and a member refresh is run for each. More info on these endpoints can be found in the Establishing Connections section of this document and the MemberClicks endpoint help documentation. See: How does the integration work?.
Single Sign-On
The SSO between MemberClicks Oasis and Higher Logic works by using the MemberClicks OAuth endpoint. “Authorization Code Grant Type” must be granted by you and the redirect URL should be configured to be the Higher Logic Thrive Community site URL.
The user provider should be set to MemberClicksUserProvider.
Installation requirements
The sign-on URL must be provided and should resemble:
https://[Client MemberClicks Portal/Site]/account/login.aspx?ReturnUrl=
Confirm this by visiting this URL and making sure log-in prompt is shown.
MemberCentric/API authentication
The Memberclicks Integration supports MemberCentric.
In addition to the “Authorization Code Grant Type,” you must confirm that “password” flow is enabled for Membercentric authentication to work.