Notification Blueprints

Notification blueprints are containers that you can use to send notifications to specified recipients when a defined trigger occurs, such as adding or updating a record.

Notification blueprints specify the rules for generating the notifications. Use a unique name for each notification blueprint for each instance. Notifications are sent according to the template layout and delivery schedule defined in the blueprint.

Blueprint elements contain the rules for layout template design, delivery, and filter criteria. Notification types determine which blueprint elements are used.

Configuring notification blueprints

When creating and configuring a blueprint, you can:

  • Specify the application it monitors
  • Design the layout
  • Configure the delivery methods and recipients
  • Specify the conditions in the application records that cause an email to be sent

Key elements of a notification blueprint 

The following table describes the key elements of a notification blueprint.

Notification Blueprint Element

Description

General Information

General information defines notification names and letterhead properties. It also specifies how information is displayed.

The Body Layout can be formatted in a table or free form.

The Table layout provides a structured notification as information is presented in a 2 column format.

The Free Form layout provides more flexibility and allows you to arrange content according to the parameters of the Rich Text Toolbar.

Content

Content specifies the notification content including the email subject and body.

Content can vary between notification types and can include dynamic data, static data, and links. Fields are an example of dynamic data, for example, [Field:Date].

Report content can be an attachment or a link to a report.

Delivery

Delivery determines the delivery schedule and recipients of the notification.

Notifications can be queued instantly, sent as a digest (daily, weekly, monthly, or quarterly), or as a reminder based on search-based filter criteria.

Filter Criteria

Filter the record based on specified criteria that must be met to generate the email notification.

Layout template design

The layout template design enables administrators to configure the format and content of notifications. Predefined letterhead templates and body layouts are used to specify the layout of the notifications recipients can receive.

Letterhead

Letterhead templates define the page, header, body, and footer properties used in a notification. A letterhead is not a required element of a notification blueprint, and does not apply to notifications sent in XML format. A default letterhead is specified in Global Notification Settings, but the selection can be overridden in the individual notification blueprint.

Body layout

The body layout defines the format of the layout in the notification body, including how the content is arranged. The body layout can be structured and free form. The structured format presents content in a 2-column table. The left column contains the field name, and the right column contains the field value. The free-form body layouts allow the content to be arranged anywhere in the body of the notification.

The following table describes the arrangement of the body layout.

Body Layout

Arranges Content Located...

Free Form

Anywhere in the body of the notification.

Formal Letter

Within 3 rows.

Dashboard

In a header row with 4 cells underneath.

2 Column 50-50

In 2 equally spaced columns.

2 Column 30-70

In 2 columns. The right column is 30 percent of the body and the left column is 70 percent.

Catalog

In a table in which the right column is narrower than the left column.

Table

In the field names on the left column and the field values on the right column. Table is a structured body layout, and the arrangement of the content cannot be changed.

Content

The content of a notification includes user-defined static content and dynamic content placeholders in the Subject line and Body. Static content is text that remains the same for every notification, while dynamic content changes based on data from specified fields.

The following table describes the types of content.

Type

Dynamic Content Placeholder for...

Field

Data from the fields of the records used for publishing the notification.

Report

Links to global and personal reports that are available from an application or questionnaire.

Link

Links to user pages, administrative pages, and records.

Subject

You can configure the Subject line for all notification types using static and dynamic text and data from fields. A Cross-Reference field appears as a Key Field reference.

Do not use the following field types to create dynamic content in the Subject line:

  • Attachment
  • Cross-Application Status Tracking
  • Image
  • Record Permissions
  • Schedule
  • Sub-Form
  • Questionnaire Reference
  • Access History
  • History Log

Body

The Body is composed of user-defined static content and dynamic content placeholders.

  • Static content is text that remains the same for every notification.
  • Dynamic content is content that changes based on unique parameters and is based on the field, reports, or links you select. When defining content, fields, reports, and links become placeholders for the actual data or content of the notification, which is generated during notification publishing.

Example: Subscription notification with static and dynamic content

The following figure shows an example of content for a subscription notification for Incident Management for reporting an incident to a business unit manager who is waiting on an update. The content in callout 1 shows placeholder field names for the actual field values that dynamically display when the notification is generated.

Content types

Fields that cannot be included as dynamic content in the Subject line are: Attachment, Cross-Application Status Tracking, Image, Record Permissions, Sub-Form, Questionnaire Reference, Access History, and History Log.

Some of the element options vary based on the notification type. Content for the Scheduled Report Distributions notification includes a section for specifying the report and attachment type, for example, PDF, Word, Excel, and others.

Note: For Subscription and On Demand notifications, the type of content you place in the Body area depends on the option you select in the Body Layout field on the General tab.

Notification delivery

Notifications are delivered based on the delivery methods that are configured in the notification blueprint. In most cases, notifications are only sent when a record is saved unless the delivery method is Instantly or Digest. When set to either delivery method, notifications are not sent when saving the record updates a calculated field when there are no other changes to the record.

Delivery methods

The following table describes the types of delivery methods.

Type

Description

Instantly


Notifications are published as soon as possible when a trigger occurs for record-based notifications. An example of a trigger is saving a record.

Digest

Notifications are aggregated and published in a digest. Digest notifications include records that meet the filter criteria, and have been added or updated since the last time the notification was sent. For example, if a daily digest is configured to send every day at 1:00 pm, it will include all records saved since 1:00 pm the previous day.

The data used for publishing the notification are captured each time a record is added or updated. Notification publishing uses the most recent version of a record that passed the filter criteria of the notification blueprint. If the notification blueprint filters are modified within a specified period, the already captured record is still used for notification publishing at the end of the period.

The frequencies are as follows:

  • Daily. Notifications are published once per day based on the notification blueprint.
  • Weekly. Notifications are published once per week based on the notification blueprint.
  • Monthly. Notifications are published once per month based on the notification blueprint.
  • Quarterly. Notifications are published once per quarter on January 1, April 1, July 1, and October 1 based on the notification blueprint.

Reminder


Notifications are published once per day, and typically use date filters that compare a date-based field in each record to the date that the notification is being run. The record collection is search-based, and does not require a save to occur for the notifications to be published. All records for an application or questionnaire can potentially be returned for a record-based notification.

Filter criteria

Filter criteria determine the records that are published in a notification. Only records that meet the specified filter criteria are included in the notification. A notification is not generated unless all criteria is fulfilled.

Example: Criteria for filtering by a date

  • Field to Evaluate = Date
  • Operator = Equals
  • Value(s) = 1/10/2015

Notification blueprint types

The following table describes the notification blueprint types. You can create a blueprint for each notification type.

Notification Type

Description

Record-Based

Record-based notifications contain dynamic or static content of specified fields from a record. The following notifications are record based:

Report-Based

Report-based notifications contain static content based on the user permissions of the user who created the notification report template. Report-based notifications are sent on a required schedule.

These notifications include an embedded report or a link to a report. A link to the report requires the recipient to have an active Archer user account, and recipients can only view the records for which they have record permissions.

The report-based notification is called Scheduled Report Distributions.

Other Data Source

Data Source notifications contain data from other data sources.

System

Admin notifications inform users of important system changes and events that are not directly related to application content. For example, you can set up a notification when a password changes, or when a mail merge job succeeds or fails.