Multi-Division Client Accounts

Overview

This Help topic describes the different architectures available for a Engage+ client that has multiple brands or divisions. Your Onboarding team will assist you in determining which architecture best meets your business requirements.

Multi-brand accounts may warrant the use of multiple unique databases and / or a "Parent / Child" configuration. These architectures can add a great deal of complexity over a single database account configuration, and should be used only when absolutely necessary. This topic describes the business conditions and requirements that might lead you to consider a multi-brand architecture, and which architecture option to then use. This decision is usually not a simple yes / no question, as there are many factors and variables in place, many of which have to do with your internal systems and business requirements.

Note: In common usage, the term "Parent / Child" is often used to describe ANY multi-brand architecture, but that term can be a bit misleading. A "Parent / Child" architecture is actually one of the multi-brand architecture models, all of which are described below.

If your company doesn't have multiple brands or divisions, then the Single Database Account architecture should suffice.

However, if you do have multiple brand or divisions, you'll likely have to consider the different multi-brand architectures supported by the Messaging platform. Each of these options offers various advantages and disadvantages, which need to be carefully considered.

Please note that the descriptions below often refer to "access" to data. In this context, this concept has nothing to do with user access, or what records in a database that a user can view (i.e., the actual data). Instead, this concept refers to the tables and fields that each system will have access to when data is available for the system in question.

Single Database Account

The simplest option is to utilize a Single Database Account, with all of the brand / division data shared within that one database. This model supports the following functionality:

You need to view and share data (such as activity data) across brands, or you don't require the data to be segregated.
You perform cross-marketing across brands.
Loading and / or mailing volumes are such that separate accounts aren't warranted.

This option utilizes a single database, with all of the brand data stored within it. This configuration doesn't separate the brand data into distinct views. Every user in every brand can see the data from all other brands.

Typically, a client that uses this architecture will have a single Recipient table with some sort of "Brand" identifier column, or with child tables that contain brand-specific data assets. When building a Campaign, the users can create Audience Filters that utilize the "Brand" identifier information available, in order to limit the Campaign to only the desired brand (if required). One key advantage to this model is that it's easy for users in different brands or divisions to share assets and objects.

This design can get cumbersome beyond more than a few brands, especially as you may run into database contention issues when loading data.

Multiple Unique Database Accounts

The Multiple Unique Database Accounts model utilizes completely separate accounts (or Parents) for each brand or division. This model supports the following functionality.

Data must be "siloed," or separated, so that one brand can't see the other brands' data.
Large brands with high mailing volumes, frequent Campaigns, and very large databases.
Very limited sharing of data across brands.

This model removes any potential database contention issues that might arise from the Singe Database Account, or the Parent / Child architectures, where all of the brands are running against the same Parent database.

Optionally, if you need to share data across brands, such requirements can be handled via exports / imports that get passed back and forth between the different accounts. This process works for small amounts of data, but can get cumbersome for larger volumes.

Parent / Child

A Parent / Child configuration is designed around a single database (referred to as the "Parent" system) with all of the brands residing in that database, but separated into different views (each of which is referred to as the "Child" systems). When defining a Parent / Child configuration, you should consider the following questions:

Which tables should be built in the Parent system, given that multiple Child systems need to utilize data from these tables?
Which tables are Child-system specific (if any), and should those tables be built through the Parent system, or the Child system?
Which Child systems should be granted rights to which Parent system-built tables?
Which fields on a Parent system-built table, to which a Child system has a view, should be made available within the Child system?

The answers to those questions will form the basis for configuring the tables within the Parent / Child architecture.

As an example, let's say you have three brands, each of which is set up within their own Child system. Two of these brands share a Store table (which was created in the Parent system, with access granted to these two Child systems) that contains store details, location, contact information, and so forth. Brand C doesn't need to see this table as they have no brick-and-mortar stores, so that Child system isn't configured for access to the Store table or any of its fields. Additionally, Brand B doesn't use the Store table fields related to "store location" in their marketing strategy; however, Brand A does use location data in their marketing. Therefore, these specific location-related fields would not be made available within the Child system for Brand B.

At this point if the Solution Architect does NOT leverage any of the advanced configuration features of the Parent / Child architecture (described below in more detail), then all records loaded to the Store table, as well as the related fields that are shared by multiple Child systems, will be accessible to those Child systems. Users of each Child system would utilize and see the same shared data assets.

However, in some situations, you may want to share the same general table architecture, but you want only a subset of records from a given table to be available for each Child system, and / or they may want certain values for a specific field to be Child-specific. For example, multiple brands may have the same order entry system which allows them to utilize the same table structures to store that data, but you may want brands to have access only to orders and items carried out for the brand in question. Additionally, brands may sell the same items, but pricing on those items may be different by brand, and you may want to make sure that the price of an item is unique by brand.

To support these more complex scenarios, the Parent / Child architecture has several different configuration features that can be implemented at a very granular level: Table Configurations, Unique Child Data, Hierarchy Options, and Hierarchy Rules, all of which are described below.

Table Configurations

