Oracle Field Service Cloud Notification Configuration Guide. Release 15.8

Transcription

1 Oracle Field Service Cloud Notification Configuration Guide Release 15.8

2 Copyright 2015 Oracle and/or its affiliates. All rights reserved. Part Number E This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are commercial computer software pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government. This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group. This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services. Documentation Accessibility For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at Access to Oracle Support Oracle customers have access to electronic support through My Oracle Support. For information, visit or visit if you are hearing impaired.

3 Table of Contents 1 Introduction Document Purpose and Scope Target Audience Glossary General Overview Notification-Specific Terminology Notification Workflow Creating a Scenario Defining General Scenario Information Editing General Scenario Information Filling Scenario with Steps 'Add notification scenario step' Window 'Settings' Tab Number of Attempts on 'Sent' and 'Failed' Statuses 'Patterns' Tab 'Events' Tab 'Conditions' Tab Message Sending Interval Triggers 'Day Before' Trigger 'Reminder' and 'Change' Notification Triggers Triggers Related to Route and Activity Actions Escalation Message Triggers 'Manual' Trigger 'Call Ahead' Trigger External Trigger Inventory-Related Triggers Visit-Related Triggers Notification Methods 'Set property' Method Actions 'cancel_activity' 'unschedule_activity' Setting Properties Based on Message Status Received from Agent Message Removal Cases Message Content Placeholders Blocks...58

4 9.2.1 Block Examples Formatting Date and Time Formatting Encoding Placeholder Values Suppressing of Unassigned Variables Printing Blocking Conditions PAS: Submitting Survey Results...73 Appendix: Message Examples...75 Inventory Blocks...75 Message Examples...75

5 1 Introduction 1.1 Document Purpose and Scope This document is intended to give a general understanding of the Notification Functionality, implemented in Oracle Field Service Cloud (hereinafter OFSC), and to describe the basics of its operation and configuration. The document provides an overview of the messaging mechanism and scenarios, including the scenario creation process, triggers to be used to invoke scenarios, blocking conditions to stop the message generation, formatting and message content-related issues. 1.2 Target Audience This document is intended for practicing OFSC users as well as professionals who support integration of OFSC with external client company systems and messaging applications. It is assumed that the reader is familiar with the basics of OFSC functionality. 1.3 Glossary Below is the list of terms and concepts that may be mentioned in the document and will provide a better understanding of the functionality. Please note: The reader, hereinafter, may be addressed as "you". Term Activity API Bucket Capacity Capacity bucket Capacity category Context Daily Extract Delivery window Dynamic Routing ETA Field Description Any time-consuming work performed by a resource Application Programming Interface a particular set of rules and specifications that software programs follow to communicate and interact with each other Entity appearing on the resource tree which can contain resources of a defined type and be assigned activities Workforce possessing the necessary work skills available at a certain moment of time Bucket used for Quota management Predefined set of work skills, work skill groups and time slots within which they are considered by the Capacity API OFSC or API screen showing all available properties and action links Functionality used to extract data from OFSC for further analysis and reporting (previously referred to as DWH) Statistically calculated time period in which a resource is expected to start an activity Routing option allowing to assign only a predefined number of activities to resources and/or assign activities only for a predefined period of time Estimated time of arrival. Predicted time at which a resource will arrive at an appointment and start an activity, calculated dynamically for current and historical data Property present in the system by default

