Notifications

Attention: SAP Field Service Management documentation is now available at the SAP Help Portal. On 31 December 2020, docs.coresystems will no longer be available. Until that time, documentation will NOT be updated in docs.coresystems.

In a Nutshell

Important: In SAP Field Service Management, there are two types of notification:

  • Notifications: visible in the FSM web apps
  • Push Notifications: visible on mobile apps

Whenever the term Notifications is used, it’s meant for the notifications in the FSM web apps.

The data model for notification is currently Notification DTO Version V8. It consists of four properties:

Property Description
text The content of a notification. It has no maximum length.
title The header of a notification. It can be up to 255 characters long.
type Type can be any string and used for grouping notifications. It can be up to 255 characters long.
read Contains information if a message has been already marked as read. The read state is shared among all users. When a notification becomes marked as read, it is marked as read for all users. For more information, see Create New Notifications section in this document.

The Notification DTO inherits from the SyncObject DTO. Following properties are important for a notification:

Property Description
createDateTime The time when a notification is created.
createPerson Initiator of a notification. In case of a notification being triggered by a user action, the property createPerson contains the ID of this user. In case of a notification being triggered by the system, the property createPerson is empty.
lastChanged Contains the point in time as number, when a notification has been most recently updated. The value of lastChanged needs to be always provided in case a notification needs to be updated.
owners Contains the responsible persons for a notification. As on the database level, there is only one notification created for all users. It is up to the receiver (old notification solution in the Cockpit or new notification solution in Shell) to filter the received notifications by the owners or to fetch only those notifications, which are addressed to the current user. For more information, see Create New Notifications section in this document.

Create New Notifications

The notification bell is always visible.

Important: Whenever a new notification is created, there will be only one notification created in the database for all users. This means that all users will get the same notification and there won’t be individual notifications for each user. As long as the user has the required access right, the user can use the API to fetch all notifications, including those notifications in which the user is not part of the owners. There is no API to get only those notifications, which are addressed to a specific user. Because of this, it is up to the receiver (old notification solution in the Cockpit or new notification solution in Shell) to filter the received notifications by the owners or to create a specific SQL request to only fetch those notifications, which are addressed to the current user. Furthermore, this also effects the unread state. Changing the unread state for a notification will change the unread state for all users as the unread state is part of the notification, which is stored in the database, and there is no other table, which stores the unread state for every user or the like.

Create Notifications by Business Rules

Notifications are in general created by so called Business Rules, which can be created in Admin by following these steps:

  1. Select a company.
  2. Select Business Rules from the side navigation.
  3. Click on Create to create a new business rule or click on one of the existing business rules.

A business rule consists of an event-based trigger, which will execute all defined actions in case the respective event has been triggered. By choosing the action “Send Notification”, a notification will be created in case the provided event is triggered. Please note that Push Notifications can be triggered by the action “Send Push Notification”, which is different. The notification will be always sent to all users and it is only possible to specify the text and the title. It is not possible to define the owners (responsible persons) and/or type. Both the text as well as the title support JS execution like ${moment().format()} that will be executed before the notification is sent.

Current Limitations: So far, the business rules do not support translations of notifications. A notification is displayed in the same language for all users. It is possible to have something like ${i18n.translate(user.settings.Cockpit_SelectedLanguage.data, 'CUSTOM_TRANSLATION_KEY')} as title and/or text. But as the statement is executed, when the notification is created and not when the notification is received by the users, the text will be in the language from the user, who triggered the business rule. This means that all users will receive the text in the language of the creator but not in the language they have selected.

Create Notifications Manually

It’s also possible to create notifications manually in Admin by following these steps:

  1. Select a company.
  2. Select Messages from the side navigation.
  3. Click on Notifications and click on Create to create a new notification.

In comparison to creating notifications by business rules, it is possible to specify owners (to) and a type. But the fields title and text do not support JS execution.

