1. Configuring Applications Using Application Composer
  2. Access Parent Data When Creating Subtab Records

Access Parent Data When Creating Subtab Records

When you add a subtab to any "parent" page, you can also configure the subtab to default parent data into new records.

This means that when your users create a new subtab record, one or more fields can be automatically populated with data from the parent record. This capability is available when the subtab is based on either a standard or custom object, and it's available for both related object subtabs and child object subtabs. This topic describes how you set this up.

Relationships and Subtabs

Two objects can be related in either a one-to-many relationship or in a many-to-many relationship. Relationships are useful because they let you associate one object's records with the records of another object. For example, maybe your users want to track the trouble tickets that get created for an account. You enable this association between records first by creating a relationship between the objects, then by creating the subtabs.

Accessing Parent Data from Subtabs

When a user creates a new record on a subtab, you can choose to have values from the parent record automatically default into a field on the subtab. You must manually enable this capability by writing Groovy to pull data from one field into another field.

To enable this capability, use the Groovy AfterCreate trigger to access parent object data. The trigger will copy parent data to the new record created on the parent object's custom subtab. You must add this Groovy, as follows:

  • If the subtab is based on a one-to-many relationship:

    • Add Groovy to the "many" object.

  • If the subtab is based on a many-to-many relationship:

    • Add Groovy to the intersection object.

Let's look at the following examples in the next section.

Groovy Example for a One-to-Many Relationship

You have a Vehicle subtab on the Account object. When your users create a new Vehicle record on this subtab, you want to populate the new Vehicle record with the Account's city from the City field of the Account object.

To enable this, create an AfterCreate trigger on the Vehicle object with the following code:

setAttribute('AccountCity_c',Account_AccToVehicle_Src?.PrimaryAddressCity);

  • AccountCity_c is the target field on the Vehicle object that you want to populate with the value from the Account object's City field.

  • Account in Account_AccToVehicle_Src? indicates the source object from which to pull the data.

  • AccToVehicle in Account_AccToVehicle_Src? is the name of the 1:M Account to Vehicle relationship.

  • PrimaryAddressCity is the source data from the Account object that you use to populate the AccountCity_c target field on the Vehicle object.

Groovy Example for a Many-to-Many Relationship

You have a Country Club Membership subtab on the Account object. When your users create a new Country Club Membership record on this subtab, you want to populate the new Country Club Membership record with the Account's city from the City field of the Account object.

To enable this, create an AfterCreate trigger on the AccountCountryClub intersection object with the following code:

setAttribute('AccountCity_c',Account_AccToCountryClub_Src?.PrimaryAddressCity

  • AccountCity_c is the target field on the Country Club Membership object that you want to populate with the value from the Account object's City field.

  • Account in Account_AccToCountryClub_Src? indicates the source object from which to pull the data.

  • AccToCountryClub in Account_AccToCountryClub_Src? is the name of the M:M Account to Country Club Membership relationship.

  • PrimaryAddressCity is the source data from the Account object that you use to populate the AccountCity_c target field on the Country Club Membership object.

Subtabs Based on Self-Referencing Relationships

In the case of self-referencing object relationships, both 1:M and M:M, it's not possible to access parent object data when creating records in custom subtabs. For example, it's possible to have the same object (such as Trouble Ticket) as both the source as well as the target of a 1:M or M:M relationship. However, when creating new records in a subtab for such a relationship, parent record data can't be accessed.