6 Term Forecasting Geocoding Group GUI Historical data Inventory Linked activities Manage Mass activity Message (Notification) Mobility Not scheduled Not ordered Ordered PCC Penalty Planning Preassigned activity Property Quota Repeating activity Resource Resource Tree Route Description Oracle Field Service Forecasting Cloud Service. Feature of OFSC allowing to forecast the company workload on the basis of historical data Process of finding geographic coordinates from street addresses or postal codes Feature on the resource tree identifying a particular type of resource Graphical User Interface, allows to use software by manipulating images rather than by issuing text commands Data of the past periods available in the database or from other sources Equipment that can be installed or deinstalled during an activity Two separate activities related so that the completion or start of one is dependent on the completion or start of the other Oracle Field Service Core Manage Cloud Service (former Manage Application). Serves as the command center for field operations and the central hub for viewing real-time information about resources and their activities across the entire field organization Activity involving 2 or more resources Communications within software (which may or may not be readable by humans), as well as person-to-person communications delivered via computer software Oracle Field Service Mobility Cloud Service (former Mobility Application). A webbased application for mobile resources to execute and manage work-related activities and ongoing communications Activity not assigned to a specific date Activity with an unspecified order of execution in a route, so that it can be executed at any time during the working day. Not-ordered activities do not have defined ETAs or delivery windows Activity with a defined place in a route, which must be performed at a specified time of day. The order of activities can be changed; ordered activities can be changed to not-ordered activities and vice-versa Predictive Customer Communications. Notification solution of OFSC used to proactively communicate with the customer in relation to activities. PCC includes such features as day before notifications, change, reminder and post appointment survey calls. It is the part of the Oracle Field Service Customer Communication Cloud Service. Relative scale representing the expected increase of total cost which a particular factor brings into routing result Company's estimation of the workforce or workload required at a certain moment Activity which was assigned to a specific resource before the routing run Field and field value, assigned to an entity in OFSC (to user, resource, activity or inventory). There are fields and custom properties Amount of work that can be accepted for the bucket Activity recurring with a predefined frequency in a predefined period Element in the resource tree representing a defined company asset Hierarchy of company resources, showing parent-child relationships List of activities assigned to a resource for a specific date, or a list of non-

7 Term Routing Service Window SLA window Teamwork Time Slot User Work Skill Work Zone Description scheduled activities assigned to a resource Process of assigning activities to resources (usually automated) Time frame expected by the customer for an activity as scheduled by the company Interval of time (that may involve a range of dates) within which certain work has to be performed according to the Service Level Agreement Feature that allows resources to assist each other in an activity or on an on-going basis 1) Fixed service window, defined with a name and label, specifying when certain types of activities can be performed 2) Service Window (if the activity type does not support time slots) 1) Person using OFSC 2) Entity used for authentication and authorization, allowing people or external software to access OFSC 1) Activity that a resource is qualified to perform (resource property) 2) Qualification required to perform an activity (activity property) Defined geographical area in which a resource can perform an activity 2 General Overview OFSC supports generation and sending of messages with the help of the Notification Functionality. Using the activity information as the basis, OFSC employs triggers, scenarios, blocking conditions to generate messages that can be delivered to company's customers, resources, administrators, etc., as well as to external systems and internal properties. OFSC messaging mechanism is a highly configurable engine that can initiate sending of different types of messages on different events and situations that occur in the OFSC system. Basic list of notification-specific terms along with a brief description of the notification workflow is presented below to give an overall understanding of the Notification Functionality. 2.1 Notification-Specific Terminology Term Notification Message Agent Message Engine Message Trigger Message Scenario Scenario Event Description Process of delivering a message to one or many recipients Standalone application intended for processing messages initiated by OFSC Part of the application server that generates and processes messages Event or condition in the system, which when occurs, triggers a message scenario Branching event-driven algorithm that consists of one or more steps. A step corresponds to one message and defines when and how this message should be generated, and when and how it should be sent to a message agent Set of rules used to generate further steps following the completion of the

8 Term Start Step Inner Step Message Status Final Message Status Message Description Description current scenario step Initial step of a message scenario that is actually invoked by the relevant message trigger upon a certain predefined action or situation in OFSC (there can be more than one start step) All start steps are performed at the beginning of a message scenario and there should be at least one start step in every message scenario. Step of the scenario that is invoked after the message generated at the previous start or inner step is deleted from the message queue (i.e. after the previous step message receives its final status) Dynamic message property that defines its state in terms of sending. The following message statuses are possible: 'New' status is set in the Message Engine for a successfully created message that is not yet being sent to the message agent 'Falsemethod' status is set by the Message Engine if a message cannot be created due to invalid configuration or missing data 'Obsolete' status is set by the Message Engine if a message is invalidated as the result of an activity-related operation in OFSC (delete, move, suspend, etc.) or another message creation 'Sending' status is set by the message engine when a message is being sent to and initially processed by a message agent 'Sent' status is returned by a message agent when there is no confirmation that the final recipient (person or system) has received the message, e.g. it is commonly used when the message was received by an answering machine) 'Delivered' status is returned by a message agent if a message has been delivered successfully and the final recipient (person or system) has received the message Note: As there is no way to check that an has been read by the customer, the 'Delivered' status is not usually set for , though it is subject to the agent and client-specific rules. 'Failed' status is returned by the message agent if a message cannot be delivered Message status that requires no further processing. The following possible final statuses may apply: 'Falsemethod', 'Obsolete', 'Sent', 'Delivered' and 'Failed' Note: Messages with the 'Sent' or 'Failed' status can be returned to the 'Sending' status and sent again (this is an adjustable predefined option). These statuses are only considered final after all applicable attempts and retries (if any) have taken place. Customer specific message details that along with the message status can influence the message scenario flow. For example, the 'Failed' message status can invoke different scenario steps with the 'no_answer' and 'hang_up' descriptions

