Alert conditions

Reporting > Action > Alerts > Conditions

Note: This topic describes Alert management using Medallia Setup. Although some Alert properties are common between Setup and Admin Suite, some options can only be configured with Admin Suite, and these may have unintended effects on Setup options. For more information about these differences, see Differences between and issues with managing alerts in Setup and Admin Suite. For information about configuring Alerts with Admin Suite, see Alerts.

Alert conditions define the criteria of an experience event that requires follow-up action by the company. Conditions evaluate the values of one or more fields in survey records. When a condition is valid for a record, Medallia Experience Cloud creates an alert instance, and starts the follow-up workflow by putting the instance in the New state.

Tip: The terms Alerts, Alert conditions, and Alert types are often used interchangeably to mean the same thing: the condition that must exist to start a follow-up workflow (Alert instance).

Alerts evaluates survey records that are in the COMPLETION_PENDING Survey status (e_status). For each record, Experience Cloud evaluates the record against every active alert condition (in priority order). When a condition is valid, that alert triggers an instance and the alert becomes attached to the record; no other alerts will ever be considered for the record. The Alerts conditions screen shows all alerts in priority order, starting at the top with the lowest priority number.

Use the Alert conditions screen to:

  • Create alert conditions with the Create an Alert button.
  • Modify alert conditions with the Edit link below each condition's name in the list.
  • Deactivate or activate alert conditions. You can do this from the list, or when editing a condition.
  • Deleted Alert conditions.
  • Preview the results of a condition to see which of the recent records meet the condition criteria.
  • Preview all alerts to see which condition would find which of the most recent records.
  • Prioritize alerts by changing the ordinal values in the left-most column and clicking Save Changes. Each active condition must have its own unique priority value; the values do not have to be consecutive (for example, 1, 2, 5, 7, 20 are acceptable for a list).

Alert condition properties

The properties are available on the Alert condition editor when creating or editing a condition.
Description
Description of the Alert to be shown to users on the dashboard Alert modules and in reports, and in log notes.
Name
Name of the alert as it appears in the alerts list.
Alert Name (Brief)
Name of the alert as it appears in filters and in report column headings.
Internal Description
Internal comments about this item. Be as descriptive as possible to help others understand the functionality of this specific alert.
Active
Whether or not Condition(s) is evaluated when new survey records come in. Only active alerts are evaluated and used to create alert instances.
Warning: Setting an Alert condition to inactive makes unavailable all alert records for that condition: the associated alerts cannot be closed or move through the workflow. Close or remove all alerts for this condition before deactivating the condition. When an alert condition is set to inactive, existing alert instances with the inactive condition still trigger if the alert is not closed or removed before the condition is set to inactive.
Resolve closes
Whether or not the Resolve button changes the alert to the Closed state instead of the Resolved state.
Allow assignment
Whether or not the Alert may be assigned to a single user instead of the Assignee role.
Trigger for non-survey types

Whether this alert triggers when the the survey type is not SURVEY.

The alert condition evaluates fields in a survey record to identify notable events that require follow-up. However, for efficiency and reporting purposes, additional non-survey information is also stored in survey records. By default, alerts only evaluates records that truly came from survey results. When this option is turned on, the Condition(s) can evaluate non-survey-source records as well. For more information, see e_survey_type.

Conditions

One or more expressions of a survey record fields, and the values that must be in those fields, for the condition to be true. Combine multiple expressions with AND or OR operators.

Note: A complex expression must combine the expressions with either AND or OR; they cannot have both AND and OR operators. See Alert condition examples, below, for a way to use a K-Field to combine the operators.

To define an expression:

  1. Select the type of field from these options:
    • the client shows Feedback fields.
    • the field shows Event fields and K-fields.
      Important: K-fields used in alert conditions must have the Export Only property; otherwise, those alerts fail to trigger consistently.
    • the question (special Feedback fields; may not be fully supported)
    • a problem with shows Feedback fields marked as a Problem question. Use this to trigger Alerts based on how a particular problem was handled.
    • the topic shows published Medallia Text Analytics topics.
    • the Action Intelligence Insight shows Action Intelligence System fields. For more information, see Action Intelligence.
  2. Pick the field.
  3. Pick the values that must be in the field for the expression to be true (and trigger the alert). Use the Advanced… option to select multiple values. The N/A /No Answer option is equivalent to a NULL value.

The fields must be enumerated AltSets so the value can be selected; pure text and auto-indexed text AltSet types do not work.

