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.
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 .
The day-before messages become obsolete after the following activity-related actions:
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.
Reminder and Change Notification Launch Conditions
Reminder and change are condition-driven launch conditions intended for use with PCC messages.
Notification basethat is configured in the Reminder and change notifications selector. It can be one of the following activity fields:
- delivery window start
- service window start
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.
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 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.
the Activity status is changed
the Activity becomes not ordered
the Activity is moved
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
Delayaction 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
suspendedactivity 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
In order to retrieve information about the destination resource and date, use the following placeholders:
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.
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.
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.
Manual Launch Condition
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
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.
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).
Call ahead launch condition works for Mobility only.
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
resourcepool to the
installpool or when a new
installinventory record is created (other than those in the resource pool)
Deinstall inventory– invoked when the inventory is moved from the customer pool to the
deinstallpool or when a new
deinstallinventory 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
installpool to the resource pool
Undo deinstall inventory– invoked when the inventory is moved from the
Deinstalledpool 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
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.
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.