Processes can generate notification messages to inform users about execution outcomes, validation issues, data quality warnings, or anything else worth surfacing. Notifications appear on the Process Execution screen when a run completes, and are stored in the database where they can be reviewed and closed from the Notifications screen.
Notifications are defined in the Process Logic workbook and written to the database via a Process Output targeting the EU_NOTIFICATION object.
Notification severity
Every notification has a severity that determines how it is treated.
Warning — the Process completed and results were written to the database, but something non-critical was detected. Any chained Processes continue to run. Typical uses: records not found for deletion, missing optional configuration, data outside expected ranges.
Error — a significant problem was detected. The Process fails automatically, no results are written, and any chained Processes are not executed. Typical uses: critical validation failures, configuration errors in filters or outputs, required data missing.
Information — a non-critical message with no impact on execution. Visible only when the Logging Level is set to Verbose. Typical uses: confirmation messages, record counts, processing summaries.
The platform also generates its own notifications for certain conditions — for example, when an input range column count mismatches the object structure, or when a numeric output cell is formatted as General rather than a specific numeric format. These platform-generated notifications use the same three severity categories.
Define notifications in the Process Logic workbook
Notifications are defined in the workbook as a table of rows, typically on the energysys worksheet. The standard Process Logic template includes a predefined named range called EU_NOTIFICATION for this purpose. Each row in the range represents one notification. If the first cell in a row is blank, that row is ignored — use this to conditionally suppress notifications using Excel formulas.
Each notification row must include the following fields, in the order they appear in the EU_NOTIFICATION object:
Field | Value |
Severity |
|
Type | Always |
Title | A short description of the issue |
Message | A detailed explanation to assist the user |
Created Date/Time | Timestamp in |
Status | Always |
Application | The name of the application where the notification should appear |
The column order must match the attribute structure of EU_NOTIFICATION. You may define multiple named ranges that write to EU_NOTIFICATION within the same Process — each becomes a separate Process Output.
The first notification row in the template is reserved for the overflow check — it fires if incoming data exceeds the workbook's configured row capacity. Do not remove this row.
Structuring notifications well
Notifications are only useful if they give the reader enough context to act on them. A message like "Process completed" tells the user nothing useful, especially when a workflow runs across multiple entities or date ranges. A well-structured notification identifies the relevant entity, what happened, and when.
A consistent format across all Processes in an application makes the Notifications screen significantly easier to work with. Consider defining a standard like: the Title identifies the entity or scope, and the Message provides the specific detail, date, and outcome. Apply this pattern consistently across every Process your team builds.
Configure a Process Output for notifications
After defining the notification range in the workbook and uploading it to the Process:
Open the Configuration application and navigate to Process Configuration \> Processes.
Select the relevant Process.
In the Process Output section, click Edit.
Add a new Process Output.
Set Location to the named range containing the notification records (typically
EU_NOTIFICATION).Set Object Specification to
EU_NOTIFICATION.Set an Output Order value. Notification outputs do not depend on other outputs and can appear at any position in the order sequence.
Enter an Audit Comment and click Save and Refresh.
Viewing and managing notifications
Notifications generated by a Process appear on the Process Execution screen immediately after the run completes. They are also stored in the database and accessible from the Notifications screen (Processes \> Notifications), where they can be filtered, reviewed, and closed.
Notifications are created with a Status of Open. Once reviewed and actioned, change the status to Closed to remove them from the active list. The Notifications screen functions as an action list — use it to track which notifications have been dealt with.
Note that the Notifications screen shows only notifications associated with the currently selected application. If a Process is configured to write notifications to a different application than the one it runs in, those notifications will appear in the Notifications screen of the target application, not the one where the Process executed.