9 Term Message Queue Message Blocking Conditions Description Pool of messages for which the final status is not set. When the final status is set, its information is processed by the Message Engine and the message is deleted from the queue and saved in the message log. All messages, regardless of their status, are displayed in the 'Messages' tab of the 'Activity details' and in the 'Messages Report' screen. The messages that obtained their final status are exported to the Daily Extract Message blocking conditions can be defined for a scenario step, and, if such conditions are met, the relevant message is blocked. In this case the message is either generated with a final status or not generated at all

10 2.2 Notification Workflow Below is the Notification workflow diagram (Figure 1) and its brief description. OFSC provides a set of APIs to receive data from different sources, agents and external systems like CRM, Inventory Management and Human Capital Management systems. If, as the result of the received data, a certain condition is met, relevant trigger is activated. The trigger invokes a start step/s of a message scenario in the Message Engine. At the end of every message scenario step a message is generated and saved in the message queue. Each message is processed and eventually receives the final status. If a blocking condition is met, the message is not generated or generated but not sent, and its final status is set. In addition to the start steps there can be inner steps included in the message scenario. An inner step is invoked in accordance with a final status of the message received as the result of the previous step processing. Upon fulfillment of the predefined conditions, the message from the queue is sent to the corresponding message agent via the Outbound API. The scenario is completed as soon as there are no more further steps to be executed. The example of a possible scenario flow is illustrated below (Figure 2):

11

12 3 Creating a Scenario A message scenario can be set up by either creating a new scenario or modifying an existing one. In both cases the following steps are to be performed: 1. The general scenario information is to be filled in or modified 2. The defined scenario is to be filled with steps. 3.1 Defining General Scenario Information The 'Add notification scenario' window will appear (Figure 4). Fill in the fields with the scenario information: 'Scenario Name' field the name of the scenario 'Scenario Label' field a unique scenario identifier 'Scenario From' field the date of the scenario start (selected from the drop-down calendar) 'Scenario To' field and checkbox the date of the scenario end (selected from the dropdown calendar) if the checkbox is not checked and no date is selected, the scenario will run indefinitely Figure 4: 'Add notification scenario' screen

13 For example, a scenario can be created with the following parameters (Figure 5): 'Scenario's Name' 'Example' 'Scenario's Label' 'Ex' 'Scenario's From' 04/07/13 'Scenario's To' 04/14/13 Clicking 'Add' creates the new scenario. Figure 5: Example of a Notification Scenario The scenario will appear in the 'Message Scenarios' screen.

14 3.2 Editing General Scenario Information In order to edit an existing scenario go to 'Company Settings' 'Message Scenarios' (Figure 6). Figure 6: 'Message Scenarios' screen If there are many scenarios on the list you can use the 'View' button to find the scenario that has to be modified. The filters window will appear containing the 'Find' field where the scenario name can be entered, and the number of rows the 'Message Scenario' screen is to contain. The 'Rows' field is mandatory. The default number of rows is '20' (Figure 7). Figure 7: The filters window Enter the scenario name in the 'Find' field and click 'Apply' (Figure 8). Figure 8: Scenario search Those scenarios that match the search key will be shown in the 'Message Scenarios' screen (Figure 9).

15 Figure 9: 'Message Scenarios' screen filtered An existing scenario data can be modified using the 'Modify' link in the 'Actions' column (Figure 10). The 'Edit notification scenario' window similar to the 'Add notification scenario' window will appear (Figure 11). Figure 11: 'Edit notification scenario' window

