4Launch Conditions

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.

    Day Before Launch Condition

    The day before is an action-driven launch condition that generates messages to customers that should be sent before the activity within the predefined time period.

    The day before launch condition is intended for use with PCC (predictive customer communications) messages. It is invoked when a new activity is created or when an existing activity is rescheduled. The launch condition is not invoked for non-scheduled, reopened, or prework activities. The launch condition generates messages only for the activities for which the Enable 'day before' trigger feature is enabled in Company settings > Activity types.

    The day-before messages become obsolete after the following activity-related actions: cancel, delete, start, suspend, reschedule, as well as upon the creation of the Reminder and the Change messages with the Customer recipient. No day-before messages are generated on the activity move between resources within the same day.

    Note: For more information, see the Add a launch condition for a message scenario section.

    Reminder and Change Notification Launch Conditions

    Reminder and change are condition-driven launch conditions intended for use with PCC messages.

    These launch conditions invoke message scenarios at the moment of time set in the launch condition configuration. The time is calculated in relation to the Notification base that is configured in the Reminder and change notifications selector. It can be one of the following activity fields:
    • ETA
    • delivery window start
    • service window start
    The Reminder launch condition is intended to generate a reminder message to a customer which is to be sent within a fixed time prior to an activity. The allowed reminder time values (for example, 45, 60, 90) will be shown as the Reminder field values in the Activity details screen.
    Note: Subject to user visibility settings, the Reminder field may appear in read-only mode.
    There are up to five Change launch conditions which can be used to send a message if the activity delivery time has changed.

    In order for the Reminder and Change messages to be sent, the Enable reminder and change triggers feature should be enabled for the corresponding activity type. At the same time, both launch conditions can be invoked only for a pending ordered activity (regular or reopened) in an activated route on the current working day. The Reminder message is generated within the time period from Reminder Time + Reminder Time Adjust to Reminder Time – Reminder Silent Interval before the activity Notification base. This flowchart shows the relationship between the Reminder Interval between the Reminder Time and the Notification Base changes. This process is described in the paragraphs above and below.

    The Reminder time is defined on the activity level using the Reminder field in the Activity details screen. When the Reminder time is set to 0, the Reminder launch condition is disabled for the selected activity. The Reminder Time Adjust is the system predefined time shift for the reminder, which is used to eliminate the delay in message processing. For example, if Reminder Time Adjust = 3 minutes and Reminder Time = 60 minutes, the reminder will be generated 63 minutes prior to the Notification base. The value of Reminder Time – Reminder Silent Interval defines the minimal time before the Notification base is to generate the Reminder.

    The Reminder launch condition can be invoked only once for the same activity. Each of the Change launch conditions is defined by its own time interval, based on the time remaining to the Notification base, and the threshold value (in minutes). The Change message is initiated when the current time is within a specific Change launch condition time interval, and the difference between the current value of the Notification base and the time previously reported to the customer is equal or higher than the threshold.

    The time intervals of different Change launch conditiontriggers should be configured in a way that they do not overlap. The Change launch condition is not invoked if:
    • the Reminder is not sent and the current time is within the Reminder Silent Interval

    • an incomplete Reminder exists

    • a Change message has already been sent and the last Change message was sent by the same change trigger.

    Before generating messages, the Reminder and Change launch conditions try to cancel all existing customer messages (if any). They use the drop_message SOAP function to cancel messages that are in the Sending status. If the corresponding agent is not accessible, or it returns a result indicating that the message is under processing and cannot be dropped, the generation of the Reminder and Change messages is stopped and will repeat during the next cycle.

    Change and Reminder messages are removed from the message queue if one of the following events occurs after they have been generated and sent:
    • the Activity status is changed

    • the Activity becomes not ordered

    • the Activity is moved

    Note: For more information, see the Add a launch condition for a message scenario section.

    Launch Conditions Related to Route and Activity Actions

    Most of these action-driven launch conditions are invoked by the resources manual action.

    Following is the brief overview of the launch conditions:

    • Activate – invoked on a route activation

    • Deactivate – invoked on a route deactivation

    • Reactivate – invoked on reactivation of a previously deactivated route

    • Add – invoked when a new activity is added or an existing activity is moved to a different day or resource. This launch condition is not invoked for prework activities (regular and reopened only).

    • Start – invoked on activity start. This launch condition is not invoked for prework activities (regular and reopened only)

    • Complete – invoked on completion of a started activity

    • Cancel – invoked when an activity is canceled

    • Not done – invoked when the status of a started activity is changed to not done

    • Delay – invoked on activity execution delays if the activity duration after the Delay action exceeds the threshold value (in minutes)

    • Suspend – invoked when a started or a pending activity is suspended. This launch condition is not invoked for pre-work activities

    Note: If the suspend action is performed for a started activity, a new suspended activity is created, and the launch condition is invoked for the newly-created activity (with the suspended status). In this case, both the pending and the suspended activities have the same property values, and the suspended activity has no inventory.

    A Move activity is invoked when an existing activity is moved to another resource or day. This launch condition is not invoked for prework activities.

    The messages generated by the Move activity launch condition refer to the origin resource. In order to retrieve information about the destination resource, use the destination_resource block

    In order to retrieve information about the destination resource and date, use the following placeholders:

    The Resource changed? and the Day changed? message blocking conditions can be used to determine if the move is to be performed to another resource or to another day.

    Note: For more information, see the Add a launch condition for a message scenario section.

    Escalation Message Launch Conditions

    These condition-driven launch conditions provide notifications about activities that are not started on time.

    Not started 1 – is invoked when an activity has not been started within certain time after ETA.

    Not started 2 – similar to Not started 1. It allows setting the second message with a different delay time. The Not started launch condition can only be invoked for a pending ordered activity (regular or reopened) in an activated route which belongs to the current working day. The Enable not started trigger feature should be enabled for the corresponding activity type. The Not started 1 and Not started 2 messages are independent and can be generated for the same activity at the same time.

    Not activated – sent if the resource has not activated their route the defined number of minutes after the planned start of the working day, according to the calendar. It works only once a day for a specific route. The messages are not generated again if the calendar has been changed. If any not activated in time messages are present for the resource at the moment of route activation, these messages become obsolete. For a new resource the Not activated in time messages are only generated on the next day (in the company time zone) after its creation. This launch condition is only invoked for resources with the Enable Not activated in time alert and trigger feature enabled.

    Service window warning – intended to notify of a possibility to lose the service window (Figure 53). It is sent in either of the following two cases:
    • the Activity is scheduled after the service window end

    • the Activity has not been started the defined number of minutes before the service window end.

    This trigger is only invoked for pending ordered activities (regular or reopened) in an activated route with a service window that belongs to the current working day. This trigger is invoked only once per activity. You should also activate the Enable SW Warning trigger feature for the corresponding activity type.

    Configure this trigger using the threshold parameter near the Service window warning trigger selector on the Notification Triggers screen. It defines the number of minutes before the end of service window that is used in the condition.

    SLA window warning – intended to notify of a possibility to lose the SLA window. This trigger is only invoked for pending or started activities (regular or reopened). The warning is sent if the activity has not been started (for pending activities) or completed (for started activities) the defined number of minutes before the SLA window end. It is invoked only once per activity. But, if SLA window end has changed after the generation of the SLA window warning messages, the trigger can be invoked again.

    Configure this trigger using the threshold parameter ( hours/minutes) near the SLA window warning trigger selector on the Notification Triggers screen. It defines the number of minutes before the end of the SLA window that is used in the condition.
    Note: For more information, see the Add a launch condition for a message scenario section.

    Manual Launch Condition

    The Manual action-driven launch condition generates messages on the creation of a service request.

    When creating a service request, a user should select the service request type and fill in the fields related to it. The message subject/body pattern for the Manual launch condition can contain placeholders that are related to the service request itself and to all its parent objects. For example, if the request is created on the activity level, the content can contain placeholders related to request, activity, route and resource.

    The launch condition can be used in the following cases:

    • inventory tracking and hardware testing

    • I/initiating SRO or sending any other form

    • initiating support requests

    • manually generated cases when transaction is initiated by a person and is not related to the activity

    • other activity or inventory requests

    Note: For more information, see the Add a launch condition for a message scenario section.

    Call Ahead Launch Conditions

    This action-driven launch condition is initiated in Mobility when a technician completes a previous activity. It is intended for use with PCC messages.

    The launch condition is used to:
    • inform the customer

    • initiate provisioning or hardware test while the resource is on the way.

    When configured, the Complete activity screen has the mandatory Next Activity field. The resource is to select the next activity. When Complete activity form is submitted in Mobility, the system generates the Call ahead for the next activity (selected by the resource).

    Note: The Call ahead launch condition works for Mobility only.

    Note: For more information, see the Add a launch condition for a message scenario section.

    Inventory-Related Launch Conditions

    These action-driven launch conditions are used to communicate inventory operations to an enterprise resource planning system and perform automated provisioning.

    • Install inventory– invoked when the inventory is moved from the resource pool to the install pool or when a new install inventory record is created (other than those in the resource pool)

    • Deinstall inventory– invoked when the inventory is moved from the customer pool to the deinstall pool or when a new deinstall inventory record is created (other than those in the customer pool)

    • Exchange inventory– invoked when an inventory exchange between the resource and the customer pool is performed

    • Undo install inventory– invoked when the inventory is moved from the install pool to the resource pool

    • Undo deinstall inventory– invoked when the inventory is moved from the Deinstalled pool to the customers pool

    • Move inventory– invoked when inventory is moved between different resources. It is invoked when an inventory item that belongs to a resource of a current user is moved by this user to another resource via SmartCollaboration. Note that the destination resource can be invisible to the current user due to visibility restrictions.

    The messages generated by the Move inventory trigger refer to the origin resource. In order to retrieve information about the destination resource, use the destination_resource block.

    The following placeholders can be used to retrieve information about the destination resource:
    • destination_resource_id
    • destination_resource_external_id
    • destination_resource_name
    Note: For more information, see the Add a launch condition for a message scenario section.

    Visit-Related Launch Conditions

    The system can generate messages related to groups of activities called visits.

    The following group of condition-driven launch conditions is intended to be used for PCC messages to prevent the same notifications sent to the same customer on different activities within the same visit.

    • Visit Day Before – similar to the activity Day before launch condition but is applied to a visit. The only difference is that the message is created with a 5-minute delay after the visit creation to let the system accept other activities that compose the visit. The delay is also useful to prevent generation of messages for temporary visits, which may be created when visit activities are moved between resources one by one.

    • Visit Reminder – similar to the activity Reminder launch condition, but is applied to a visit. This launch condition is intended to generate a reminder message to a customer which is to be sent a fixed time prior to a visit. It can be invoked only for pending visits and only once for the same visit. In addition, the first customer-related activity in the visit must be an ordered activity in an activated route for the current working day. The Visit reminder message is generated within the time period from [Visit Reminder Time + Reminder Time Adjust] to [Visit Reminder Time – Visit Reminder Silent Interval] before the Notification base.

    Parameters:

    Notification base – ETA/delivery window start/service window start from the first customer-related activity in the visit. A certain field selection is configured in the Notification Triggers screen using the Visit reminder and change notifications selector.

    Visit Reminder Time is the time before the Notification base to send the reminder. As opposed to the regular launch conditions, this parameter is defined on the company level.

    Reminder Time Adjust is the system predefined reminder time shift to be used to eliminate the messages processing delay.

    For example: if Reminder Time Adjust = 3 minutes and Visit Reminder Time = 60 minutes, the reminder will be generated 63 minutes prior to the Notification base.

    The value of (Visit Reminder Time – Visit Reminder Silent Interval) defines the minimal time before the Notification base to generate the reminder.

    • Visit change 1...Visit change 5 – similar to the activity Change launch conditions, but applied to a visit. There are up to five Visit change launch conditions which can be used to send a message if the visit delivery time has changed.

    The Visit change launch condition can be invoked only for pending visits. In addition, thefirst customer-related activity in the visit must be an ordered activity in an activated route for the current working day.

    The Visit change message is initiated when the current time is within the time interval of a specific Visit change launch condition, and the difference between the current value of the Notification base and the time previously reported to the customer is equal or higher than the threshold.

    The time intervals of different Visit change launch conditions should be configured in a way that they do not overlap.

    The Visit change launch condition is not invoked if:

    • Visit reminder is not sent and the current time is within the Visit Reminder Silent Interval

    • Incomplete Visit reminder exists

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

    Before generating messages, the Visit reminder and Visit change launch conditions try to cancel all existing customer messages (if any). They use the drop_message SOAP function to cancel messages that are in the Sending status. If the corresponding agent is not accessible, or it returns a result indicating that the message is under processing and cannot be dropped, the generation of the Visit reminder and Visit change messages is stopped and will repeat during the next cycle.

    • Visit cancel – initiated when the last of the activities in a visit is canceled (none are pending, completed, or not done). This launch condition can be invoked several times for the same visit when new activities are added to an existing canceled visit.
    • Visit complete – initiated when the last pending activity in a visit gets a final status, and at least one activity is completed or notdone. This launch condition initiates the PAS scenario and is invoked only once, when the visit becomes completed or notdone for the first time.

    Visit launch conditions are designed to be used mostly for customer interactions reducing the number of day before calls, reminders, change messages and PAS messages to the same customer.

    Note: For more information, see the Add a launch condition for a message scenario section.