2Configuring Message Scenarios

Create a Message Scenario

You must first create a message scenario before you can define the launch condition, scenario steps, message, and delivery channel..

  1. Click Configuration.

  2. Click Message Scenarios under Subsystems and Integrations.

    The Message Scenarios screen opens.

  3. Click the + icon in the left panel.

    The Add Message Scenario window opens.

  4. Type the name users will see on the Message Scenarios screen in the Name field.

  5. Type a unique identifier for the message scenario in the Label field.

  6. Type the date the scenario becomes active in the Start Date field or click the calendar icon and select a date.

  7. To set an end date at which the scenario becomes inactive, select the End Datecheck box and type or select a date in the field.

    Note: If you do not select the End Date check box, the scenario will run indefinitely.
  8. Click OK.

The Add Message Scenario window closes and the message scenario you created appears in the list of scenarios on the left of the Message Scenarios screen. The scenario will display an error message in the scenario list because you have not yet defined a launch condition for it.
Now you can configure the message scenario.

Edit a Message Scenario

Each scenario consists of one or more start steps (and, in some cases, inner steps) that you can edit.

  1. In Oracle Field Service Core Manage Cloud Service, click Configuration.

  2. Click Message Scenarios under Subsystems and Integrations.

    The Message Scenarios screen opens.

  3. Select the appropriate message scenario from the left panel.

  4. Do one of the following:

    • Click the title of the message scenario step you wish to edit.

    • Click Image of selection icon next to the message scenario step, and select Modify from the drop-down list.

    The Modify scenario step window opens.
    The Modify Scenario Step screen lets you define settings related to a message scenario.
    The window contains four tabs from which you can specify the settings related to message generation:
    • Settings contains the basic parameters of the message generated at a certain scenario step, that is, how, when, and where it should be sent

    • Patterns defines the content of the message to be sent

    • Conditions sets the blocking conditions, that is, the conditions under which the message should not be generated at this step

    • Next steps defines the conditions of the subsequent steps execution

Configure a Scenario Step

Configuring a scenario step is a process that offers maximum flexibility. The Add scenario step and Modify scenario step windows contain four tabs from which you can specify the settings related to message generation:

  • The Settings tab contains the basic parameters of the message generated at a certain scenario step, that is, how, when, and where it should be sent.

  • The Patterns tab defines the content of the message to be sent.

  • The Conditions sets the blocking conditions, that is, the conditions under which the message should not be generated at this ste.p

  • The Next steps tab defines the conditions of the subsequent steps execution.

