How do I set notification preferences?

The Notification Preferences page enables administrators to configure the notification rules. Users who have the ORA_SVC_SR_ADMINISTRATOR or ORA_SVC_SR_POWER_USER duty roles can access this page.

Notification preferences are used to select multiple recipients like team members, queue members, and so on. When notification preferences is used, it will override the recipients that are set in the Groovy code.

Here's how you configure the notification rules:
Note: Ensure that your triggers are published.
  1. Sign in to the application as an administrator.

  2. In the Navigator, click Tools > Notification Preferences.

    The Notification Preferences page is displayed.

  3. From the Object drop-down list, select Service Request or Work Order.

    Note: Other supported objects are also displayed in the Object drop-down list.
    1. Click Add. A blank row is added in the table.

    2. To enable the notification trigger, select Yes from Enabled drop-down list.

    3. To prevent users from personalizing this notification through the User Notification Preferences page, select No from the OverrideFlag drop-down list.

      Note: To clean up the user notification preferences data, in case the resource leaves your company or is no longer active, run the Purge Obsolete User Preferences scheduled process. This scheduled process lets your organization ensure that your data on user notification preferences isn't stale.
    4. Select a Groovy notification trigger from the Triggering Event drop-down list.

    5. Enter the Notification Name and Description.

    6. In the Recipients column, click Edit.

      The Configuration for Trigger Name dialog box is displayed.

    7. Select the notification delivery options for the respective recipients.

      For an enabled triggering event, notifications are sent to the specified recipients only if you select at least one delivery option. If any delivery method is selected for a specific recipient, that recipient will also receive bell notifications. Additionally, if you do not select the Bell Notifications option, then no notifications will be sent to the specified recipients.

      The following tables describe the recipients and delivery options for the service request object:

      Recipients for Service Request Object

      Delivery Options for Service Request Object

      • Assigned To: Resource to whom the service request is assigned.

      • Manager of Assigned To: Manager of the resource to whom the service request is assigned.

        If a service level agreement is about to expire, and immediate attention is required, the manager of the resource to whom the service request is assigned, can be informed.

      • Resource Team: Additional resources that have been added to a service request on the Team subtab.

        If you have a team of resources collaborating on a service request, and a trigger such as the service request escalating to Critical status happens, the entire team can be informed.

      • Queue Owner: Owner of the queue.

        If your organization uses manual assignment, the queue owner can be notified when a new service request is associated with a queue owned by the queue owner. For information about the setup steps required to send a notification to a queue owner, see the "Trigger a Notification to the Queue Owner" section.

      • All Queue Members: Send defined notifications to all members of a specified queue, so that they can effectively monitor the queue for open items.

        Queue notifications reduce the need for agents to manually check each queue they are associated with, to see whether there's new work.

        To enable this recipient option, set the profile option ORA_ENABLE_QUEUE_MEMBER_NOTIFICATIONS to Yes. This profile option is disabled by default.

        You should only enable this option if your queues have a small number of participants. If your organization's queues have many members, enabling notifications to all of them might affect application performance.

      • Bell Notifications: Sends a bell notification to the web application.

      • Mobile Notifications: Sends a mobile push notification to the Oracle Fusion Cloud Mobile application.

      • Browser Notifications: Sends a real-time notification to the desktop of the selected users that are signed in the Omnichannel toolbar, when a predefined trigger is executed.

      • Email Notifications: Sends an email notification to the selected internal recipients' primary work email ID saved in the application.

        Note: The from email address is configured through the SVC_OUTBOUND_EMAIL_FROM profile option. If that isn't specified, the default from email address noreply@oracle.com is used.

      The following tables describe the recipients and delivery options for the Work Order object:

      Recipients for Work Order Object

      Delivery Options for Work Order Object

      • Assigned To: Resource to whom the work order is assigned.

      • Created By: The user who created the Work Order

      • Field Service Resource ID: The resource ID being used to complete the work order

      • Last Updated By: The user who last updated the work order.

      • Manager of Assigned To ID: Manager of the resource to whom the work order is assigned.

        If a service level agreement is about to expire, and immediate attention is required, the manager of the resource to whom the work order is assigned, can be informed.

      • Requested By: The user who reported this work order.

      • Bell Notifications: Sends a bell notification to the web application.

      • Browser Notifications: Sends a real-time notification to the desktop of the selected users that are signed in the Omnichannel toolbar, when a predefined trigger is executed.

      • Email Notifications: Sends an email notification to the selected internal recipients' primary work email ID saved in the application.

        Note: The from email address is configured through the SVC_OUTBOUND_EMAIL_FROM profile option. If that isn't specified, the default from email address noreply@oracle.com is used.
    8. To let users follow a specific service request and receive all notifications for that service request, select the Enable Followers check box.

      When enabled, users with the correct permissions will see the Follow option in the Actions menu of the Service Request Details page.

      The notification followers receive notifications for all supported channels, when any notification event is triggered for the service requests they follow.

      To enable this feature for the site, set the ORA_ENABLE_FOLLOW_NOTIFICATIONS profile option to Yes.

      To follow a service request, users must have the SVC_GET_SR_FOLLOW_NOTIFICATIONS permission. This privilege is added to the following ready-to-use duty roles:

      • Service Request Administrator

      • Service Request Channel User

      • Service Request Contributor

      • Service Request Power User

      • Service Request Troubleshooter

      Note: To evaluate whether a resource is still valid and enabled to follow specific service requests, run the Purge Obsolete Notification Followers scheduled process. This scheduled process removes inactive and end-dated users from following the service request, so that the application doesn't get overloaded with stale data. This scheduled process lets your organization ensure that your data on notification followers isn't stale.
    9. Click the New SmartText link and enter the Notification Text for the selected object.

      For more information about using SmartText, see the "Using SmartText" topic.

  4. (Optional) To delete a notification preference, select the row and click Delete. The associated notification text is also deleted.

    Note: If you delete a notification that uses a Groovy notification trigger, you can create a new notification using the same trigger, if no other notification uses it.
  5. (Optional) To modify an existing notification text, click the Update SmartText icon for the selected row.

  6. Click Save.