16 3.3 Filling Scenario with Steps Each scenario consists of one or more start steps and can contain several inner steps. In order to fill the newly created scenario with steps or edit the steps, click the 'Steps' link in the 'Actions' column (Figure 12). The 'Scenarios Steps > '[Scenario name]' screen will appear (Figure 13). Figure 13: Scenario steps screen If no steps have been added to the scenario, the 'There are no steps for this scenario in the system' message will be shown (Figure 14). Figure 14: Notification scenario with no steps If this is the case, click the 'Add new' button for the 'Add notification scenario step' window to open 'Add notification scenario step' Window The 'Add notification scenario step' window includes four tabs which contain the settings related to message generation, namely: 'Settings' tab contains the basic parameters of the message generated at a certain scenario step, i.e. how, when and where it should be sent 'Patterns' tab defines the content of the message to be sent 'Events' tab defines the conditions of the subsequent steps execution 'Conditions' tab sets the blocking conditions, i.e. the conditions under which the message should not be generated at this step 'Settings' Tab The 'Settings' tab contains the basic parameters of the message generated at the current message scenario step, i.e. how, when and where it should be sent (Figure 15).

17 Figure 15: 'Settings' tab of 'Add notification scenario step' window Below is the list and a brief description of the fields included in the 'Settings' tab: Field name Description Possible values Name The name of the step Name of the step (up to 64 characters) Type The type of the step Start, Inner Recipient The addressee of the message Customer, Dispatcher, Resource, use static address Notification Method Send at from within Delay sending by The message sending method Note: the methods used are company-specific. They correspond to the list of Notification Methods configured for the company. The time when the message is to be sent The time when the scenario step can start Not applicable when the 'time of event' is selected as the 'Send at' value The time range during which the message can be delivered (in hours and minutes) Time period between message creation and sending (in minutes) used for sending messages External System: used to customize outgoing interfaces that transfer information from OFSC to the back-office system Set Property: used to set new values for properties within OFSC External Trigger: created as the result of an incoming IVR request initiated by the customer day of event the day of the event triggering the scenario step time of event the time of the event triggering the scenario step day of route the day of the resource's route All options can be set a number of days before or after the corresponding event (+/-). (00:00 23:59) or (12:00AM 11:59PM) depending on the user time format settings 00:01 99:

18 Field name Description Possible values Block messages for specific days Block messages for holidays The checkboxes define days of the week when the messages should not be sent. This parameter is intended to be used for PCC messages. The checkbox defines if the messages can be sent on company-specific holidays. This parameter is intended to be used for PCC messages. checked: messages will not be sent on the selected day(s) of the week not checked: messages will be sent on such day(s) of the week checked: messages will not be sent on holidays not checked: messages will be sent on holidays Shift blocked messages up to [..] days earlier Number of attempts on 'failed' status Number of attempts on 'sent' status Interval [...] min Note: the list of holidays can be configured in 'Company Settings' 'Holidays'. The number of days to shift the messages back in the calendar, if such messages are assigned for a day of the week/holiday for which the block is set. This parameter is intended to be used for PCC messages. Note: if a message cannot be sent because it falls on a nonworking 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. The maximum number of resend attempts (including initial) if the notification status returned is 'Failed' Not applicable for 'Set property' and 'External Trigger' notification methods For further details, please, refer to the 'Number of Attempts on 'Sent' and 'Failed' Statuses' section. The maximum number of resend attempts (including initial) if the notification status returned is 'Sent' Not applicable for the ' ', 'Set property' and 'External Trigger' notification methods For further details, please, refer to the'"number of Attempts on 'Sent' and 'Failed' Statuses' section The time interval between the re-send attempts 0-10 numerical non-zero value without special characters (1-999) numerical non-zero value without special characters (1-999) numerical non-zero value without special characters (1-999) that must be specified if the 'Number of attempts on 'Failed' and/or 'Sent' status is greater than '1'