To configure a scenario step:

  1. Click Configuration.

  2. Click Message Scenarios under Subsystems and Integrations.

    The Message Scenarios screen opens.
  3. Select the appropriate message scenario from the left panel.

  4. Do one of the following:

    • Click the scenario step name or click the action button and select Modify to open the Modify scenario step window with the Settings tab on top.
    • Click Add new to open the Add scenario step window with the Settings tab on top.

    The Add Scenario Step lets you add a scenario step and define settings related to a message scenario.
  5. Refer to Settings Tab and complete the fields on the Settings tab.

  6. Click the Patterns tab and type content into the Subject and Body fields. For information about how the Patterns tab differs for each of the delivery channels, refer to Patterns Tab.

  7. Click the Conditions tab and complete the fields. For information about the Conditions, refer to Conditions Tab.

  8. Click the Next steps tab and complete the fields. Refer to Add Next Steps.

    Working with Launch Conditions

    The Message Scenarios page displays information about launch conditions for the selected scenario. Launch conditions are the system events that trigger a message scenario.

    Message scenarios are not initiated unless and until something happens to trigger them. The event that sets the message scenario in motion is called a launch condition, and these events are predefined by Oracle Field Service Cloud. Launch conditions include events such as the delay of an estimated arrival time, the reassignment of an activity, or the installation of inventory. You define the launch condition that sends a specific message to a designated recipient using the delivery channel you identify at the time you want it to be sent.

    You can specify multiple launch conditions for a single message scenario, and whenever one of those conditions is detected, the message scenario begins to run through the steps of the scenario. However, while message scenarios can have multiple launch conditions, each launch condition can be associated with only one message scenario because the system has to know which scenario to launch when the launch condition is detected.

    The two types of launch conditions include action-driven and condition-driven. Action-driven launch conditions are those events that immediately launch the message scenario when they occur, for example, activating a route or completing an activity. Condition-driven launch conditions are determined by polling the system periodically to see if certain conditions have been fulfilled and, if they have, then launching the message scenario. For example, Oracle Field Service Cloud checks to see whether the current time is within a notification window for the start of a delivery window or in the time frame during which an escalation notice should be sent. So there is not a specific action that launches the message scenario for condition-driven launch conditions, but rather the passage of time that indicates the message should be sent now.

    The Launch conditions section displays the scenario’s existing launch conditions and lets you add and remove conditions. A numeric indicator lets you know how many messages are in the queue for each of the launch conditions and lets you estimate the potential results of any changes you make to the scenario.
    Note: If the number of messages is greater than 999, the indicator displays the number in thousands, denoted by the letter k. For example, 5,000 messages will be indicated as 5k. If the number of messages is 1,000,000 or greater, the indicator displays the number in millions, denoted by the letter m. For example, 12,000,000 messages is displayed as 12m.

    You can remove a launch condition by clicking the x in the upper right corner of the condition indicator.

      Add a Launch Condition for a Message Scenario

      A launch condition is the event that triggers the message scenario.

      Launch conditions are configured on the Message Scenarios screen.
      1. Click Configuration and select Message Scenarios under the Subsystems and Integrations heading.

      2. On the Message Scenarios screen, select the scenario for which you want to define a launch condition.

      3. Click the Add new link for launch conditions.

        The Add launch condition window opens. The window contains a drop-down menu that, when clicked, lets you select the event that triggers the message scenario.
        The Add Launch Condition window lets you select an event that triggers the message scenario.
      4. Select the launch condition for the message scenario, referring to the following table for a description of each condition.

      5. Click OK.

      Table Launch condition, associated scenarios, and description

      Launch Condition Scenario to be associated to OR Scenario will be launched when Description
      Reminders

      For detailed information about how the reminder interval for message delivery is determined, refer to Reminder and Change Notification Launch Conditions

      Day Before

      There is a specified number of days prior to activity

      Provides a proactive message to customers within the defined number of days before an activity is scheduled to start. The message is sent immediately at the specified time before a new or rescheduled activity.

      This launch condition is not invoked for non-scheduled, reopened, or pre-work activities. It also applies only to activities that have the Enable ‘day before’ trigger field selected when the activity type is created or modified. Messages invoked by this launch condition become obsolete after the following activity-related actions:

      • Cancel

      • Delete

      • Start

      • Suspend

      • Reschedule

      No messages are generated when an activity is moved between resources on the same day.

      Reminder

      There is a specified number of minutes prior to activity

      Provides a proactive message to customers within the defined number of minutes before an activity is scheduled to start. The message is sent immediately at the specified time before a new or rescheduled activity.

      This launch condition is not invoked for non-scheduled, reopened, or pre-work activities. Messages invoked by this launch condition become obsolete after the following activity-related actions:

      • Cancel

      • Delete

      • Start

      • Suspend

      • Reschedule

      No messages are generated when an activity is moved between resources on the same day.

      Additional information is required when you select this launch condition:

      • Reminder time in minutes (Specify more than one reminder time by separating the values with commas)

      • How the time is calculated:

        • Delivery window start

        • Service window start

        • ETA

      • Silent interval

      Change 1 to Change 5

      Estimated time of arrival is changed (1st)

      Estimated time of arrival is changed (2nd)

      Estimated time of arrival is changed (3rd)

      Estimated time of arrival is changed (4th)

      Estimated time of arrival is changed (5th)

      Provides up to five proactive messages to customers when the estimated time of arrival for the activity has changed. Additional information is required when you select this launch condition:

      You will be asked to specify the difference between when the time is calculated (delivery window start, service window start, or ETA) and when the last notification was delivered to the customer. You will also define a window of time before the activity start for which the rule will apply.

      • How the time is calculated:

        • Delivery window start

        • Service window start

        • ETA

      • The number of minutes between the time and the last time a message was delivered to the customer, at which point this message will be delivered

      • The range of minutes prior to the activity start during which the launch condition applies

      These launch conditions are invoked only for pending ordered activities (regular or reopened) in an activated route on the current work day; they do not apply when a reminder is not sent and the current time is within the silent interval, when an incomplete reminder exists, or when a change message was already sent and the last change message was sent by the same launch condition. It also applies only to activities that have the Enable ‘reminder’ and ‘change’ triggers field selected when the activity type is created or modified.

      Messages generated by these launch conditions are removed from the message queue if one of the following events occurs after their generation and sending:

      • The activity status is changed.

      • The activity becomes non-ordered.

      • The activity is moved.

      Refer to Reminder and Change Notification Launch Conditions.

      Call Ahead Next activity is about to start Provides a proactive message to customers when the next activity is about to start.

      Route

      Activate

      Route is activated

      Invoked when a route is activated.
      Deactivate

      Route is deactivated

      Invoked when a route is deactivated.
      Reactivate

      Route is reactivated

      Invoked when a route is reactivated.

      Activity

      Add

      Activity is created

      Invoked when a new activity is created or an existing activity is moved to a different day or resource. This launch condition is invoked only for regular and reopened activities, but not for prework or instances of mass repeating activities, such as lunches or meetings.

      Start

      Activity is started

      Invoked when an activity is started. This launch condition is invoked only for regular and reopened activities, but not for prework.

      Complete

      Activity is completed

      Invoked when an activity is completed.

      Cancel

      Activity is cancelled

      Invoked when an activity is cancelled.

      Not done

      Activity is not done

      Invoked when the status of an activity is changed to not done.

      Delay

      Activity is delayed

      Invoked when an activity is delayed beyond the number of minutes specified in the launch condition.

      Suspend

      Activity is suspended

      Invoked when an activity is suspended.

      Note: If a started activity is suspended, a new suspended activity is created. This launch condition is then invoked for the new suspended activity. When this happens, both the pending and suspended activities have the same property values, and the suspended activity has no inventory.
      Move Activity

      Activity is moved

      Invoked when an activity is moved to a different day or different resource. This launch condition is invoked only for regular and reopened activities, but not for prework.

      The messages that are generated with this launch condition refer to the origin resource. To retrieve information about the destination resource, use the destination_resource block. To retrieve information about the destination resource and date, use the following placeholders:
      • destination_resource_id

      • destination_resource_external_id

      • destination_resource_name

      • destination_date

      For information about using blocks and placeholders, refer to Message Content Overview

      To control whether the activity can be moved to another resource or another day, use the Resource changed? or Day changed? blocking condition. For information about blocking conditions, refer to About Blocking Conditions.

      Alerts

      Not Started 1

      Not Started 2

      Activity is not started after the ETA (alert 1)

      Activity is not started after the ETA (alert 2)

      Invoked when an activity has not been started within the number of minutes specified when defining the launch conditions. The two launch conditions are independent and can be generated for the same activity at the same time. They can be invoked only for pending ordered activities (regular or reopened) in an activated route that belongs to the current working day.
      Not Activated Route is not activated

      Invoked when a route has not been activated within the number of minutes specified when defining the launch condition. This launch condition applies only once per day per route, and messages are not regenerated if the calendar changes. Any existing not-activated messages become obsolete at the moment of route activation. If the resource is new, the messages generated by this launch condition are not generated until the day after the resource is created. Additionally, the resource must be associated with a resource type that has the Enable ‘Not activated in time’ alert and trigger field selected when the resource type is created or modified.

      Service Window Warning Activity is not started on time for the service window Invoked when an activity has not started within the number of minutes before the end of the service window that is specified when defining the launch condition. It is also invoked when an activity is scheduled after the end of the service window. The launch condition can be invoked only for pending ordered activities (regular or reopened) in an activated route with a service window that belongs to the current working day, and it is invoked only once per activity. The activity must be associated with an activity type that has the Enable ‘SW Warning’ trigger field selected when the activity type is created or modified.
      SLA Warning Activity is not completed before the end of SLA window Invoked when a pending activity has not been started within the defined number of minutes before the end of the SLA window or when a started activity is not completed within the defined number of minutes before the end of the SLA window. The launch condition is invoked only once per activity unless the SLA window end changes after the generation of this alert, at which point it can be invoked again.
      Service request

      Manual Service request is created
      Invoked when a service request is created. When you create the message, you can use placeholders related to the service request and its parent objects. For example, if the service request is for an activity, the content can contain placeholders related to the request, activity, route, and resource. Refer to Activity Message Placeholders. Use this launch condition for the following situations:
      • Inventory tracking and hardware testing

      • Initiating SRO or sending any other form

      • Initiating support requests

      • When a transaction is initiated without being related to the activity

      • Other activity or inventory requests

      Inventory

      The inventory launch conditions are used to communicate inventory operations to an enterprise resource planning system and perform automated provisioning.

      Install Inventory Inventory is installed Invoked when inventory is moved from the resource pool to the install pool or when a new install inventory record is created.
      Deinstall Inventory Inventory is deinstalled Invoked when inventory is moved from the customer pool to the deinstall pool or when a new deinstall inventory record is created.
      Exchange Inventory Inventory is exchanged Invoked when inventory exchange between the resource pool and the customer pool is performed.
      Undo Install Inventory Undo install inventory performed Invoked when inventory is moved from the install pool to the resource pool.
      Undo Deinstall Inventory Undo deinstall inventory is performed Invoked when inventory is moved from the deinstall pool to the customer pool.
      Move Inventory Inventory is moved

      Invoked when inventory is moved between different resources. The launch condition applies when a user moves an inventory item belonging to his or her resource to another resource using Collaboration Cloud Service. Depending on visibility restrictions, the destination resource may be invisible to the user who originates the move.

      The messages generated by this trigger refer to the origin resource. Use the destination_resource block to retrieve information about the destination resource.

      Use the following placeholders to retrieve information about the destination resource.
      • destination_resource_id

      • destination_resource_external_id

      • destination_resource_name

      Refer to Message Content Overview for details about using blocks and placeholders.

      Visit The visit launch conditions apply to groups of activities, called visits, which are a combination of several related activities for one customer. They are used to send proactive messages to customers for the entire visit, thus avoiding multiple messages for different activities within a single visit.
      Visit Day Before There is a specified number of days prior to visit

      Provides a proactive message to customers within the defined number of days before a visit is scheduled to start. After a five-minute delay to allow the system to accept the other activities that comprise the visit, the message is sent at the specified time before a new or rescheduled visit. The delay also prevents generation of messages for temporary visits, which may be created with visit activities are moved between resources one by one.

      Visit Reminder There is a specified number of minutes prior to visit

      Provides a proactive message to customers within the defined number of minutes before a visit is scheduled to start. The message is sent immediately at the specified time before a new or rescheduled activity. The launch condition is invoked only for pending visits and only once for the same visit. The first customer-related activity in the visit must be an ordered activity in an activated route for the current working day.

      Additional information is required when you select this launch condition:

      • The time prior to the visit in minutes

      • How the time is calculated:

        • Delivery window start

        • Service window start

        • ETA

      • Silent interval

      Refer to Reminder and Change Notification Launch Conditions to understand when the message is sent.

      Visit Change 1 — Visit Change 5

      (For visit) Estimated time of arrival is changed (1st)

      (For visit) Estimated time of arrival is changed (2nd)

      (For visit) Estimated time of arrival is changed (3rd)

      (For visit) Estimated time of arrival is changed (4th)

      (For visit) Estimated time of arrival is changed (5th)

      Provides up to five proactive messages to customers when the estimated time of arrival for the visit has changed. Additional information is required when you select this launch condition.
      • How the time is calculated:

        • Delivery window start

        • Service window start

        • ETA

      • The number of minutes between the time and the last time a message was delivered to the customer, at which point this message will be delivered

      • The range of minutes prior to the activity start during which the launch condition applies

      These launch conditions apply only to pending visits, and the first customer-related activity in the visit must be an ordered activity in an activated route for the current day. They are not invoked in the following circumstances:
      • The Visit reminder is not sent and the current time is within the silent interval for the visit reminder.

      • An incomplete Visit reminder exists.

      • The Visit change message has already been sent and the Visit change message was sent by the same visit change launch condition.

      For more information about the when the message is sent, refer to Reminder and Change Notification Launch Conditions.

      Visit Cancel Visit is cancelled Invoked when a visit is cancelled.
      Visit Complete Visit is completed Invoked when a visit is completed.

        Edit a Launch Condition

        You can edit one or more launch conditions for a message scenario.

        1. Click Configuration.

        2. Click Message Scenarios under Subsystems and Integrations.

          The Message Scenarios screen opens.

        3. In the left panel, select the message scenario that contains the launch condition you want to edit.

        4. Click the launch condition name in the header of the launch condition box.

          The Edit launch condition window opens.
        5. To replace the launch condition, click the drop-down menu and select a new launch condition.

        6. To change the parameters of the launch condition—for example, how a time frame is calculated or the number of minutes before a message is launched—enter new values in the appropriate fields.

        7. Click OK to save your changes and close the Edit launch condition window.

          Delete a Launch Condition

          You can delete one or more launch conditions for a message scenario.

          1. Click Configuration.

          2. Click Message Scenarios under Subsystems and Integrations.

            The Message Scenarios screen opens.

          3. In the left panel, select the message scenario you want to edit.

          4. On the right side of the screen, click the x in the upper right corner of each launch condition you want to delete.

          5. Click OK in the confirmation dialog.

            Note: If you delete all launch conditions for a message scenario, a warning appears under the scenario name in the left column. No message will be generated or sent for message scenarios that do not have launch conditions.

            Launch Condition Warnings and Notes

            If a launch condition is configured improperly, a warning will appear when you try to save it.

            Table Launch Condition Warnings and Descriptions

            Type Text Description
            Note Note: Selected value {PRIOR_TO_VALUE} will be also applied for Reminder and other Change launch conditions. Appears for Change launch conditions when the value of the Notify30_60 parameter is changed.
            Note Note: Selected value {PRIOR_TO_VALUE} will be also applied for Change launch conditions. Appears for the Reminder launch condition when the value of the Notify30_60 parameter is changed.
            Note Note: Selected value {PRIOR_TO_VALUE} will be also applied for Visit reminder and other Visit change launch conditions. Appears for Visit change launch conditions when the value of the Visit notification base parameter is changed.
            Note Note: Selected value {PRIOR_TO_VALUE} will be also applied for Visit change launch conditions. Appears for the Visit reminder launch condition when the value of the Visit notification base parameter is changed.
            Warning This launch condition already assigned to the {MESSAGE_SCENARIO_NAME} message scenario. It will be reassigned to the current message scenario. Appears when you try to reassign a launch condition assigned to another message scenario.
            Error Start time has to be greater than end time Appears when validation fails for start time and end time parameters.
            Error Incorrect parameter value Appears when validation fails. The corresponding field will be highlighted.
            Error Entered time range [{EDITED_TRIGGER_START} – {EDITED_TRIGGER_END}] has intersection with other configuration: {EXISTED_TRIGGER_NAME} [{EXISTED_TRIGGER_START} – {EXISTED_TRIGGER_END}] Appears when a time range for a Change (or Visit Change) event crosses the range of another already configured Change (or Visit Change) event.

              Working with Scenario Steps

              The message scenario steps indicate what should happen when a message scenario is triggered by a launch condition.

              Every message scenario must include at least one start step. Without the start step, messages for the scenario will never be sent. Inner steps are those that are triggered by the results from the start step or a previous inner step. Each step defines the recipient and delivery channels as well as number of notification attempts, notification time, and message parameters. Additionally, you can define message patterns, blocking conditions, and next steps. Refer to Configure a Scenario Step for detailed information about setting up a message step.

              For example, assume you want to send a message to customers when the estimated time of arrival changes. After selecting the Estimated time of arrival is changed (1st) launch condition, you can begin configuring the scenario steps. Your first step may be notifying the customer via an email message that you can configure with information specific to the customer. technician, and activity. You can then add a step that sends an email to the resource assigned to the activity if the customer cancels due to the delay, again using placeholders to provide activity-specific information.

              Each step appears on its own line. For each step, the number of messages to be sent today and a graphic depiction of the number being sent appear on the line. The following color coding scheme is used:
              • Green—No warnings and the channel is active

              • Gray—No warnings and the channel is inactive.

              • Red—Warnings exist or the number of message scenarios is greater than zero and the channel is inactive


              The Scenario Steps window describes the number of sent messages and the number of messages to be sent.

              The line for each step includes an action link that lets you modify or delete the step. You can also modify the step by clicking the step name to open it. Steps that have not been properly configured will display an error message in red.

              Note: If your display is not wide enough, you may not see all of the columns shown in the figure.

                Add a Scenario Step

                You must add at least one step to a message scenario in order for the message to be sent.

                1. Click Configuration.

                2. Click Message Scenarios under Subsystems and Integrations.

                  The Message Scenarios screen opens.
                3. In the left panel, select the scenario to which you want to add a scenario step.

                4. Click the Add new button in the Scenario steps section of screen.

                  The Add scenario step window opens.
                5. Refer to Configure a Scenario Step for information about configuring all the settings for a message scenario step.

                  Edit a Message Scenario Step

                  Each scenario consists of one or more start steps (and, in many cases, inner steps) that you can edit.

                  1. Click Configuration.

                  2. Click Message Scenarios under Subsystems and Integrations.

                    The Message Scenarios screen opens.
                  3. Select the appropriate message scenario from the left panel.

                  4. Do one of the following:

                    • Click the title of the message scenario step you wish to edit.
                    • Click the action button to the right of the message scenario step and select Modify from the drop-down menu.
                    The Modify scenario step window opens.
                    The Modify Scenario Step screen lets you define settings related to a message scenario.
                  5. Refer to Configure a Scenario Step for information about configuring all the settings for a message scenario step.

                    Configure a Scenario Step

                    Configuring a scenario step is a process that offers maximum flexibility. The Add scenario step and Modify scenario step windows contain four tabs from which you can specify the settings related to message generation:

                    • The Settings tab contains the basic parameters of the message generated at a certain scenario step, that is, how, when, and where it should be sent.

                    • The Patterns tab defines the content of the message to be sent.

                    • The Conditions sets the blocking conditions, that is, the conditions under which the message should not be generated at this ste.p

                    • The Next steps tab defines the conditions of the subsequent steps execution.

                    To configure a scenario step:

                    1. Click Configuration.

                    2. Click Message Scenarios under Subsystems and Integrations.

                      The Message Scenarios screen opens.
                    3. Select the appropriate message scenario from the left panel.

                    4. Do one of the following:

                      • Click the scenario step name or click the action button and select Modify to open the Modify scenario step window with the Settings tab on top.
                      • Click Add new to open the Add scenario step window with the Settings tab on top.

                      The Add Scenario Step lets you add a scenario step and define settings related to a message scenario.
                    5. Refer to Settings Tab and complete the fields on the Settings tab.

                    6. Click the Patterns tab and type content into the Subject and Body fields. For information about how the Patterns tab differs for each of the delivery channels, refer to Patterns Tab.

                    7. Click the Conditions tab and complete the fields. For information about the Conditions, refer to Conditions Tab.

                    8. Click the Next steps tab and complete the fields. Refer to Add Next Steps.

                      Settings Tab

                      Use the fields on the Settings tab to define general information about a scenario step for a message scenario, including the recipient, delivery channel, and other message delivery parameters.

                      Table Fields in the Settings tab

                      Field Name Description Possible Values
                      Name The name of the step Name of the steps to a maximum of 64 characters
                      Type The type of step Start, Inner
                      Recipient The person or entity receiving the message. Customer, Dispatcher, Resource, Use Static Address
                      Note: When you select Customer, Resource, or Dispatcher, the recipient’s address is obtained from the activity or resource fields. However, if you select Use Static Address, you must enter a static email address using the notify@example.comformat.
                      Delivery Channel The method used to send the message
                      Note: The methods used are company-specific and correspond to the list of delivery channels configured for the company.

                      Email, Set Property (used to set new property value for entities)

                      Sending time The time when the message is to be sent Select one of following options:
                      • Day of event

                      • Time of event

                      • Day of route

                      For example, if you select Day of event, select +, and enter 2 in the Days field, then the messages are sent after two days from the Day of event.

                      from

                      The time when the scenario step can start

                      Note: This option is not applicable when Sending time is time of event.

                      00:00 – 23:59 or 12:00AM – 11:59PM, depending on the time format settings

                      Sending will time out in The end of the time range during which the message can be delivered, measured in hours and minutes from the sending time 00:01 – 99:59
                      Sending delay Time period in minutes between message creation and message sending 0 – 999
                      Block messages for specific days

                      The days of the week on which proactive customer messages should not be sent

                      Sun – Sat. When a day is selected, messages will not be sent on that day.

                      Block messages for holidays Whether proactive customer messages can be sent on company holidays.
                      Note: The list of holidays can be configured in Company Settings > Holidays.
                      When the check box is selected, messages will not be sent on company holidays.
                      Blocked messages sending

                      The number of days to shift proactive customer messages back in the calendar if messages are assigned for a day of the week for which a block is set or if they are assigned to fall on a company holiday when holidays are blocked.

                      Note: If a message cannot be sent because it falls on a non-working day or a holiday and cannot be shifted to a working day, it will be blocked with the falsemethod status and the NONWORKING_DAY description.
                      0 – 10, when 0 means that the messages will be blocked because there is no shift of days defined.
                      Number of attempts on ‘failed’ status

                      Interval is the maximum number of attempts (including the initial one) to resend a message if it is returned with a Failed notification status. The minutes field defines the number of minutes between attempts to resend the message.

                      This functionality is available for all messages except Set property and External launch condition. The Failed attempts are ignored if:

                      • Scenario processing has been stopped. (Refer to Message Removal Cases

                      • The next attempt cannot be scheduled before the message expires.

                      • Further attempts are pointless, for example, if the email address is invalid.

                      Note: An agent can also stop further Failed attempts or change their number using the fault_attempt and stop_further_attempts fields in a send_message response or a set_message_status request.
                      1 – 999 for both the number of attempts and the minutes between attempts
                      Number of attempts on ‘sent’status

                      Interval is the maximum number of attempts (including the initial one) to resend a message if it is returned with a Sent notification status. The minutes field defines the number of minutes between attempts to resend the message.

                      This functionality is available only for External system messages. The Sent attempts are ignored if:

                      • Scenario processing has been stopped. (Refer to Message Removal Cases

                      • The next attempt cannot be scheduled before the message expires.

                      1 – 999 for both the number of attempts and the minutes between attempts
                      Customer notification time
                      The time range to be communicated to the customer. If the final status for the message is Sent or Delivered, the Customer notification time is stored in the time delivered start/end activity fields.
                      Note: This option is available only when the recipient is Customer.
                      Service Window, Delivery Window, ETA
                      Reply address

                      The email address for the reply

                      Applicable only for the 'Email' notification method

                      any valid email address
                      Email address source

                      The field containing the email address to be used in the 'Email' notification method

                      Not applicable for the 'use static address' recipient

                      any field to be selected from the drop-down list of the email address sources available in the system

                        Patterns Tab

                        The Patterns tab defines the content of the message that is sent for the scenario step. The options for the pattern depend on the selected delivery channel.

                        Every pattern has a subject and body. Some patterns can be defined for several languages, although English is the default language and it is used if the message step does not include a pattern in another language. The different pattern types are described below.

                        Patterns can use placeholders to represent actual values that will be inserted when the message is sent. For example, if you want to include the customer’s name in a message, you can use the {activity_customer_name} placeholder. For more information about placeholders and lists of all allowable placeholders for each entity, refer to Placeholders.

                        Email notification pattern

                        When the delivery channel is email, you can define the subject and body for the message using placeholders to represent the actual value that will be inserted into the message.


                        Patterns tab of the Modify Scenario Step screen.
                        External system notification pattern

                        External system notification patterns for the message body use XML, as shown in the figure.


                        Image showing example of external system notification pattern
                        Set property notification pattern

                        The following message for the Set property delivery channel sets the CANCEL_REASON property to the value with index14, indicating a customer request as defined in the property settings. – 'CUSTOMER REQUEST', as is defined in the property settings.


                        Image showing example of set property notification pattern
                        Note: Values for properties should be defined using an internal format. In particular, use property_label to define the subject value. For enumeration properties, use the index value in a message body rather than its corresponding translation. Translations for enumeration property values are shown in the following figure.

                        Image showing example of enumeration property values
                        External launch condition notification pattern

                        In external launch condition patterns, the body defines the activity information to be passed to an external application, as shown in the figure.


                        Image showing example of activity information to be passed to an external application
                        Timing of message content generation

                        The Patterns tab also lets you define when the message content should be generated. The options are:

                        • On message creation—This option is intended for use when messages are related to synchronizing activity statuses and assignments. If multiple operations are performed for the same activity within a short time period, a separate message should be generated for each operation. Each message should contain activity details that are accurate at the moment of creation. For example, if several sequential move operations are performed, it might be necessary to include from and to values in all intermediate messages.

                        • On message sending–This option is recommended for messages that are generated in advance, such as Day before and other proactive customer notifications.

                          Conditions Tab

                          The Conditions tab is used to define the set of blocking conditions under which the message should not be sent.

                          To define blocking conditions:
                          1. Open the scenario step for which you want to define blocking conditions.

                          2. Click the Conditions tab.

                            The Add Blocking Condition tab for adding conditions to block messages.
                          3. Complete the fields as described in the following table.

                            Table Fields in the Add Blocking Condition tab

                            Field Name Description
                            Condition to block message
                            Field

                            Select the property from the drop-down menu that you want to use as the blocking condition. The menu includes all available properties related to activity, inventory, resource, service request, route, visit, user, and shifts and calendars. Additionally, several other fields, such as interface and day of the week, can be used for blocking conditions.

                            See Blocking Conditions Reference for a complete list of available blocking conditions.

                            Check on
                            Choose one of the following options to define the time when the message’s blocking conditions should be checked:
                            • On creation—The conditions are checked at time of the message generation and not checked again.

                            • On sending—The message is generated and stored in the message queue. The blocking conditions are checked at the time of message sending, which allows the system to account for any changes since the message was generated.

                            • On creation and sending—The blocking conditions are checked at time of both message creation and sending.

                            Condition

                            Select the operator from the drop-down menu that relates the field you selected and the value you will enter. For example, if you want to block a message if the day has not changed, you would select Day changed? for the field, enter no for the value, and select in from the Condition drop-down menu. The menu options include:

                            In–The field value matches the entry in the Value field.

                            Not in–The field value does not match the entry in the Value field.

                            Contains—The field value contains the entry in the Value field.

                            Does not contain—The field value does not contain the entry in the Value field.

                            Note: Do not use the Contains or Does not contain option for enumerated properties.

                            Is empty—The field value is null or undefined.

                            Is not empty—The field value is not null.

                            >

                            >=

                            <

                            <=

                            These operators compare the field value to the entry in the Value field. They apply to integer, string, enumeration properties, and date/time fields.

                            Does not start with—The field value does not start with the entry in the Value field.

                            Starts with—The field value starts with the entry in the Value field.

                            Status
                            Select the final status that will be assigned to the message when the defined conditions are met. Setting the status lets the message be processed further in the scenario, even though the actual message creation is blocked by the defined conditions. The options include:
                            • Failed

                            • Sent

                            • Delivered

                            • False Method

                            • Obsolete

                            Note: If you do not select an option from the Result menu, no message is created.
                            Set message final status
                            Value

                            Type a value that will be compared to the field value with the following operators: In, Not in, Contains, Does not contain, >, >=, <, and <=.

                            You can enter only one value for the >, >=, <, and <= operators. To enter multiple values for the other operators, separate the values with commas.

                            Description
                            Type a description that defines what happens when the message is blocked.
                            Note: The Description field is not enabled until you make a selection from the Result menu.
                          4. Click Add to add the blocking condition.

                            The new blocking condition appears in the Block Conditions tab.
                          5. To add more blocking conditions, repeat steps 1 through 4.

                          6. To rearrange blocking conditions, select an option from the Order drop-down list in the Add/Modify Blocking Condition tab.

                            The system processes the blocking conditions one by one in order of their appearance in the list in the right panel. Checking stops after the first blocking condition is met, so the order of the conditions may change the message-sending logic.
                          7. To delete a blocking condition, select it in the right panel and click Delete.

                          8. Click Save to save the blocking condition addition or changes to the scenario step.

                            In this figure, the blocking condition has been set so that the customer with phone number 555–12345, who has previously confirmed the appointment in another manner, will never receive any messages. Therefore, the message’s final status will be set as Obsolete with the Previously confirmed description.

                            Blocking conditions and message status sections in the Add Blocking Condition tab.

                            Note: For troubleshooting message scenario configurations, ensure that you include properties used in Blocking Conditions and Message Scenario Steps to the Monitored activity and Monitored inventory fields. You can configure the properties on the Configuration, Displays, Display, Activity history screen.

                            Add Next Steps

                            The Next steps tab defines what should happen when the scenario step is completed. You can specify different next steps that depend on the status of the message (for example, whether it was sent successfully or if it failed to send).

                            1. Open the scenario step for which you want to define the next steps.

                            2. Click the Next Steps tab.

                            3. Click the Status drop-down menu and select the status that will be the condition for triggering the next step.

                              The available options include: Sent, Delivered, False Method, and Failed.
                            4. If you want the next step to depend on the description that was added on the Conditions tab, click the Description check box and type the description in the field.

                              When the message step has the status you select and the description matches your entry in the Description field, the next step that you define will be initiated.
                            5. Click the Next step drop-down menu and select the step you want to initiate when the message step is completed and has the status you selected in step 3 and matches the optional description if you entered one in step 4.

                            6. Click Add to add the next step to the panel on the right side of the Next Steps tab.

                            7. To edit a next step, select it in the right panel, click Edit, and make the necessary changes to the Status, Description, and Next step fields.

                            8. To delete a next step, select is in the right panel and click Delete.

                            9. Click Update to save your changes on the Next steps tab

                            10. Click Update again to save the scenario step.

                              Delete a Scenario Step

                              You can remove scenario steps from a message scenario.

                              1. Click Configuration.

                              2. Click Message Scenarios under Subsystems and Integrations.

                                The Message Scenarios screen opens.
                              3. Select the appropriate message scenario from the left panel.

                              4. Click the action link to the right of the message scenario step you want to delete, and select Delete from the drop-down menu.

                              5. Click OK in the confirmation dialog.

                                The step is removed from the Scenario steps section of the page.
                                Note: If you delete the scenario’s start step, an warning message appears under the scenario name in the left column. No message will be generated or sent for message scenarios that do not have a start step.

                                Scenario Step Warning Messages

                                If a scenario step is configured improperly, a warning will appear when you try to save it.

                                Table Scenario Step Warning Messages

                                Message Description
                                Message Step is not reachable
                                Appears when the message scenario step is not reachable, that is, when no other step triggers it as its next step. It can appear for a newly created inner step until it is configured as the next step of another step.
                                Note: This message appears only for scenario steps that are designated as the inner type.
                                Endless loop

                                Appears when the steps create a loop, potentially causing an endless loop situation. Correct this error by modifying the step sequence as needed to prevent a loop.

                                Delivery Channel is missing Appears when a step is configured with a delivery channel, but the system connectivity parameters are missing in the company configuration. Open the Delivery channels screen and configure the missing channel.
                                Delivery Channel has missing credentials Appears when a delivery channel is misconfigured. Open the Delivery channels screen and configure the missing channel parameters.
                                Delivery Channel is inactive Appears when an existing delivery channel is set as inactive. In this case, the step messages will not be sent to the external system. Activate the channel or select a different delivery channel.

                                  Message Sending Interval

                                  Each message has its own time interval within which it should be sent. The corresponding time boundaries are called 'Send from' and 'Send to'. They are displayed as Time range of notification in Activity details > Messages tab > <activity_name> > Message Content.


                                  Image showing message-sending interval

                                  The interval is initially determined on message creation and is automatically adjusted when the recipient's time zone is changed. Also, the 'Send from' value can be updated for a message that supports multiple 'Failed' or 'Sent' attempts. In this case, if the current attempt is 'Failed' (or 'Sent'), the 'Send from' is set to the time when the next attempt should performed.

                                  The 'Send from' value is calculated by doing the following:

                                  1. Determine the start time of the message sending interval without day shift (in the time zone of the recipient).
                                    Image showing start time of message-sending interval

                                    One of these three options apply, depending on the value selected:

                                    • Time of event: The current time in the recipient's time zone

                                    • Day of event: The current date in time zone of recipient + the 'from' value

                                    • Day of route: The route date + the 'from' value

                                  2. Apply the day shift for the message (if needed).


                                    Image showing day shift for message sending
                                    1. Get a date part of the value determined at the previous step.

                                    2. Add day shift, which is the number of days before or after the corresponding event.

                                    3. Apply 'Block messages for specific days', 'Block messages for holidays', and 'Shift blocked messages' rules.

                                  Note: The 'Delay sending by' parameter is not involved in the 'Send from' calculation. It is checked on message sending.

                                  The 'Send to' value is calculated using the following formula:

                                  'Send to' = 'Send from' +  the 'within' value

                                  The 'New' messages are checked against the 'Send to' constraint. If the message has not been processed in time, the server updates it with the 'Failed' status and the 'MESSAGE_STEP_EXPIRED' description.

                                  The system also checks the 'Send to' value for messages with the 'Sending' status. Maximum time to keep expired ('Send to' <= current time) messages in the 'Sending' state is 60 minutes. If the delay time has elapsed for a message, it is removed with the 'Failed' status and the 'MESSAGE_STEP_EXPIRED' description.

                                  Also, the same 'Send to' logic is implemented in all notification methods. It is especially necessary for the messages that might remain in the 'Sending' state for a long time (e.g. customer notifications that require message delivery confirmation).