Server Error
Server Error
Server Error
Server Error
Server Error
Server Error
Server Error
Server Error
Server Error
Server Error
Server Error
Server Error
Server Error
Server Error
Server Error
Server Error
Server Error
Server Error
Server Error
Server Error

Notifications

User defined email and REST API based notifications to manage GRC - long

  • Episodes7
  • Duration25m 13s
  • LanguagesEN
Episode 2

Notification Attributes

Notification key settings

Introduction

In this episode, we will explain the basic attributes of every type of notification. These attributes are basic for you to be able to configure notifications.

Types

There are four types of notifications:

  • Warning: they trigger when a deadline is about to happen (or is already in the past) or when a specific situation happens, such as when an audit is completed or not.
  • Comments & Attachments: they trigger when someone puts a comment or attachment in an item in eramba.
  • Report: they regularly trigger a filter defined by you and email the output to whatever recipient you define
  • Awareness: they trigger an email reminding people they own an item as often as you define

Each one of these notifications has special attributes.

A warning requires you to define what scenario will trigger the notification. There are two options on how to define this:

  • Choose from a list of pre-defined conditions on the notification
  • Choose a Dynamic Status that will trigger the notification. This allows an almost infinite number of scenarios.

Report Notifications:

  • The filter or report you wish to send
  • If you choose filters (instead of graphical reports) if you want to send it as CSV or PDF (graphical reports are sent as PDF by default)
  • How often (every day, every 10 days, etc.)

Comments & Attachment Notifications:

  • The type of trigger you need, when a Comment is created, when an Attachment is created, when a Comment or Attachment is created, Etc.
  • There is an option to avoid sending emails immediately after these conditions match, instead, you can send a daily digest with all comments/attachments.

Awareness Notification:

  • How often you would like to send the awareness notification, this could be every day, every 10 days, Etc.

Scope

Notifications work exactly the same way no matter in which module or sub-module you are. This means you will click on the "Notification" option on the top bar and configure them as you wish.

In the screenshot above, the Internal Control module has three sub-modules (Audits, maintenance and Issues). Each one of these four tabs has a "Notification" settings option.

Whatever notification you create on each module will affect ALL items on that module.

For example:

  • If you create a -1-day (1 day before the deadline) warning notification on the Audit module, that notification will run every night, checking all audit records on the module and looking at those with a deadline the day after.
  • If you create an awareness notification on the Internal Control module that reminds people they own a control every 10 days, then every 10 days eramba will send one email per Internal Control found on the module.

Recipient

On every notification you can choose to send emails or REST calls, by default the "Email option" is selected.  Report notifications can only send emails.

You will be given three or four options, you can choose one or combine them:

  • Users: select one or more users or groups that will receive this notification
  • Custom roles: select one or more roles (from the list of modules in the module you are creating the notification) that will receive the notification. For example: If you are in the Policy module, the roles will be "Policy Owner", "Policy Reviewer" and "GRC Contact".
  • Emails: write one or more emails that will receive this notification.

The "Custom Role" option is important when working with Warning, Comments & Attachments and Awareness notifications.

For example, imagine you want to create an Awareness notification on the Policy module that, every 50 days, reminds the Policy Reviewer Role that they own a policy.

When you create the notification, on the recipient tab you must use Custom Roles and set the "Policy Reviewer" role as the recipient.

The reason is that when this notification runs, it applies to ALL items on that module and every item will have a defined Reviewer. You do not know who that person will be, you simply need to point to the reviewer, whoever eramba finds there will receive the notification.

This same situation happens when you are doing Warnings or Comments and attachment notifications. Some modules have more than one module (sub-modules), for example, the Policy module has a sub-module called Reviews.

If you want to create a notification that triggers 1 day before a planned review date, the warning notification must be created on the "Review" tab, because is on that tab where that deadline is stored. When selecting the recipient you will notice more than one role, this is because you can also select the "Policy" module roles as well as the "Reviewer" module roles, and notice the brackets used in the roles.

Body

On every notification you can define the subject and body of the email, in the Warning, Awareness and Comments & Attachment notifications you can use macros that will display attributes of the item that triggered the notification.

If the Policy named "Security Policy" triggers a -1 warning notification, you can inject the title of that policy into the body (as shown in the screenshot above).

REST Settings

If you select the option of REST APIs when creating the notification you will be asked for:

  • Request Type (GET, POST, Etc)
  • Endpoint (URL)
  • Headers
  • Payload

You can use macros (as explained in the previous section) on your requests, for example, the screenshot below shows how a macro is part of the JSON payload.