19 Field name Description Possible values Customer notification time The time range which is to be communicated to the customer If a message final status is 'Sent' or 'Delivered', the 'Customer notification time' is stored in the 'time delivered start/end' activity fields Service Window, Delivery Window, ETA Time Zone Language Static address Reply address address source Survey Applicable only for the 'Customer' recipient The time zone to be used Applicable only for the 'use static address' recipient used with the 'External System', ' ', and 'Set property' notification methods The language to be used Applicable only for the 'use static address' recipient used with the 'External System', ' ', or 'Set Property' notification methods The static address to be used Applicable only for the 'use static address' recipient used with the ' ' notification method The address to send the reply to Applicable only for the ' ' notification method The field containing the address to be used in the ' ' notification method Not applicable for the 'use static address' recipient The field containing the survey to be used Applicable only for the 'External system' notification method any time zone applicable to the company a company-specific language chosen from the drop-down list any valid address any valid address any field to be selected from the drop-down list of the address sources available in the system a company-specific survey chosen from the dropdown list For further details on survey configuration refer to the 'PAS: Submitting Survey Results' section Number of Attempts on 'Sent' and 'Failed' Statuses Attempts on 'Failed' status This functionality is available for all messages except 'Set property' and 'External trigger'. The 'Failed' attempts are ignored if: Further processing of this scenario is stopped (for more information, refer to the 'Message Removal Cases') The next attempt cannot be scheduled prior to expiration of the message.

20 It is not reasonable to make further attempts. For example, if 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. Attempts on 'Sent' status This functionality is only available for the 'External system' messages. The 'Sent' attempts are ignored if: further processing of this scenario is stopped (for more information refer to the 'Message Removal Cases' section) the next attempt cannot be scheduled prior to expiration of the message 'Patterns' Tab The 'Patterns' tab defines the content of the message sent, i.e. sets the message pattern to be used according to the notification method chosen. In general, for every pattern there is a subject and body. Some patterns can be defined for several languages, though 'English' message patterns are the default ones, and they are used if the message step provides no pattern in the client's language. Following are the examples of the message patterns for different notification methods (Figures 16-18, 20): Notification Pattern Figure 16: notification pattern example When the step is performed, an with the subject and body set above will be sent, where the placeholders (inside the brackets) will be replaced with the actual values. External System Notification Pattern In the example, the message body that will be sent upon the step execution is represented in XML (Figure 17).

21 Figure 17: External System notification pattern example Set Property Notification Pattern Figure 18: Set Property notification pattern example As the result of this step (Figure 18), the 'CANCEL_REASON' property will get the value with index '14' 'CUSTOMER REQUEST', as is defined in the property settings. Note: values of the properties should be defined in an internal format. In particular, 'property_label' should be used to define the subject value. For enumeration properties the 'index' value should be used in a message body (rather than translation). To see the translations for enumeration property values, go to 'Properties' 'Modify' (Figure 19).

22 External Trigger Notification Pattern In the example below, the body defines the activity information to be passed to an external application (Figure 20). Figure 20: External Trigger notification pattern example In addition to defining the content of the message in the 'Patterns' tab, there is an ability to define when the message content is to be generated. There are the following two options: Generate content on message creation Generate content on message sending (Figure 21).

23 The "immediate" generation of content is mainly intended for messages related to synchronization of activity statuses and assignments. In some cases, if multiple operations related to the same activity are performed within a short period of time, it is necessary to generate a separate message for each of the performed operations. A particular message should contain activity details at the moment of its creation. For example, if several sequential move operations are performed, it might be necessary to include correct 'from' and 'to' values into all intermediate messages. The second option is preferable for messages that are generated in advance. This option is used for the 'Day before' and other customer-related notifications 'Events' Tab The 'Events' tab is used to define the next steps to be invoked upon the specified final status and/or description of the message (Figure 22). Figure 22: 'Events' tab The 'Events' tab contains the following fields: 'Status' the drop-down list of available statuses; includes all final statuses of the message, i.e. 'Sent',

24 'Delivered', 'False Method' or 'Failed' 'Description' any client-specific description (e.g. 'Confirmed') 'Next step' the step to be invoked if the specified conditions are met. When the conditions are defined, they can be added by clicking the 'Add' button. The 'Change' and 'Delete' buttons can be used to manage the added conditions.

25 For example, if the message gets the 'Sent' status, the next message step will be Step 3 (Figure 23). Figure 23: Scenario event creation - no description set Or, if the message gets the 'Sent' status and the description is empty, the next message step will be Step 4 (Figure 24). Figure 24: Scenario event creation - empty description Or, if the message gets the 'Sent' status and the description is the 'answering machine', the next step will be Step 2 (Figure 25). Figure 25: Scenario event creation - description added To add an event, click 'Add' and the event will appear in the area on the right (Figure 26). To change or delete an event, select it from the list on the right, and then click the 'Edit' or the 'Delete' button, respectively (Figure 27).

