Pull notifications

Pull notifications

Synigo Pulse allows you to pull notifications to your portal(s), using the Synigo Pulse API. The reason for enabling this is that there are tenants who have implemented these concepts themselves, using for example service busses or data warehouses. Therefore, it is a great addition to also support pulling (or fetching) notifications instead of only pushing them. Now, you can choose whether to design push or pull notifications. Please be aware of the considerations. Push notifications have a minimal impact on the back office systems, thus avoiding a negative impact on the user's perception of the performance. 

How to add a “Pull Notification”

In the CMS you can add a new notification to your notifications collection. This one is called Remote Notification. Here you can add the following information:

Field

Description

Icon

An image, typically a logo of the system to identify the notification.

Title*

The title of a notification instance, for example “Open Topdesk Calls”

Subtitle*

A subtitle of this instance (for example Title: Open Calls, Subtitle Topdesk)

Connection

Select the desired Http connection for this notification (this is a content picker)

Hide when empty
If the result yields no results, or the count is 0, this notification will not be shown.

Groups

The AAD Security groups who are allowed to use this notification

Individuals

Individual users, identified by their UPN, who are allowed to use this notification


* To add the count to the title and or the subtitle add {0} as a placeholder. At this position, the count will be inserted. For example "You have {0} new messages"


Because we don't want normal CMS users to have access to the security settings, these settings are stored as a single connection in the admin section of the CMS, called Connections. These settings have a name, url, method, body and a key-value based structure, which will be translated to HTTP headers, for the request.

Expected Response

If successful, this method returns a 200 OK response code and a single notification. The model is pretty simple: 

HTTP 200 OK
{
   count:3,
}

Field

Description

count: int

The number of occurrences of this notification instance

url: string

Optional: the url which will be navigated to, when the user clicks this notification (optional)


If the status code of the response is not equal to 200, we’ll inform the user, that the retrieval of this notification has failed. The table below will give an indication of what the message will be. 4xx means: all status codes in 400 range, except those explicitly identified (e.g. 404).

Status code

Reason

4xx

Not allowed to access this notification source

404

Notification source not found

408, 429, 504

Too busy, try again later

5xx

Something went wrong, try again later

Defining a connection

A connection is used by a pull notification to retrieve the desired data and has the following settings:

Field

Description

Name

The name of this connection

Url*

The url to the source of this connection

Method

The method to use (selection between GET POST or PUT)

Headers*

A key-value based field where you can add the headers for this  request

Body*
Optionally, add a body for this connection

* Wildcards
You can add the username (upn) to any of the security headers or url, by adding {username} to the text, for example https://mysystem.com/users/{username}/overview 

Security Considerations

  1. The connection details are kept server side, so your users will not have access to this information.
  2. a proxy is added, to hide the actual request from your users. This way no one can see and recreate these requests in an unwanted context.

Design Considerations

  1. With the "Hide when empty" option and optionally injecting the count, you can actually add nudges like "Don't forget to fill out the employee satisfaction survey", which is only shown when count > 0, being the user still needs to fill out this survey.
  2. When hide when empty is false, you'll see a ? as a placeholder where the actual count will be inserted. this is because we actually do not know what the count will be. Also you'll see an animation, informing the user that we're still trying to get the actual result. When done, the ? will be replaced with the actual count.
  3. We wait 5 seconds for your service to respond. After these 5 seconds, we'll display a connection timed out message.

    • Related Articles

    • Notifications on your portal

      Purpose of this article We now support notifications within the portal. This has the advantage that you can see what's happening across your portal for different sources without needing to switch to those sources.  Requirement Please note that your ...
    • How to use push notifications

      Purpose of this article Our native app now supports push notifications. Sometimes you want to reach your colleagues or your students quickly with important messages that shouldn't be overlooked. Since most people have their smartphone with them at ...
    • Release 3.0.5 (May 2019)

      Release 3.0.5 is a minor upgrade leading up to version 4.0 in which we've implemented a lot of new features.  Features CMS upgrade for the native App  Our native app is nearly finished! In this release we'll deploy the CMS changes necessary for you ...
    • Release 4.0.9 (24 march 2020)

      Push Notifications Today we released the push notifications functionality to all of our tenants. please see this article  for more information. Other Fixes We've updated the people directory backend to also support the extra filters for your native ...
    • App Release 1.2 Oktober 2019

      We're very proud to have our native app released to both the Google Play Store and to Apples App Store. Our first version contains the following features: Sign in and out using your Office 365 sign in experience. A dashboard with completely ...