The Enterprise platform allows an organization to share only relevant data with each entity and maintain better data integrity, while also allowing each entity to operate with its unique set of administrative tools.  Within the solution architecture, there are top-level platform configuration settings that all communities must share and other configuration settings that can be uniquely applied to each sub-community.

• Features unique to each community
• Shared features across all communities
• Sub-community Profile Inheritance Configuration Options
  • Encompass Configuration Considerations and Best Practices
    • Configuration options available at the STEP level
    • Configuration options available at the CATEGORY level
    • Configuration options available at the FIELD level

Features unique to each community

• Directory Search - When a constituent or admin searches the directory, they search only records that are members of that Sub-community.
• Directory Search Configuration - Unique data fields that make up the directory search in the sub-community (For example, the Law School can have data fields that are centered on search criteria unique to a law school grad).
• Constituent Admin - Unique set of constituent admins.
• Content Admin - Unique set of content admins.
• Content - Unique site map and content pages.
• Events - Events created in a sub-community are unique to that sub-community.
• Campaigns - Campaigns created in a sub-community are unique to that sub-community.
• Forms - Forms created in a sub-community are unique to that sub-community.
• Email Marketing - Email marketing module is unique to a sub-community.
• Groups - Groups created in a sub-community are unique to that sub-community.
• Payment Gateway Processor - Unique payment gateway processors can be configured for credit card transactions for each sub-community.
• Reconciliation Reports - Reconciliation Reports created in a sub-community are unique to that sub-community.
• Email footer - Unique email footers can be configured for each sub-community.
• Email Marketing Category Opt-Out - Unique email category opt-out can be configured for each sub-community.
• Tokens - The tokens dropdown presents a list of available tokens that were created in the sub-community.
• Profile - A unique Profile page can be configured for each sub-community.
• URLs - Unique URLs can be configured for each sub-community. For example, www.yoursite.org, sub-community.yoursite.edu, etc.
• Website Design - Each sub-community can have a design that is unique from other communities.

Shared features across all communities

Below is a list of features that are shared across all communities where the configuration settings are determined by the top-level platform.

• Profile - A core set of profile fields is defined for all sub-communities by the top-level platform. Once the profile fields are established, sub-communities can then add fields and modify the profile within their sub-community.
• Profile Data Export - Any profile field created on a profile form is available at the top-level for import/export.
• Profile Settings - These include several member and admin preferences/fields (member is deleted, member is hidden, email address is valid).
• Authentication - Authenticating to the top-level of the platform authenticates the user to all sub-communities the user is a member of.  If a user is not a member of a particular sub-community, the user cannot authenticate to that sub-community.
• First Time Login Process - Data fields configured that are displayed to a constituent during the first time login process.
• Login Fields - Fields that represent the constituent username and password.  For example:  Email address field configured as username.
• Flagged Word Filter
• Module Titles - Class Notes, Message Boards, Instant Notes, etc.
• User Added Content - Class Notes and Message Boards.
• Identity Checkpoint Merge Review Fields - These are the configuration settings that determine what data fields are available for the review process in the Identity Checkpoint merge tool.  The fields cannot be customized for each sub-community and only exist at the top level primary community.

 

Sub-community Profile Inheritance Configuration Options

Profile inheritance can be set up at the step, category and field level. iModules recommends setting profile inheritance at the highest level possible so that profile inheritance can be pushed to sub-communities in the biggest chunks possible. This makes management and maintenance of profile inheritance more manageable for admins. Setting inheritance rules on each individual field makes it easy to lose sight of what field is available in which sub-community. However, if you group fields together on one step and name the step “Law School Fields” for example, it makes it obvious at first glance that all fields on that step only exist in the Law School sub-community.

This feature adds the ability for a top-level community admin with the proper rights to define what constituent profile fields are excluded from the profile cloning process to a sealed sub-community's constituent profile. By default, all profile steps and fields are cloned to a sealed sub-community. Community Inheritance allows an institutional admin the ability to set top-level profile cloning rules at the step, category and individual field level.

