Video overview

The following video presents an overview of how you can use Case Management Forms to close the loop with customers.

Creating and editing cases

When creating a Case Management Form you determine whether users can use the form to create new cases, or only edit cases opened through an alert, as determined by the Form Type property on the Reporting > Action > Case Management Forms screen in Setup.

If you select CREATE_RECORD for that property, users can only use the form to create new cases. Because data entered in a Case Management Form is stored as part of a survey record, creating a new case is effectively creating a new survey record. To allow this you must also ensure that you do the following:

• Assign roles to the standard report named Responses Contact Report. When you select CREATE_RECORD for the Form Type property, Experience Cloud associates the form with the Responses Contact Report. The Case Management Form only appears to users with roles assigned to the report.
• Ensure there is a subtab to display the Responses Contact Report. Consider using the default New Case subtab under the Responses tab, so users can open the Case Management Form from the same area of the reporting application they use to see customer feedback.

If you select any other value for the Form Type property (EDIT_RECORD or ALERT_RESOLUTION), users cannot create new cases, and can only edit case information for existing responses. If an alert is associated with the survey, users can also close the alert directly from the Case Management Form part of the response report. When you create an edit form and one or more alert forms for the same role, the alert forms take precedence. In that scenario, when a record generates an alert, users can edit the record only through the associated alert form, and not through the edit form.

It might take a user several working sessions to resolve an alert. While working in a case, users can click Save Progress to edit the case without changing the alert status. If your session expires, you can reauthenticate and continue working without losing any data, all changes are automatically saved.

Dynamic forms

Turn on the Make form dynamic property to make the form dynamic based on the field selections a user makes. With dynamic forms you can control which fields are displayed or hidden based on the user's selections. You can also make field dropdowns display only a subset of their possible values based on the values selected in other fields.

If you have existing forms that you want to make dynamic, turn on the Make form dynamic property and then click Save. Similarly, you can make dynamic forms non-dynamic. Note that when you do this, all defined conditions are removed, and cannot be replaced merely by making the form dynamic again. Whenever you make a form dynamic, you must create its conditions manually.

Showing and hiding fields

The Display condition property controls whether a field is shown or hidden on the form. Traditionally, this property is used to populate a form based on data already recorded in a survey response, so when a user opens the form, he or she sees only the fields necessary for resolving the customer's problem. For example, you might want to display a group of fields based on the Contact Reason provided by the customer.

With dynamic forms, you can also show and hide fields based on the values users select in the form, so users see only relevant fields. For example, you might want the Resolution Notes field to be hidden until the user selects Yes for the Resolved field. In this case, the Display condition for the Resolution Notes field would be q_packages_bp_cc_case_problem_resolution-yn = 1.

Experience Cloud evaluates display conditions when the user opens a form, and also every time the user selects a field value. When a Display condition is empty, that field is always visible.

Dynamic field values

Suppose you have a form that includes fields for State, County, and City. In a non-dynamic form, each field always has all of its possible values available in its dropdown. In a dynamic form, you can condition the County dropdown to show only the values relevant to the user's selection in the State field. Similarly, you can condition the City dropdown to show only the values appropriate to the selected County. In this way, you reduce the number of values people must browse to find what is needed, making the form easier to use.

Only enumerated fields (those using an alternative set with a ContentKind of ENUMERATION) can display values dynamically. For more information, see Alternative sets.

For a field's values to be dynamic, you must set one or more conditions for that field in its Value condition properties on the Case Management Forms screen. For example, the following image shows the configuration properties for the Contact Reason field (bp_cc_case_root_problems_mvalt), which a call center agent uses to identify the root problem in a customer's issue:

In this example, the values users see in the Contact Reason field are dynamic, based on the value the user selects for the bp_cc_case_problem_resolution_yn field, which is a Yes/No field indicating whether the issue was resolved. When the user selects Yes (an alternative set value of 1), the Contact Reason dropdown on the form displays the values Ordering Issue, Delivery Issue, Billing/Invoice Issue, and Contact Center Support Issue. When the user selects No (an alternative set value of 2), the Contact Reason dropdown displays the values Contact Center Support Issue, Field Service Support Issue, and Other.

