Event Based Alerts

This document describes the concept of using events to create user defined alerts based on information included in the events. The alerts are managed and stored as an M3 application message. The M3 application message can either be sent as an e-mail or sent to Infor Ming.le™ as an alert task. It can also start a workflow in Infor Intelligent Open Network (ION).


M3 BE includes a large number of predefined application messages coded into the business logic but for some customers, these are inadequate and new messages have been added to the M3 product as modifications. In most cases, the event based alerts removes the need for coding new messages.

Follow these steps

  1. Add a subscription to the M3 table to be used for the alert in 'Event Subscription. Open' (CMS045). The name of the M3 table is used as event name and M3 as a publisher.

  2. Activate the subscription for event based alerts and set it as active.

    Define the alert

  3. Define the alert in 'Event Based Alerts. Open' (CMS047).

    Trigger alert

    Define when the alert should be triggered using filters where logical expressions like "Value changed", "Equal to" etc can be used for specific fields.

    Posted into Infor Ming.le

    Select if the alert is also to be posted into Infor Ming.le.

    Alert message to be generated

    Define the alert message to be generated.

    Recipient of the message

    The recipient is always a defined M3 user but does not need to be a licensed user, and can either be a fixed user, retrieved from a field in the event or retrieved from a related table like item responsible from the item master for a sales order line event.

    From both a performance and volume perspective, it is important that the filters are defined correctly and thoroughly tested in an environment with fewer transactions than a production environment. Since a normal M3 environment generates several hundred events per second, poorly defined filters can quickly generate massive amounts of alert messages.

    Post definition steps

  4. Once the alert has been defined, the corresponding autojob must be restarted before the updated subscriptions become active in the Event Hub and the new definitions updated to cache.

    Restart the autojob in 'Subsystem. Open' (MNS050) and select related option 'Job in subsystem' (Option 11) for the autojob subsystem (normally named ASJ).

  5. Find the autojob CMS911 (Event subscription - alerts) in the list.

  6. End it and once stopped, start it again.

View alerts

The event based alerts can be viewed in various ways such as email, through the M3 application message widget in M3 H5 or Infor Ming.le Homepages, directly in the M3 function 'Application Message. Open' (CRS420) or as alerts, tasks and workflows in Infor Ming.le. The alert itself contains the message defined in the base program (CMS047) and usually a drillback link to the original M3 db record that triggered the event. Note that drillback links for events generated from customer defined fields (CDFs) that extend a standard M3 table, relate back to the main program for the extended table. Main program in this case is retrieved according to setup in function 'Table. Open' (MNS120).


The best way to troubleshoot the generation of the alerts is to turn on the concept log for the required autojob in the server view, or admin pages in a cloud environment. Once activated, generate a new event and then view the concept log written to the autojob log. Every validation performed within the autojob is written to the log as a readable text.

Related topics