Supported use case

Experience Cloud supports one use case for using sub-records: surveying multiple entities within the same survey, for the same unit. For example, your survey could ask the same questions about multiple restaurants at a hotel, or the same questions about multiple products sold at a retail store. A survey record can have multiple sub-records. For example, a large resort might want to ask questions about multiple restaurants and multiple theaters in the same survey. In that scenario, you would configure one sub-record for the the restaurant questions and another sub-record for the theater questions.

Experience Cloud does not support other use cases, including surveying for multiple units within a sub-record. For example, Experience Cloud does not support having the first five questions of a survey associated with one unit, and the next five questions (which are different questions) associated with a different unit. In this scenario, the record itself would be associated with both units, so anyone with access to either unit would be able to see the entire survey.

Contact your Medallia expert if you have a desired end result that does not meet the supported use case.

Examples

Consider the following examples for different industries.

Hospitality example

Consider a hotel that has three restaurants on its property. Most of the questions in the survey are about the hotel. However, you can use a sub-record to collect feedback about each of the 3 different restaurants at the hotel. The questions for the restaurants are the same (overall satisfaction with the restaurant, speed of the restaurant, and so on), and the company can view aggregate data for the restaurant questions.

Automobile sales example

Dealerships are often interested in the reason a buyer rejected or accepted a sale from a different dealership. For example, they might want to understand why a consumer purchased a car at the San Francisco dealership as opposed to the Palo Alto dealership. Typically, sales surveys ask a set of questions about each rejected dealership in addition to questions about the dealership where the sale was made.

Retail example

A retail company might want to ask about multiple products in a single relationship survey, where the unit is the account and the list of products is dynamic per account.

Design surveys to accommodate sub-records

You can design your survey in different ways to make use of sub-records. These designs are the most common:

1. The survey taker selects all possible entities with which they interacted, and then chooses the entities for which they would like to provide more feedback.

   • Entity page 1 — Survey taker is asked to select from a set list the entities with which they interacted.

   • Entity page 2 — Of the selected entities, the survey taker chooses the entities for which they want to give feedback, up to a maximum number. This requires JavaScript in the survey.

   • Entity page 3 — The survey taker is asked more questions about the selected entities from page 2.

2. The survey taker selects all possible entities with which they interacted, and the survey asks more questions for 1 or more of those entities (determined randomly).

   • Entity page 1 — Survey taker is asked to select from a set list the entities with which they interacted. The survey selects (at random) from those entities up to a maximum number. This requires JavaScript in the survey.

   • Entity page 2 — Survey taker is asked more questions about the entities selected entities.

3. Entities are known ahead of time and provided in the invitation file. In this case, on any page the survey taker is asked more questions about the entities listed in the file.

Use sub-records in reports

Data in sub-records is supported in many, but not all Experience Cloud reports. Only the reports listed in this section support data in sub-records.

Responses List

You can use multi-valued fields tied to sub-record in Responses List reports to display them in an organized table format:

Responses Form Profile section

You have two options for displaying sub-record data on the Responses Form Profile section:

• Use the original Unit data fields and Feedback fields that populate the multi-valued K-fields, as you would normally add fields to the Profile section. Be sure to turn on the HideUnanswered property.

  

• Use the multi-valued K-fields that are tied to a sub-record in the Responses Form Profile section, and the fields automatically display in a table format.

  

Satisfaction

You can use multi-valued scale fields associated to a sub-record in Satisfaction reports. This displays the aggregate calculation across all sub-records.

Ranker (and Question Group dropdown)

You can add the multi-valued K-field that contains the entity names to Ranker reports, enabling users to rank on those entities. The multi-valued scale fields that are in the sub-record can be used in the Question Group dropdown for the columns in the Ranker report.

Profiler

You can use multi-valued fields of Choice set data type associated with a sub-record in Profiler reports.

Multi-select/Dynamic Filters

Filtering for an individual entity shows data for all surveys where questions about that entity were answered, but aggregate scores contain data only for the sub-records with that entity. For example, if you filter for Burger King on a Responses Form report, you will see all records where Burger King is one of the sub-records (and you still see the other sub-records on those survey records). However, if you filter for Burger King on a Satisfaction report, any of the multi-valued fields that are associated with the sub-record displayed on the Satisfaction report show an aggregate score across all sub-records only where the Restaurant name is Burger King.