Next to the possibility to create manually new notifications, all existing notifications are shown as long as the current user has the required permissions (see Permissions to Use Notifications section in this document), and it is possible to modify or delete the existing notifications.


Permissions to Use Notifications

It requires specific permissions to trigger notifications by a business rule, to receive notifications in the cockpit/shell, and to execute CRUD operations in Admin.

The permissions are regulated by the object type NOTIFICATION, and can be changed in the user group, which is assigned to your user. To change the permissions, follow these steps:

  1. Go to Admin and choose your account.
  2. Choose Users Groups from the side navigation.
  3. Change the object type NOTIFICATION in section Permissions.

The following table indicates what kind of access is granted for which permission level:

Attribute Value Business Rule Notification Cockpit/ Shell Admin (login with user and account)
create All Business Rule triggers notifications. - Notifications can be created.
create Own Business Rule triggers notifications. - Notifications can be created.
create None Business Rule does not trigger any notification. - Notifications cannot be created.
read All - All notifications are displayed. All notifications are displayed.
read Own - Only the notifications created by the user are displayed. Only the notifications created by the user are displayed.
read None - No notifications are displayed. No notifications are displayed.
update All - All visible notifications can be marked as read. All notifications can be updated.
update Own - Only the notifications created by the user can be marked as read. Only the notifications created by the user can updated.
update None - No notifications can be marked as read. No notifications can be updated.
delete All - - All notifications can be deleted.
delete Own - - Only the notifications created by the user him/herself can be deleted.
delete None - - No notifications can be deleted.

Attention: In order to have access to all notification functionalities, it is recommended to use a user, which is assigned to the predefined user group Admin (or a custom user group with full permissions). Other predefined user group like Dispatcher might have less permissions and therefore cannot use all notification functionalities.

Please note the following:

  • In the old cockpit solution, the current user sees all notifications even such notifications with specified owners and the current user not being part of those owners. However, the current user will only see a pop up, which notifies about a new notification, in case the current user is part of the owners or the new notification has no owners. New incoming notifications are filtered by owners inside the old cockpit solution. In the Shell, the current user sees only those notifications, which has owners and the current is one of them or those notifications without owners. The Shell avoids the necessity of filtering the received notifications by making use of a query, which only provides notifications in which the current user is enlisted as owner or notifications without any owners.
  • A user counts as a creator of a notification, when a business rule triggers a notification and the user is responsible for the business rule taking action or when the username is used to log into the Admin and the user creates manually a notification.

    Important: When only the account is used to login to the admin app, the notification has no creator and the notification is considered as system notification.

  • The UI of the Admin supports the update of the following fields: owners, title, text, and read.

UI

Like in the old cockpit solution, the notifications should be resembled by a bell icon in the Shell’s top bar. In case of unread notifications, there should be a red bubble next to the bell. In addition, the red bubble should contain the number of the unread notifications, which is not the case for the old cockpit solution.

The notifications are only grouped by date rather than type or creator. As a result, neither type nor creator is shown in the Shell notification popover. Furthermore, the date of a group is now part of the group header. In the old cockpit solution, it used to be separate from the group header and multiple groups could be assigned to one date.

The counter in the group header shows in the new Shell solution the number of unread notifications, which belong to the respective group, whereas in the old Cockpit the counter showed the total number of notifications a group contains. In case a group in Shell has no unread notifications, the unread count is not shown. Furthermore, in the group header in the Shell, there is checkmark button, which allows to mark all notifications as read for the respective group.

The content of a notification shown in the Shell is similar to the content shown in the old cockpit solution. It shows the title, the text, and the time when the notification was created. However, there is no red/white dot anymore to indicate a notification as unread/read in the Shell, instead, this is indicated by the notification’s title. If the title is bold, a notification counts as unread. Otherwise, a notification counts as read. The read state of a notification can be changed by clicking on any part of a notification. Like in the old cockpit solution, there is button at the end of the notification popover to mark all notifications as read.

In addition, the avatar (profile picture) has been moved from the group level to notification level. Now, every notification has its own avatar.