Configure Account Model Settings

Settings for Managing Your Account Model

The type of container Account associated with a Contact—either Administrative or Household—is controlled by these org-wide settings in EDA Settings.

When you've decided on your preferred, primary account model, verify all of these settings so that the correct kinds of container Accounts are created for Contacts. Keep in mind these guidelines.

• For many orgs, the default values are fine as they are.

• For orgs choosing a primary account model different from the out-of-the-box default value (Household when the default is Administrative), change the value in Default Account Model.

• For orgs that have custom record types for Administrative or Household Accounts, specify those custom values in these settings. For example, if you have a custom Administrative Account record type called Student Account, change Administrative Account Record Type to Student Account. If your preferred, primary account model is Administrative, also change Default Account Model to Student Account.

Note Even though you can have only one preferred, primary account model, it's fine to have a mix of Contacts in your org—some with Administrative Accounts and some with Household Accounts. When creating Contact records, follow the workflow that creates the appropriate type of container Account. Refer to details in Contact.

Verify or Change the Default Account Model

The Default Account Model setting specifies your preferred, primary account model. Between Administrative and Household, you must pick a favorite. Out of the box, Administrative is the default value. In other words, whenever you create a new, independent Contact, an Administrative Account is created automatically as the Contact's container Account.

Verify that the current setting matches your intended configuration. If you have a custom Account record type for your preferred, primary account model, specify that custom record type as the Default Account Model. Changes apply only to Accounts created after the change, not existing Accounts.

1. On the Education Cloud Settings tab, in Education Data Architecture, click Settings.

   

   Note If you don't see the Education Cloud Settings tab, access it from App Launcher. For details, see Education Cloud Settings.

2. In EDA Settings, select Account Model and verify the Default Account Model setting.

3. To change from Administrative to Household Account or vice versa, or change to a custom record type:

   1. Click Edit.

   2. Select a valid value for container Accounts. Educational Institution or Business Organization aren't valid record types for container Accounts.

   3. Save your changes.

Verify or Change the Record Types Used for Administrative and Household Accounts

The Administrative Account Record Type and Household Account Record Type settings must specify values that are different from each other to ensure data integrity. Verify the current settings for both. If you're using a custom Account record type instead of the default Administrative or Household Account record type, then change the corresponding Account record type setting. Changes apply only to Accounts created after the change, not to existing Accounts.

1. In EDA Settings, select Account Model.

1. In EDA Settings, select Account Model.

2. Verify the values selected in Administrative Account Record Type and Household Account Record Type. Make sure that they each specify a unique record type.

3. To change either setting to a custom record type:

   1. Click Edit.

   2. Select the custom record type.

   3. Save your changes.

For details about creating custom Account record types, refer to Account.

Things to Know About Container Versus Parent Accounts

We recommend using container Accounts for all the Contacts at an institution—students, faculty, and staff. In limited cases however, if data management needs for faculty and staff are simple and low volume, it's possible to use parent Accounts for these Contacts instead of container Accounts. The parent Account is typically the one that best represents a Contact's primary function. For example, the Account representing the Math Department could be the parent Account for each of the school's math teacher Contacts.

If you go this route, avoid overloading parent Accounts with too many child Contacts. Let's consider the data volume implications of these sample approaches.

• If the Math Department is the parent Account to a dozen teachers: As the years pass and teachers come and go, the Account's child records increase in number, eventually growing to hundreds of Contacts before the school archives older records.

• If the school's top-level Educational institution Account record is the parent Account to all faculty and staff: As the years pass, the Account's child records could eventually grow to number in the thousands before the school archives older records.

In either case, with these kinds of data volumes, changing ownership or sharing for just one record can involve thousands of calculations to update records throughout the data hierarchy. All these calculations take time and can cause performance issues.

For extra credit: If you're wondering why it's non-negotiable that a Contact have either a container or parent Account, the Salesforce security model is the reason. A Contact without a parent Account is considered private, which means the Contact record is visible only to the person who created or owns the record and to admin-level users. It can't be shared with other users who have a legitimate business need to access the Contact's data, and this limitation can lead to data quality issues. For example, if a Contact record exists but isn't visible to one of those users, the user could create a duplicate record without realizing it's a duplicate.