You can create as many conditions as needed. Values can be available in multiple conditions. For example, both conditions in the example above result in the Contact Center Support Issue value being displayed. Experience Cloud processes conditions in order from top to bottom, and stops processing as soon as one is met. For more information about creating conditions, including correct syntax, see Conditional expressions.

Required fields and display conditions

Your selection for the Form Type property interacts with the Required and Display condition field-level properties to affect how users interact with the Case Management Form to resolve alerts and close case records.

If you allow users to create new cases, they must enter values for all fields marked as Required before they can submit the new case record.

If you allow users only to edit cases, the following scenarios apply:

• For cases associated with an alert, users must enter values for all required fields before closing the case and resolving the alert. However, when editing (and not closing) a case associated with an alert, users can leave required fields empty, and simply update the record by clicking Update Contact Report on the form. This sets the status of the alert to In Progress.
  Important: These are the only case forms statuses that change to IN_PROGRESS after a note is added or a case form is updated: NEW, IN_PROGRESS, and OVERDUE.
• For cases not associated with an alert, no fields are required, even if you have checked the Required property for fields on that form. In this scenario, users are simply editing the survey record. When a form is saved for a record that does not currently have an alert, that record is sent through alert processing, and generates an alert if any alert conditions are met. For more information, see Advanced alerts.

You can also set a Display condition for any field on the form, limiting when that field appears. Note that if you have marked a field as Required, but it is not displayed on the form because its Display condition was not met, that field is still required to resolve the alert and close the case.

Best practices

Medallia recommends that you start with a small, basic form to help users get comfortable with the process, and then add fields only as needed. Remember that as the form becomes more complicated it takes longer for users to complete their work, leading to a more expensive process. Keep forms light and easy to complete. Consider beginning with a simple form that allows users to enter the following information:

• Root cause — This is ultimately what led to the customer's dissatisfaction. Create it as a structured list of options that are actionable for the user. Consider using categories that already exist in the business, because this will help drive adoption and usage. Users in the organization are used to seeing the categories, so there is less need to train them on specific functionality.
• Resolution type — A structured field that allows users to select what they did to alleviate the issue. Be sure to include an option to indicate that the issue was impossible to resolve.
• Resolution verbatim — A text field that allows users to recap what happened and what was done to resolve the issue.

You can create up to 3 columns of fields on a Case Management Form. Consider organizing fields in the following columns, by the distinct type of information being tracked:

• Column 1 (low priority fields) — Customer information that is not already present in the Responses Form. Since that report already contains much identifying information for the customer, you might have very little here. If you do not need to supplement the identifying information already in the report, omit this column.
• Column 2 (medium priority fields) — Outreach information, such as how users reached out to the customer (such as through email, or a phone call), the number of attempts made to contact the customer, the outcome of each contact, and whether the customer was granted any sort of compensation.
• Column 3 (critical fields) — Cause and resolution information, such as the root cause of the issue, whether the issue was resolved to the customer's satisfaction, a description of what the user did to help resolve the issue, and the user's ideas to help prevent the issue from arising again. To ensure good feedback from users, make a few critical fields required.

Recommend a time to resolution to reduce the frequency alerts are auto-closed passively. Engage users to resolve customers' issues actively.

When designing a Case Management Form, consider the workflow at your company. Data collected through Case Management Forms is less valuable without someone to own and lead the organizational changes the data suggests.

If you are using legacy reports, avoid adding date/time fields to Case Management Forms because users must enter the full date/time value in a specific format. While the format is displayed on the form by default, there is no date/time picker to assist the user. If you are using Medallia Alchemy Experience Reporting, Case Management Forms include a date date/time picker. For more information about Medallia Alchemy Experience Reporting, see Reporting.

When an alert is triggered for a record, the Accepted Date field is reset to the current date and time. If your workflow relies on the Accepted Date field, consider using the e_initialfinishdate field instead, since it is not reset by alerts, opt outs, and other Experience Cloud processing.