When defining Tables and Fields within Messaging, the platform provides several different options related to the Parent / Child architecture:

Create a Table at the Parent-level, for use by the Parent system only.

Create a Table at the Parent-level, and share the entire Table with one or more Child systems.

Create a Table at the Parent-level, and share only specified Fields with one or more Child systems (note: each Child system can be granted access to a different set of Fields).

Create a Table at the Parent-level, and define a Child-level Field within it, for use by that Child system only.

Create a Table at the Child-level, for use by that Child system only.

Unique Child Data

A key risk to "shared" data across multiple Child systems is when more than one Child system has access to the same record, but values for a given field or set of fields from the record in question are specific to each Child system. This configuration could potentially create an issue where one brand overwrites the data provided by another brand.

To prevent this situation, the platform provides a field-level setting within the Messaging interface called "Store values in this field per child system." This setting appears on the Tables screen when you drill into a specific field. When this option is checked for a field, and data is loaded directly into the Child system, none of the other Child systems will have visibility into that value. This feature allows you to store unique Child-specific values for a given field, or set of fields. See Create a New Data Field for more information on how to enable this setting.

The following example illustrates the flexibility of leveraging Unique Child Data.

Let's say your client has two brands, each of which is set up within their own Child system. Both of these brands share a Product table that contains SKU level details, such as size, color, unit price, and so forth. Both of these brands have tremendous cross-over in terms of the products they sell, but they sell those specific products at varying price points. For example, Brands A and B both sell the same red shirt. Therefore, both of these Child systems have access to the Primary Key for that product. However, these two brands don't sell that red shirt for the same price. Brand A sells it for $19.99, and Brand B sells it for $24.99.

You would need to enable the "Store values in this field per child system" flag for the "Price" field on this table. This flag allows you to store Child-specific values in this field. In this example, Brand A would store "19.99" in the Price field, and Brand B would store "24.99" in this same field.

Note: This bottom-up configuration feature requires that data being loaded into a field where the "Store values in this field per child system" flag has been enabled be loaded directly through the Child systems. Therefore, this input data must be provided in distinct Child system files.

Hierarchy Rules

Hierarchy Rules are a top-down configuration feature set in the Parent system that determine which records from a given table a Child system can access. This feature creates a distinct database "view" (or subset of records) relevant for each Child system(s). To leverage this configuration option, all data is loaded through the Parent system. During the import process, Hierarchy Rules are utilized to "tag" a Primary Key in order to make it visible to a Child system (or potentially, to more than one Child system). The assignment of data to a Child system (or systems) can be as simple as looking at one value in one field (for example, a "Brand Code" identifier), or a more complex rule based on a Filter that looks at a more complex set of conditions.

A user working within the Parent system has access to all data within all Child systems (except data contained within tables and / or fields built directly within, and loaded directly to, a Child system). However a user working within a Child system can't see Parent-level data, nor can the user see any data in any of the "sibling" views.

The following example illustrates the flexibility of Hierarchy Rules.

Let's say you have three brands, each of which is set up within their own Child system. Two of these brands (A and B) share a Store table that contains store details, location, contact information, and so forth. Brand C doesn't have brick-and-mortar stores, and therefore they don't need to see this table.

This Store table is created within the Parent system, and Brands A and B are given access to this table, but each Brand has its own unique set of stores. Therefore you could limit access to brand-specific stores, by establishing which Child systems can access which Primary Keys on the Store table. This configuration would allow each Child system to see only the Store table records that were relevant to their brand, instead of seeing all available Store table records.

As you can see, Hierarchy Rules let you establish which Child systems have access, or a view, to which records in a given table, to which the Child system has been granted access.

Hierarchy Options

Messaging offers several different methods of importing data into the platform – regularly-scheduled FTP transfers (see FTP Import Templates), one-off FTP transfers (see Manual Imports), API messages (see Data Management APIs), and Web Forms.

When data is loaded to a given system (either to the Parent or to a Child), the data can always be viewed by that system. Additionally, if data is being loaded to a Parent system, then the platform allows you to select a Hierarchy Option. The Hierarchy Option tells the platform what Parent-level data can be viewed by which Child system(s).

The available Hierarchy Options are:

Update Current Customer Only: This option will load the data to the Parent system only (the data will be viewable only through the Parent).

Update Current Customer and Children: This option will load the data to the Parent system, and to all Child systems as well. The data will be viewable by the Parent and all Child systems that have access to the table and fields in question.

Custom Hierarchy Rules: This option let you create complex, custom rules for how data is loaded and shared with Child systems; see the section above for more details on Hierarchy Rules.

Note: The Hierarchy Option you select applies only to the target table into which data is being loaded. If this table is joined to other tables in your database, the Hierarchy Option will NOT be applied to those joined tables.

Combination

As described in the above examples, it's possible to combine the Unique Child Data and Hierarchy Rules features within the same client account. By combining these features, along with the ability to configure the tables within the Parent / Child architecture at a very granular level, you can create a very complex, sophisticated architecture that allows you to isolate and share specific fields and / or tables, as needed, in order to meet your business requirements.

Back to Getting Started with Messaging