Creating a policy

In the context of FDD, a policy refers to the establishment of notification preferences. The policy determines the communication method, the message, the recipient group, and escalation patterns.

To create a policy, follow these steps

• Access the FDD homepage.

• Click on the three dots icon at the top right of the page.

• Select "Policies" from the options. This will open the Policies page, displaying existing policies and their descriptions.

To create a new policy:

• Click on the "Create Policy" button located in the top right corner of the page. This action opens the "Add Policy" form.

• The purpose of a policy is to deliver the right message to the right people at the right time. Start by assigning a name to the policy in the "Name" field. It is recommended to name policies based on team structures and event criticality (e.g., Security Team, Engineering Team, Energy Management Team).

• Provide a description for the policy in the "Description" field.

• Next, select the "On create fields". These fields will determine the content of the message when an event is generated. 

• Options include Building, Device Name, Event Description, Event Name, Event Note, Floor, Point Name, and more. 

• Choose the relevant fields based on how you want the notifications to appear to end users. Typically, all fields are selected, but if you're not using escalations, you can exclude them. Similarly, if notifications are intended only for building-level users, the "Building" option can be omitted.

• The "Return to normal notification" and "On end fields" function similarly.

• The "On create fields" trigger a notification when an event is first generated. The "Return to normal notification" determines whether you want to receive a notification when the event returns to normal. 

• If "Return to normal" is selected as "Yes," the "On end fields" allow you to choose the fields for which you want to receive notifications.

• The "Auto Close After" field marks an event as inactive if it remains active for a specified duration. This feature helps handle events that persist over extended periods, preventing clutter and enabling efficient event management.

• Assignees play a crucial role in policies. In the "Group Configuration" section, you can select specific roles or users in your portfolio to receive notifications. Assign the same set of notifications, such as Push, Email, SMS, or Call, to everyone in the selected group.

• Alternatively, the "Custom Configuration" offers more flexibility. You can assign different notification methods to specific roles or individuals. For instance, engineering personnel may receive Push, Email, SMS, and Call, while the Property Manager may receive only Push notifications (lower priority). Moreover, you can choose not to notify the Property Manager initially but trigger a notification after a specified duration using the "Duration in minutes" field. This functionality is useful for events like fire or security alarms. Additionally, you can create unlimited escalations based on previous escalations. For example, you can set a 30-minute escalation after the first notification, resulting in a total of 1 hour before the next escalation. This level of customization allows you to tailor policies according to your specific requirements.

These are the essential steps to create a policy in FDD.

Assigning the policy

Assigning a policy is a crucial step during the configuration phase of FDD. There are two primary methods to assign policies: through routine configuration and during event review.

During routine configuration:

• Select the routines that need to be configured.

• Click the "Configure" button located in the bottom right corner of the screen.

• You will be prompted to choose the policy that applies to the specific routine or set of routines. This selection determines how notifications will be distributed for those routines.

During event review:

• When reviewing an event, you have the option to update the policy assigned to it.

• This provides flexibility to modify the policy associated with a specific event and customize the notification distribution.

It's important to note that policies can be assigned at both the event level and the routine level. If an incident has
rolled up to routines, you need to understand how notifications work in such cases.

Here's how the notification process functions:

• When an incident is generated, you receive a notification.

• As the incident progresses, such as escalating from alert to warning to critical, notifications are triggered at each level.

• When incidents are merged, or when criticalities adjust, you also receive notifications.

• The incident takes on the notification policy of the highest priority event within it.

These steps outline the process of assigning policies in FDD, enabling you to manage notifications effectively.

Notifications

Notifications in FDD are sent through various channels, including Push, Email, SMS, and Call. Let's focus on email notifications as an example.

When an event is created, the user receives an email with the subject "Event Created - Event Name". The event name provides information about the nature of the event. For instance, an email with the subject "Event Created - Fan Cmd Failure" indicates the detection of Fan should be running, but failed to start.

The event email contains the following data (based on configuration):

• Event Name

• Event Description

• Event Note

• Building

• Routine Name

• Device Name

• Point

• Point Value

• Start Time

• Priority

• Floor

These fields are selected during policy creation. The email notification also includes buttons for "View Event" and "Click to Acknowledge Event."

To access configurations and change settings, click on the three dots button at the top right of the FDD page and select "Configs". 

Opening any of the events allows you to modify settings. For example, in the "Base Settings" section on the right-hand side, you can choose the event name, which can be Routine Description, Point Value, Priority, Point Name, Start Time, Building, Device Name, Floor, Routine Name, and more. By default, the event name is the name of the routine.

If policies are created for return to normal events, users receive notifications for them as well. A closed event notification typically includes details such as Event Name, Description, Routine Name, Device Name, Point, Point Value, Start Time, End Time, and more. Closed events are displayed in green to indicate their status.

If one recipient has already acknowledged an event, subsequent recipients clicking the acknowledge button will receive a message stating that the event has already been acknowledged.

Notifications are also sent when the incident priority changes. These emails have subjects starting with "Incident Priority Changed" and contain details about devices and areas.

The notification includes information such as Priority, Start Time, End Time, Building, Events Summary, the number of open events, number of devices, floors, routines, and more. Users can also view individual event details, priority levels, point values, and other relevant fields.

Notifications primarily cover Event Created, Incident Created (merging of events), and Incident Priority Changed. This means that even if there are hundreds of faults, users will receive a maximum of three notifications per incident. The same applies to push notifications, phone calls, and SMS. Push notifications resemble email notifications.

For phone calls, a robotic voice reads out the event details and contents to the user.

These are the main aspects of how notifications will appear in FDD, ensuring users stay informed about relevant events.