Custom modules

You can split on sub-record K-fields in custom modules, just as you can with other fields. For example, for a custom ranker report, you can split on the Restaurant name K- field in the y-axis, and then add a fields-split element on the Overall Satisfaction and Likelihood to Recommend scores in the x-axis.

Data access

You can set access at the entity level (using Segment data categories) if you are using Choice set or Indexed text data type. For example, a user with access to a restaurant in a hotel (a Feedback field with Indexed text data type) has access only to records in which the survey taker answered questions about that restaurant. While the user does not see data about other restaurants, the user (depending on the report structure) might still have permission to see other questions about the hotel that were answered in the survey. If you want to restrict access to only the sub-record, Create a separate workspace where only sub-record fields are displayed.

Alternatively, you can set access at the unit level. For example, a user with access to a hotel (unit) has access to all restaurants associated with the hotel.

For more information, see Roles.

Configure sub-records

To help you understand how to configure sub-records, this section follows an example configuration of a fictional hospitality company. This company has several properties (units), with up to 5 restaurants at each property. The company would like their guests to be able to give feedback about up to 3 of the restaurants they might have visited during their stay. The survey should ask the same questions about all three restaurants. In reports, the company would like to see their overall restaurant scores, but also scores for individual restaurants.

The company does not know which restaurants their guests visited, so they pass all of the restaurant names in the Org file.

The company's survey design follows the second model explained in Design surveys to accommodate sub-records, above. In the survey, they first ask Which of these restaurants did you visit?. On the following page, they ask the survey taker to select up to three restaurants (out of those selected on the first page) for which to provide feedback. They then ask the following questions in the survey about each restaurant the survey taker selected for feedback:

• How satisfied are you with <Restaurant name>? (0 -10 satisfaction Rating scale).

• How likely are you to recommend the <Restaurant name>? (0 - 10 likelihood Rating scale).

• Did you make a reservation? (a Multiple choice - one element with a Yes/No choice set).

• Anything else you would like to tell us about the restaurant (a Text entry element).

Complete these steps to configure sub-records:

1. For each unit, create five Data fields to store the Restaurant name for up to 5 restaurants.

   Select the Indexed text data type for each Unit data field to make it easier to add new values through importers. However, if your company expects to change the name of the entities frequently consider using a Choice set data type, because a change to the entity name does not change its underlying database value.

   Additionally, on the Advanced settings tab, select Retain this value if survey is reset for each field to ensure that the value in place at the time the survey was created persists.

2. Update the Org Hierarchy file.

   Tip: If the company does not know what restaurants a guest visited, they can pass all restaurants for each hotel in the Org Hierarchy file. The survey presents the survey taker with all of the restaurants at the hotel they visited, and then choose which of the restaurants at that hotel they visited.

   1. In the Org Hierarchy file, add 5 columns for each of the restaurants. Some of the columns can be empty for some units.

   2. Using Importers, map these columns to the Unit Data fields you created in an earlier step. For more information about using Importers, see Importers.