Encompass Configuration Considerations and Best Practices

• Profile field property changes made at the top level will push down into the sub-community level.
• Profile data changes made at the top level affect all sub-communities.
• Profile field property changes (drop down values, field names, etc.) made at the sub-community level will push to all other sub-communities where that field exists and to the top level, with the exception of field display names which can be unique for each sub-community.
• A sub-community can temporarily rearrange profile fields in a category, but the field order will be reset when any change is made to the data/field, category, or tab at the top level primary community.
• New fields added at the sub-community level will be found in the top level primary community list of fields but not added to the top level primary community profile and can be reported on – other sub communities will not be able to see these.

Configuration options available at the STEP level

Community Inheritance

• Step does not exist in communities - Selecting this option excludes the step from rendering in all current and future sealed sub-communities. This allows the profile step to only exist in the top-level community.
• Step exists in all communities - Selecting this option automatically includes the step in all current and future sealed sub-communities.
• Hide from certain communities - This option gives admins the ability to select which specific sealed sub-communities the profile step will NOT exist in. For example, an individual profile step might only exist in the profile of a specific sealed sub-community and not in others.
• Step exists in certain communities - This option gives admins the ability to select which specific sealed sub-communities the profile step will exist in.

Community Settings

• Remove the ability to edit step settings in a sealed sub-community – Selecting this option will remove the ability for sub-community admins to delete the step in a sealed sub-community.

Configuration options available at the CATEGORY level

Community Inheritance

• Category does not exist in communities - Selecting this option excludes the category from rendering in all current and future sealed sub-communities. This allows the profile category to only exist in the top-level community.
• Category exists in all communities - Selecting this option automatically includes the category in all current and future sealed sub-communities.
• Hide from certain communities - This option gives admins the ability to select which specific sealed sub-communities the profile category will NOT exist in. For example, an individual profile category might only exist in the profile of a specific sealed sub-community and not in others.
• Category exists in certain communities - This option gives admins the ability to select which specific sealed sub-communities the profile step will exist in.

Community Settings

• Remove the ability to edit category settings in a sealed sub-community – Selecting this option will remove the ability for sub-community admins to delete the category in a sealed sub-community.

Configuration options available at the FIELD level

Community Inheritance - When adding a new or existing field to a profile step or category at the top level, the field will inherit data rules set at the step or category level.

• Field does not exist in communities - Selecting this option excludes the field from rendering in all current and future sealed sub-communities. This allows the profile field to only exist in the top-level community.
• Field exists in all communities - Selecting this option automatically includes the field in all current and future sealed sub-communities.
• Hide from certain communities - This option gives admins the ability to select which specific sealed sub-communities the profile field will NOT exist in. For example, an individual profile field might only exist in the profile of a specific sealed sub-community and not in others.
• Field exists in certain communities - This option gives admins the ability to select which specific sealed sub-communities the profile field will exist in.

Community Data Field Rules - Field Data Rules are set on the individual fields themselves.

• Field is read only to admin - Sub-community admins will be able to make changes to field properties, move the field, and delete the field from the form, but will not be able to make changes to the value in the field. (This does not make the field read only in the top level community.)
• Field is read only to constituents – In the sub-community, constituents will be able to see the field, but will not be able to make changes to the value in the field. This is commonly used for fields like Class Year or Major.
• Field properties cannot be set on this field - Sub-community admins will be able to see and move the field and change the value in the field, but will not be able to make any changes to the field settings. They will also be able to delete the field from the form, but not remove it from the system.
• Field cannot be deleted - Sub-community admins will not be able to remove the field from the profile form where it exists or delete the field from the system. Selecting this option basically removes the little red X from the field editing options.

Roles

• Roles created at the top-level inherit to sealed sub-communities if that field exists in the sub-community.
• Roles created in sealed sub-communities do not inherit to the top level or other sub-communities.

 

For more information regarding sub-community configuration, please contact your iModules representative.