No unit is assigned automatically to records created as new cases. If you want this information recorded as part of new case records, add a unit field to the Case Management Form.

Consider whether you need metadata fields in your Case Management Form for reporting purposes. For example, if you want to track records created as new cases specifically, you must add a field to the Case Management Form for this purpose. As users work in the Case Management Form, they use the new field to indicate whether the record was created as a new case. You can then include the field in reports, with a filter to show only the new-case records.

Unsupported field types

The following field types are not supported on Case Management Forms because they require more advanced validation or logic:

• ROOM_NUMBER

• SHORT_INT

• IP_ADDRESS

• SURVEY_SPEC

• REAL_NUMBER

• ENCRYPTED

• FRACTIONAL

• TRANSLATABLE

• JAVAENUM

• UNIT_GROUP

• HYPERLINK

• TIME

• STATIC_REPORT_TYPE

Creating Case Management Forms

Experience Cloud solutions include Case Management Forms, the data from which is used in Closed loop feedback reports. You can supplement existing forms or create your own.

1. In Setup, open the Reporting > Action > Case Management Forms screen.
2. Click New CaseManagementFormSetup.

   

3. Enter a unique Name for the form.

   The name is used only to identity the form, and is not visible to users.

4. Enter a Heading.

   The heading appears above the form, and is visible to users.

5. Select a Form Type.
   • ALERT_RESOLUTION — Users can use the form as part of the process for closing an alert.
   • CREATE_RECORD — Enables users to create a new record in the New Case tab.
     Note: If you select this option, you must complete extra steps (at the end of this procedure) to ensure that the New Case form is visible to users.
   • EDIT_RECORD — Enables users to edit existing cases only, and disallows the creation of new cases on this form.
6. If you want the form to be dynamic based on the values selected by the user in enumerated fields, turn on the Make form dynamic property.
7. In the Assigned Roles property, assign roles to the form by moving them to the right-side box.

   You can assign multiple roles to the same form. For any specific role, you can assign one form of the CREATE_RECORD type, one form of the EDIT_RECORD type, and several forms of the ALERT_RESOLUTION type (with each ALERT_RESOLUTION form associated with a different alert). Assigning roles saves your form, and updates the screen with Column sections.

8. Optionally, for forms with a Form Type of ALERT_RESOLUTION, you can make the form required to close 1 or more types of alerts. To do this, select alert types in the Restrict to Alert Types property by moving them to the right-side box.

   When a form is required to close an alert, all required fields on the form must be filled out to resolve and close the alert, and the Close Alert button is available on the form. If you do not select at least 1 alert type, the form is associated with all alert types. Additionally, if you do not select at least 1 alert type, for responses that do not generate an alert the Edit Case button is available on the form.

9. In each of the 3 Column sections, use the Add/Remove tab to select the fields to display in that column. After you select the fields you need, use the Sort tab to order them as they should appear, top-to-bottom. For example:
10. After selecting and sorting the fields in the form, click Save.

    New configuration properties appear for each field you selected. Enumerated fields include options for making the field dynamic. For example:

    

11. Optionally, configure any of the following parameters for the fields on your form:
    • Instructions — Add instructions to help the user enter the right information for the field. Instructions appear just above the field on the form. You can provide instructions in plain text, with a limited set of Markdown elements (bold, italics, and link). Instructions can also be translated. For more information, see Localization.
    • Required — Turn on this property to make the field required when creating new cases. For more information, see Required fields and display conditions.
    • Display condition — To cause the field to appear only when a specific condition is met, enter that condition here. The condition can be based on survey data, or selections users make in other fields as they use the form. For example, you might want a field to appear only for surveys submitted from a specific region. You might want certain fields to appear only after the user selects a value for a field indicating the method used to interact with the customer (such as email, chat, telephone, and so on).
      Note: Experience Cloud checks display conditions when the user opens the form, and every time the user makes a field selection.
    • Restrict editing to roles — By default, all fields can be edited by all roles assigned to the form. To limit editing to a subset of roles, select those roles by moving them to the right-side box.