3. Create survey questions.

   1. In Program fields, create 3 Feedback category fields that contain the names of the 3 restaurants selected to be surveyed.

      These are populated in the survey. Select the Indexed text data type for each field.

   2. On the first page of the survey, add a Hidden field for every field to declare the fields created earlier to display the names of the 3 restaurants the survey taker selected.

   3. On the second page of the survey, add a Multiple choice - many element to determine which of the 5 restaurants a survey taker visited, such as Which of these restaurants did you visit?. Pipe in the Unit Data fields created in an earlier step so it displays each Restaurant name in each choice set item. Add page display logic on there being at least 1 of the Unit Data fields present. Add display logic in each choice set item on its corresponding data field being present.

   4. On third page of the survey, add a Multiple choice - many element to determine which of the 5 restaurants a survey taker wants to provide feedback for, such as For which of these restaurants would you like to provide feedback? Please select up to three. Pipe in the Unit Data fields you created in an earlier step so it displays each Restaurant name in each choice set item. Add page Display logic to condition survey taker to select at least 3 of the restaurants (At least 3 of the restaurants are present). On the same page, add a Text element for the JavaScript that sets the restaurant names the survey takes selects.

   5. On the fourth page, create the following content elements for each of the 3 restaurants being surveyed (since only a maximum of 3 restaurants are surveyed). Pipe in the name of each restaurant.

      • Rating scale — How satisfied are you with Restaurant name 1? (0 to 10 satisfaction scale).

      • Rating scale — How likely are you to recommend Restaurant name 1? (0 to 10 likelihood scale.

      • Multiple choice - one — Did you make a reservation before your visit? (with a Yes/No choice set.

      • Text entry — Is there anything you would like to share about your experience at Restaurant name 1?.

4. Create the multi-valued K-fields that aggregate restaurant data. On the Advanced settings section, select Make it multi-valued.

   Important: The data type of each K-field must be identical to the Feedback fields it contains. For example, if the Restaurant name is a Choice set, then the multi-valued K-field Restaurant name must also be Choice set.

   For the Restaurant name K-field with an Indexed text data type:

   list (
          q_restaurant_1_name_selected_auto,
          q_restaurant_2_name_selected_auto,
          q_restaurant_3_name_selected_auto
   );

   For the How satisfied are you with <Restaurant name>? K-field with an Choice set data type:

   list (
          q_restaurant_1_osat_scale11,
          q_restaurant_2_osat_scale11,
          q_restaurant_3_osat_scale11
   );

   For the How likely are you to recommend <Restaurant name>? K-field with an Choice set data type:

   list (
          q_restaurant_1_ltr_likelyscale11,
          q_restaurant_2_ltr_likelyscale11,
          q_restaurant_3_ltr_likelyscale11
   );

   For the Did you make a reservation before your visit? K-field with Choice set data type:

   list (
          q_restaurant_1_reservation_yn,
          q_restaurant_2_reservation_yn,
          q_restaurant_3_reservation_yn
   );

   Note: You do not need to create a multi-valued field for the Text entry element in this example. Comments are used only in Responses reports, which can use the original comment fields.
5. Create sub-records to associate the aggregated K-fields with their Restaurant name K- field.

   Important: The length of the list for each multi-valued field in the sub-record must be the same. In this example, the list is 3 items in length. Experience Cloud automatically matches the first item in the list with the first items in the other lists, and so on. Empty values cause no problems.

   1. On Medallia Setup, open the Sub-records screen.

   2. Click New.

   3. Enter a unique name.

   4. Optionally, enter a description.

   5. Select a PrimaryField.

      This field provides the link between the entity and the questions about the entity. The PrimaryField field is usually a K-field with an Indexed text data type, but it can be an Event or Feedback field with a Choice set data type. It must be a multi-valued field, however, and it must have the same data type as the Feedback fields it contains. In this hospitality example, the PrimaryField is a multi-valued K-field that contains the restaurant names, which is used to group the scores for each restaurant.

      Tip: While almost any field can be used as the PrimaryField, best practice is to use the entity name.

   6. Click Save.

   7. In the Additional Fields property, select the fields to associate with the PrimaryField by shuttling them over the right.

   8. Click Save.

   

6. Run a Backfill.

   Do not edit anything in the fields related to your sub-records while the backfill is running.

7. Update your reports:

   • Add the Restaurant name K-field to the Responses List report, Ranker report, and dynamic filters.

   • Add the How satisfied are you with <Restaurant name>? and How likely are you to recommend <Restaurant name>? K-fields to the Responses List report, Satisfaction reports, and Question Group dropdown.

   • Add the Did you make a reservation before your visit? K-field to the Responses Filter and Profiler reports.

   • Add the unit Data fields and Feedback fields to the Responses Form report.

8. Test your configuration by checking the following:

   • Company data is imported into Experience Cloud correctly.

   • Survey pages appear as you expect for the possible selections survey takers can make.

   • Reports show sub-record data.

   • User data access is correctly limiting data to the units and entities those users should see.

   Tip: When testing Indexed text fields, a value needs to appear on at least one record in the database before it exists in the data type. Be sure to have enough test data to verify your results.

Scope

These estimates might help you begin to scope the total effort for implementing sub-records. Contact your Medallia expert to refine your estimate before communicating with the company. In addition to the work needed to configure the questions and reports that use sub-records, estimate these hours:

• Initial implementation (40 hours):

  • 20 hours for JavaScript in survey to set the sub-record fields.

  • 20 hours for additional user access testing.

• Ongoing services (12 hours + variable cost based on survey updates):

  • 10 hours per survey update to sub-record fields.

  • 12 hours to answer questions about data access (mandatory).