26 3.3.5 'Conditions' Tab The 'Conditions' tab is used to define the set of blocking conditions under which the message should not be sent (Figure 28). Figure 28: 'Conditions' tab The fields defining the conditions are described as follows: Field name Description Example Field The value of the property selected from the drop-down list will be used as the blocking condition (Figure 29). The drop-down list includes of all available properties related to activity, resource, inventory, service request, route, visit, user, shifts and calendars. Also, there are several 'other' fields available (interface, day of week, etc.) that can be used for blocking condition logic. Note: in order to see the complete list of available system blocking conditions, refer to the 'Blocking Conditions' section. Figure 29: 'Field' drop-down list

27

28

29 For example, if the customer with the phone number [12345] never wants to receive any messages and has confirmed the appointment in any other manner, the blocking condition can be set as shown (Figure 35). Therefore, if the 'Phone' property contains the value '12345', the message will not be sent, its final status will be set as 'Obsolete' with the 'Confirmed' description. Figure 35: Blocking condition example When the condition is defined it should be added to the list of conditions by clicking 'Add' (Figure 36). After clicking the 'Add' button, the new blocking condition appears in the list of conditions (Figure 37). Figure 37: Blocking condition added to list The conditions selected from the list can be edited, moved up and down the list, or deleted by means of the corresponding buttons (Figure 38). The system processes condition rules one by one downwards, and the checking stops after the first blocking condition is met. Thus, the order of the conditions may change the message sending logic. Note: for those scenarios containing steps, the screen will display the list of steps. Clicking the 'Modify' link, the 'Modify notification scenario step' screen similar to the 'Add notification scenario step' screen, described above, will appear 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 the 'Time range of notification' in 'Activity details' 'Messages' tab '[Activity name] - Message Content' (Figure 39).

30 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 using the following algorithm: 1. Determine the start time of the message sending interval without day shift (in the time zone of the recipient). One of the three options apply depending on the value selected (Figure 40): 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 day shift for the message (if needed) Get a date part of the value determined at the previous step Add day shift, which is the number of days before or after the corresponding event (Figure 41) 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

31 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). 4 Triggers Start step of a scenario is invoked with a trigger. All triggers in OFSC can be divided into two categories: action-driven and condition-driven triggers. Action-driven triggers invoke a scenario as soon as the triggering action occurs in OFSC. The OFSC system is periodically polled, and, as soon as the poll result shows that certain conditions are fulfilled, the condition-driven triggers invoke a scenario. The triggers available in OFSC can be viewed and/or configured in 'Company Settings' 'Notification Triggers' (Figure 42). Figure 42: 'Notification triggers' screen The available triggers are listed below together with their description.

32 4.1 'Day Before' Trigger The 'Day before' trigger is intended to be used for PCC messages. It allows to generate messages to customers that should be sent before the activity within the predefined time period (Figure 43). This action-driven trigger is invoked at the time of a new activity creation or an existing activity reschedule. The trigger is not invoked for non-scheduled, reopened, and 'prework' activities. The 'Day before' trigger 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 (this only affects the messages with the 'Customer' recipient). No 'Day before' messages are generated on the activity move between resources within the same day. 4.2 'Reminder' and 'Change' Notification Triggers The 'Reminder' and 'Change' are condition-driven triggers intended to be used for PCC messages. They invoke message scenarios at the moment of time set in the trigger configuration. The time is calculated in relation to the 'Notification base' that is configured in the 'Reminder and change notifications' selector (Figure 44); it can be one of the following activity fields: ETA delivery window start service window start The 'Reminder' trigger is intended to generate a reminder message to a customer which is to be sent within a fixed time prior to an activity (Figure 45).

33 The 'allowed reminder time' values (e.g. '45, 60, 90') will be shown as the 'Reminder' field values in the 'Activity details' screen (Figure 46). Note: subject to user visibility settings, the 'Reminder' field may appear in Read-only mode. And, there are up to five 'Change' triggers which can be used to send a message if the activity delivery time has changed (Figure 47). 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 triggers 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' (Figure 48).