12. Optionally, if your form is dynamic you can create one or more value conditions for any enumerated field. For more information, see Dynamic forms, above.
    1. Select Confirm, and then click Add new dynamic value condition.

       New properties appear for the field, enabling you to define the condition for displaying selected values for this field. The Value condition property defaults to a value of false. The Values to show when this condition is true property shows all possible values for the field, with none of those values selected. For example:

       

    2. In the Value condition 1 property, enter a condition for displaying values.

       For more information, see Conditional expressions.

    3. In the Values to show when this condition is true property, select which values the user will see when the condition is met.
    4. Optionally, repeat these steps to add one or more additional conditions and sets of values.
    5. When you are done adding conditions and values, click Save.
13. When you have finished configuring fields, click Save.

14. If you selected CREATE_RECORD for the Form Type property, complete the following steps to ensure that the right roles can use the New Case form:

    1. Open the Reporting > Reports > Standard Reports screen
    2. In the list of reports, select the Responses Contact Report.

    3. Note the Name of the report.

       By default, the report is named New Case.

    4. In the MemberRoles property, verify that the report is assigned to the proper roles. By default, all roles are assigned to the report, but you might want to limit access to a subset of roles.

       

    5. If you changed anything in the report, save and publish your changes.
    6. Open Navigation in Admin Suite.
    7. Locate the New Case subtab, which is under the Responses tab by default.
    8. Verify that the report assigned to the New Case subtab has a name that matches the Name property of the Responses Contact Report.
    9. If you changed anything in the subtab, save and publish your changes.

Using case data in reports

Data entered in a Case Management Form is stored as part of the survey record itself. This means that you can use case data just as you would any other survey data. For example, you can export it, use it in K-fields, and (perhaps most importantly) display it in reports. For more information about creating custom reports, see Custom Module.

The following examples show how you might use case data in custom reports.

Top 5 Issues

This report shows the current top 5 issues to help users see which issues occur most frequently, and which need action.

The following AA2 code defines this report:

<analytics-report hide-empty-rows="true" hide-empty-columns="true">
<chart type="COLUMN_STACKED" decimals="0" data-labels-enabled="false"/>
   <axis axis="">  <optionbox-filter plugins="UNIT,TIMEPERIOD"/>
      <timeperiod-dropdown-split/>
      <heading css-class="total" text="Total"/>
   </axis>
   <axis axis="Number of Issues">
      <!-- R-field calculating the count of total issues -->
      <aggregate-field field="r_total_issue_count"/>
      <!-- Split on the required issue categorization field on the case form -->
      <split field="e_issue_type_alt">
         <static-sort column="-1" order="DESCENDING" row-limit="5"/>
      </split>
   </axis>
</analytics-report>

Issues by Unit Groups and Units

The number and type of issues can vary greatly by location (such as store, region, and so on), or by other groups in your organizational hierarchy. This report lists issue counts by your chosen unit group.

The following AA2 code defines this report:

<analytics-report hide-empty-rows="true" hide-empty-columns="true"> 
 <axis axis="">
  <optionbox-filter plugins="UNIT,TIMEPERIOD,SEARCH,CALCULATION"/> 
 <!-- R-field calculating the count of total issues -->
<aggregate-field field="r_total_issue_count"/> 
 <!-- Split on the required issue categorization field on the case form -->
  <split field="e_issue_type_alt">
   <static-sort column="-1" order="DESCENDING" row-limit="5"/>
  </split> 
 <heading css-class="total" text="Total"/>
 </axis> 
 <axis axis="Number of Issues"> 
  <heading text="Division">
   <unitgroup-split identifier="unit_group_identifier">
    <heading text="Division Total" css-class="total">
     <format decimals="0"/>
    </heading> 
    <unitgroup-split identifier="sub_unit_group_identifier"/>
   </unitgroup-split>
  </heading>
 </axis>
</analytics-report>