Note:
  • If the AltSet has numerous AltDb and NO AltDb has NumericValue added, alerts will show ALL the AltDb.
  • If the AltSet has numerous AltDb and if any AltDb has a NumericValue added (and some do not), alerts will show ONLY the AltDb that has a NumericValue.

Alert condition examples

The following condition triggers an alert when the survey taker gives a Likelihood to Recommend score of < 7 and the survey type is Transactional:

  • The respondent indicated that Likelihood to Recommend (q_demo_ltr) was 6,5,4,3,2,1,0.
  • Demo Survey Type (e_demo_survey_type) is Transactional.

Note that NULL does not satisfy the above condition.

Some more complex conditions require using a K-Field to evaluate the criteria. This example condition triggers when the field Example alert (k_example_alert) returns Yes:

  • Example alert (k_example_alert) is Yes.

Where the the Example alert is a Yes/No type (AltSet), it returns Yes when:

  • Either Likelihood to Recommend is less than 8 OR the Satisfaction is less than 8, and
  • The survey taker was contacted by a representative.
f = function(){
  rec = seqnum(q_example_ltr);			  
  exp = seqnum(q_example_sat);
  contact = seqnum(q_example_contacted);
    if (( rec <= 7 && rec > 0 ) || ( exp <= 7 && exp > 0 ) && (contact == 1)) { return 1; }
      return 2;
    };
f();

Previewing alert conditions

Preview has two variations:

  • Preview the results of a specific condition to see which recent records meet the condition criteria. Use this to verify the condition is finding the records you expect.
  • Preview All Alerts to see which conditions would trigger which of the most recent records. Use this to verify which alerts are find the records you expect.

Alerts screen capture with call-outs to the Preview All Alerts link and to one of the individual Preview links

By default, the preview feature evaluates the condition(s) against the 100 most recent records.These default settings only work for small sets of record, such as when working in a development environment. When working with large sets of records, you might need to increase the pool size from 100, or look at records from an earlier date.

To change the default behavior, append one or more of the parameters to the end of the URL in the browser. The parameters are:

  • surveysOlderThan=YYYY-MM-DD.
  • numberOfSurveys=N.

To increase the pool size to consider the 200 most recent records, append: numberOfSurveys=200. For example, this image shows the preview found 138 records out of the most recent 200:

Capture of the Conditions screen with the &numberOfSurveys=200 in the URL and the "138 surveys match" elements called out

For example, to use surveys completed before July 15, 2015, append: …&surveysOlderThan=2015-07-15. To use 500 surveys older than July 15, 2015, append: …&surveysOlderThan=2015-07-15&numberOfSurveys=500.

Tips and best practices

  • When having multiple survey types, include the Survey type field in the condition. This allows the alert to be specific to the program and helps keep other alerts from triggering on the results.
  • Always account for answers with NULL (No answer) values.
  • Using OR logic is problematic. Once selected, you cannot later select AND, making it more difficult to add more conditions. For complex conditions, it is easier to build the entire logic in a K-field.
  • In K-fields referenced by the condition, match up the field's Alt Set's sequence number, instead of the numeric values of the elements.
  • By default, Alerts are available in the Alert filter dropdown for all roles on a program instance. To change who can filter on an alert, use Alert type settings and select the target roles.

Formula fields (K-fields) with topics in alerts

Medallia does not recommend using formula fields (also known as K-fields) that reference topics as conditions in alerts, as this may lead to inaccurate evaluations and alerts that do not trigger as expected.

Such an implementation is not recommended because
  • the alert processing engine cannot determine if the formula field calculation references a topic;
  • the formula field calculation is evaluated before text processing is complete;
  • that evaluation is not an accurate representation of the data because text processing has not been completed;
  • and this leads to unexpected outcomes such as alerts triggering incorrectly or not triggering even when configured conditions are met.

If, despite these limitations, a customer use case requires using formula fields with topics in alert conditions, a workaround is available. To delay alert condition evaluation until text processing has completed, add an auxiliary condition that directly references the topic. This auxiliary condition must be designed in such a way that it always evaluates to false; otherwise, it may affect the intended evaluation result and cause erroneous alert triggering.

Because the auxiliary topic-referencing condition must always evaluate to false, the condition operator that connects the auxiliary and primary conditions must be OR. For example:

  • Auxiliary condition (FALSE) OR primary condition (TRUE) yields a final result of TRUE, and the alert triggers.
  • Auxiliary condition (FALSE) OR primary condition (FALSE) yields a final result of FALSE, and the alert is not triggered.

If the auxiliary condition ever evaluates to TRUE, the alert triggers erroneously. If the AND operator is used to connect the auxiliary and primary conditions, the alert triggers erroneously or not at all.