Setting up Alerts

These are the general steps for creating an alert.

1. Define the Condition that identifies the Alert condition, associates the Alert with the survey record, and puts the alert in the New state. Important settings:

   • Give the alert a name.
   • Define the condition(s) that associate the Alert with a survey record.
   • Whether or not the alert can be assigned an owner.

2. Define the Workflow activities actions to take when the Activity occurs. For each action:

   • Give the action a name.
   • Specify one or more actions: usually changing the state and/or sending an email.

3. For each Action, define the Alert triggers that tell when and for which Workflow states the action may happen:

   • Give the trigger a name.
   • Identify the states (status condition) the Alert must be in for this trigger to be valid.
   • Define the delay(s) that tell Experience Cloud when to evaluate the trigger (and cause the action to happen).

4. Optionally, identify the Assignees (roles and users) who may be made owners of the alerts:

   • Create and name and assignee, and save it.
   • Identify the role(s) that may be owners of the alert.
   • Optionally, choose to allow assignment to individuals. Otherwise, the entire Role is the owner.

5. Optionally, for each alert, define these Alert type settings and create Alert emails to be used for notifications to users:

   • Roles that can include the Alert in a filter option, and identify the Alert statuses that can appear in report filters.
   • Days in which to, and not to, use when calculating Trigger delays.

6. Create email templates to be used for Rapid Response emails.

Alert workflows

By default, Alerts follow this workflow:

The default workflow is adequate, but most companies customize the workflow to use some or all of these actions:

• Email notifications of new alerts, or ones that have changed, or are about to change state.
• Assignment to users or roles.
• Escalation to additional states (and to different users or roles) after elapsed periods of time.

In addition to the three default states (New, In Progress, and Closed), three additional states indicate an instance is overdue or escalated, and a resolved state is available for application-defined purposes. Here is an example of a custom workflow that uses all seven Alert states. Note that transitioning from escalated to in progress can only be done as part of an alert action, and never as direct result of a user interaction.

The Alert states have these general characteristics, though it is up to the application to define which states are used and how.

Alert condition — New state

Each alert begins with a condition that identifies when the alert is valid for a customer response. When a response record is created (in the COMPLETION_PENDING Survey status (e_status)), the alert evaluates the record against every active alert (in priority order) to see if the alert’s condition is valid for the record. When a condition is valid, that alert fires and becomes attached to the record and the alert is put in the New state; no other Alerts will ever be considered for the record.

The condition is based on the values of one or more fields in the survey record. A typical condition is valid when the customer gives a low satisfaction score or complains about an employee.

Workflow activities

Everything that happens to the Alert starting when the Alert condition is valid until it is closed is defined by the Alert’s workflow. The workflow is defined by one or more activities that happen either by user action or after a period of time has elapsed. The User-initiated activities are defined by Experience Cloud to happen from the Responses report, including:

• Entering a comment in the New or Overdue state changes to In Progress.

• Close button changes to Closed.

• Resolve button change to Resolved. Can be configure to change to Closed.

• Reopen button changes to In Progress.

All other workflow activities are application-defined and happen after an elapsed period of time defined by Workflow activities, which are comprised of:

• Actions that define "what" to do. Actions might include sending email notifications, moving alerts to different statuses, and assigning the alert instance to a role.
• Triggers that identify "when" to do the action. Alert triggers wait some specified length of time and then check to see if its Trigger conditions are true. If they are, the associated Actions happen; otherwise, the trigger expires with no action.

Tips and best practices

• Alerts do not ignore survey records in the EXCLUDED Survey status (e_status). An excluded survey is one hidden from analytics, and from Users who do not have Alert permissions to see them. However, if the record triggered an Alert, any activity timers still operate for that record. For example, they can escalate alerts and send email notifications, but the assigned User might not be able to see the record if it is excluded. As such, any Roles handling escalated alerts should have permission to see excluded records (“Survey rights - View excluded surveys”). Close the alert to turn off the workflow processing.
• Alerts evaluates survey records in the COMPLETION_PENDING Survey status (e_status).
• Text Analytic parsing happens after Alert processing: survey records are evaluated for Alert triggers before Text Analytics.

• Experience Cloud only checks triggers once an hour to see if they have exploded, so timers may take up to an hour longer than you expect. Also, you can trigger multiple status changes at the same time if multiple triggers all explode in the same hour period. See Delays and timers for details.

• Always test alerts to verify they are being generated for the correct responses. Also, test that the alert logic and status work as expected (for example, vary Score Filter or Custom Query on Responses reports).
• Alerts can be associated with non-survey records. See Alert conditions for information.