34 The 'Reminder time' is defined on the activity level ('Reminder' field in the 'Activity details' screen). When the 'Reminder time' is set to 0, the 'Reminder' trigger is disabled for the selected activity. The 'Reminder Time Adjust' is the system predefined time shift for the reminder, that 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' to generate the 'Reminder'. The 'Reminder' trigger can be invoked only once for the same activity. Each of the 'Change' triggers 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 trigger 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' triggers should be configured in a way that they do not overlap. The 'Change' trigger is not invoked if: 'Reminder' is not sent and the current time is within the Reminder Silent Interval Incomplete 'Reminder' exists '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' triggers 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

35 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 their generation and actual sending: Activity status is changed Activity becomes not ordered Activity is moved. 4.3 Triggers Related to Route and Activity Actions This set of triggers belongs to the action-driven category, most of them are invoked by the resource's manual action (Figure 49). Figure 49: Triggers related to route and activity actions Following is the brief overview of the triggers: 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/resource; this trigger is not invoked for 'prework' activities ('regular' and 'reopened' only) Start invoked on activity start; this trigger 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 'notdone' 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 trigger is not invoked for 'prework' activities Note: if the 'suspend' action is performed for a started activity, a new 'suspended' activity is created, and the trigger is invoked for such newly-created activity (with the 'suspended' status).

36 In this case both the 'pending' and the 'suspended' activities have the same property values, and the 'suspended' activity has no inventory. Move activity invoked when an existing activity is moved to another resource or day (Figure 50). This trigger is not invoked for 'prework' activities. The messages generated by the 'Move activity' trigger refer to the 'origin' resource. In order to retrieve information about the 'destination' resource, use the following block: destination_resource In order 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 further details on using blocks and placeholders, see the 'Message Content' section. 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. 4.4 Escalation Message Triggers This group belongs to the condition-driven triggers and is intended to notify about the activities not started on time (Figure 51): 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'; allows setting the second message with a different delay time Figure 51: 'Not started' triggers The 'Not started' trigger can only be invoked for a pending ordered activity ('regular' or

37 '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 (Figure 52). 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 trigger 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: Activity is scheduled after the service window end Activity has not been started the defined number of minutes before the service window end. It 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. Also the "Enable 'SW Warning' trigger" feature should be activated for the corresponding activity type. Configuration There is a 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.

38 SLA window warning intended to notify of a possibility to lose the SLA window (Figure 54). 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. Configuration There is a 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. 4.5 'Manual' Trigger 'Manual' is an action-driven trigger generating messages on creation of a service request (Figure 55). 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' trigger 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 trigger can be used in the following cases: Inventory tracking and hardware testing 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

39 4.6 'Call Ahead' Trigger 'Call Ahead' is an action-driven trigger intended to be used for PCC messages. This trigger is initiated in Mobility when a technician completes a previous activity (Figure 56). The trigger 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 and as soon as the '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' trigger works for Mobility only. 4.7 External Trigger 'External' is an action-driven trigger invoked by HTTP request from the client's external application via the External Trigger API (Figure 57). The 'External Trigger' is used to: Associate incoming voice requests with the message scenario Transfer activity data to the incoming request script Record results of the interaction 4.8 Inventory-Related Triggers 'Inventory-Related' is a set of action-driven triggers used to communicate inventory operations to an enterprise resource planning system and perform automated provisioning (Figure 58): Figure 58: Inventory-related triggers Install inventory invoked when the inventory is moved from the 'resource' pool to the 'install'

40 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 customer's 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. Please note, that the destination resource can be invisible to the current user due to visibility restrictions. The messages generated by this trigger refer to the 'origin' resource. In order to retrieve information about the 'destination' resource, use the following block: destination_resource The following placeholders can be used to retrieve information about the 'destination' resource: destination_resource_id destination_resource_external_id destination_resource_name See the 'Message Content' section for more details on using blocks and placeholders. 4.9 Visit-Related Triggers OFSC can send messages not only for a single activity, but can also generate messages related to groups of activities, called 'Visits'. This option is very convenient if several related activities have to be performed for the same customer. The following group of condition-driven triggers 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 (Figure 59): Figure 59: Visit-related triggers