Encompass Enterprise Structure

Follow

Overview & Key Terms

Encompass Enterprise is the leading online engagement platform for organizations with multiple business entities that have specific online needs, but also need to share common constituent data. Encompass Enterprise is structured so each entity (community) can manage and execute an online strategy with its own uniquely branded website and set of tools for content management, email marketing, online giving, event management, membership management, and social networking integration. The Encompass platform allows an organization to maintain better data integrity across the institution.

Encompass Enterprise is a long-term scalable solution that can benefit schools of all sizes. It improves data integrity by managing all data from a reliable, centralized database and allows top-level administrative control. Enterprise also enables collaboration and administrative communication by utilizing common elements across the organization, but still allowing sub-communities control over online engagement efforts to their specific constituents. For more information about which Encompass Enterprise configuration would work best for your institution, please contact your iModules Account Manager.

Top Level

The top level is where all data resides and where site-wide settings are configured. Those with administrative rights to the top level have access to all data in the centralized database. The top level determines the core set of profile fields that will be used by all sealed sub-communities, as well as respective access rights. Whenever profile field or profile data changes are made at the top level, those changes affect all sub-communities.


The top level can be configured in two ways.

  • The first is as an administrative data layer which is used when the top level doesn’t have a need to engage constituents as its own entity and therefore doesn’t require community attributes.
  • The second option is a primary community, which is when the top level exhibits community attributes such as the need for a website, email marketing, or an online directory. Both options store all data, determine site-wide settings and have the capability to add, edit, or delete data.

All data lives in the top level (GID=1) community and new members are pushed to their respective community through an overnight process. This overnight process is based on a sub-community query.
 

Sealed Sub-Community

A sealed sub-community refers to a business unit such as a department, region, affiliated school or college, chapter, or club. Sealed sub-communities do not have access to the data of other sub-communities, unless specifically configured by the top level. Sub-communities allow an organization to engage multiple constituent groups while using a single Encompass platform with one database.  Sub-communities have the ability to house unique content, branding, data, email marketing, groups and administrative capabilities within the larger Encompass Enterprise platform. Scope of use can vary from entity to entity and core modules are enabled as needed. For example, one sub-community may need an online directory and event management capability, while another focuses on email marketing and fundraising. Sub-community configuration is flexible and can change as strategy evolves over time.


Configuration Options

Configuration #1: Administrative Data Layer & Sealed Sub-Communities

The primary role of the administrative data layer is to keep and maintain the integrity of an institution’s data. This configuration works well when an institution has one department that is responsible for all data collection and management, but doesn’t need the capability of engaging with constituents. It is also a good choice when only a select few at the institution need access to all data.

The administrative data layer option allows for the highest degree of flexibility for organizations that plan to have sealed sub-communities at some point, but only need one for now. This configuration establishes an administrative data level and builds a single sub-community until the institution is ready to add more sub-communities.

Configuration #2: Primary Community & Sealed Sub-Communities

With this configuration, the primary community houses all of the data and has attributes of its own community such as a website or directory. The primary community also controls configuration settings for what will be shared across all communities and what settings will be uniquely applied to each sub-community. 

A benefit of the primary community configuration is the ability to centrally manage communications and branding across an institution. For example, the University of Tennessee Alumni Association created separate sub-communities for each of their campuses to better relate to their respective alumni. Each campus and school has its own look and feel incorporating a logo with the campus name, colors, and feature articles and events specific to that location.

 

 

 

 

Have more questions? Submit a request