Pitfalls

These are some of the common configuration errors when setting up alert workflows.

#1: Absolute delay never (seems to) push an alert to overdue

Palo Alto ACME company wants to move all alerts to OVERDUE after 2 days using an absolute delay. The admin sets up the absolute delay to 2 days and then puts NEW in the Alert status conditions. But, if a user updates an alert (which automatically pushes it to IN_PROGRESS) before the timer counts down, the Alert status condition is not valid, and the Alert never goes OVERDUE.

To fix this issue, all necessary previous states need to be included in the Alert status conditions. By including IN_PROGRESS in the condition. This way, when the absolute delay elapses, the condition is valid and the activity pushes the alert to OVERDUE.

#2: Relative timer never triggers

Palo Alto ACME Company wants alerts in NEW state to transition to OVERDUE in 2 days, no matter what. So, they shuttle over NEW and IN_PROGRESS under Alert status conditions and set a relative delay of 2 days. They also select a properly setup action for this trigger.

Even assuming that all other conditions are also met, this setup fails to escalate alerts appropriately when users leave notes on alerts (or preform any other actions that will reset the relative delay timer). For example, users could put a note on their alerts once a day and prevent them from ever transitioning to OVERDUE.

To fix this, an absolute delay should be set so that editing the alert does not affect the timer. Alternatively, use a relative timer with a shorter timer than your absolute delay timer. This would allow the trigger to explode either when the relative timer or when the longer absolute timer counts down. The two timers would work independently.

Making the trigger explode in 2 days if it is not touched, or 4 days no matter what would look like the screenshot below:

Modifying the alert banner

Responses Form reports include a blue banner that shows information about the alert. To change the text on the banner, use the Experience Cloud translation functionality on Translations.

For example the banner can include the name of the person the alert is assigned to. However, depending on how the alerts are configured, they can remain unassigned. In that case, Owner: Unassigned appears in the banner:

To change the Owner: Unassigned text, use the Translations screen, search for Owner and Unassigned strings, and change the text of those lines to suit your needs. Note that the Owner line applies to assigned and unassigned alerts, so if you change that line be sure to choose appropriate text. For more information about translations, see Translations.

To remove the assignment text completely for an alert condition, turn off the Allow assignment property on the Reporting > Action > Alerts > Conditions screen. For more information, see Alert conditions.

Differences between and issues with managing alerts in Setup and Admin Suite

Although many alert configuration settings and properties are shared between Setup and Admin Suite, some settings are present in only one configuration area, and some settings might seem common to both areas but are incompatible.

When creating and modifying alerts, use either Setup or Admin Suite exclusively for each alert. Medallia strongly recommends using Admin Suite exclusively both to manage alerts and to recreate alerts that were initially created with Setup.

Creating an alert in Setup and modifying it in Admin Suite causes errors and unexpected behavior with alert assignment settings, escalation paths, actions, triggers, and email templates. Any modification made with Admin Suite to an alert created with Setup overwrites certain alert elements, and this may cause unexpected behavior.

Assignment settings

Alerts viewed in Setup have an option to Allow assignment, which allows the alert to be assigned to individual users. There is no direct analog to this option for alerts viewed with Admin Suite.

There is a similar option for alert rules in Admin Suite: "Assign the Alert" enables assignment to a user on the record, a specified user, or a specified role.

If Allow assignment is enabled or disabled in Setup, it does not affect the Assign the Alert option or its related options in Admin Suite. Conversely, if "Assign the Alert" is updated in Admin Suite, Allow assignment is enabled in Setup, even if it was disabled before.

In the event this leads to unexpected alert behavior, the Allow assignment option can be disabled again in Setup as needed.

Duplicated escalation paths

Using Admin Suite to edit an alert created in Setup can create a duplicate escalation path for the alert, which causes duplicate notifications.

The duplicate escalation path has an automatically generated name that most likely will not resemble the original. This may make it more difficult to find using Setup. Delete the duplicate using Admin Suite.

Email templates

If an alert is created with a plain text email template using Setup, and then any alert component is modified using Admin Suite, the plain text email template is replaced with an HTML template that does not include any line breaks from the plain text template. The HTML template is automatically generated and automatically replaces the plain text template. Admin Suite cannot be used to create plain text email templates.

Resolution

When encountering errors or unexpected behavior with alerts created in Setup but modified in Admin Suite, delete the alert and recreate it using Admin Suite.