# How to Send SyteLine Business Event Alerts to Infor Ming.le > Source: https://netray.co/erp-help/csi-ming-le-alerts-from-syteline-business-events > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer To get a SyteLine event in front of users in Infor Ming.le, choose one of two routes: have the SyteLine Event System send the signal through a supported notification action, or publish a BOD to ION and let an ION alert or workflow create the Infor OS notification. Pick by recipient logic and volume. Either way, define the trigger narrowly, map recipients from roles, and throttle so alerts stay worth reading. ## Kind how-to ## System syteline ## Erp Infor CloudSuite Industrial (SyteLine) with Infor OS Ming.le ## Module Infor OS / Ming.le / Event System ## Query how to send SyteLine alerts to Infor Ming.le ## Alternate Queries - Ming.le alerts from CloudSuite Industrial events - SyteLine notify user in Ming.le when order changes - Infor OS alert from SyteLine event - SyteLine email alert vs Ming.le notification ## Applies To Infor CloudSuite Industrial (SyteLine) connected to Infor OS with Ming.le and ION; capabilities and menu names vary by release and tenant configuration ## Steps ### How to build a SyteLine to Ming.le alert **Items:** - Write the alert in one sentence: who needs to know, what happened, and what they should do, for example the planner is told when a customer order line date moves out by more than three days. - Decide the route: Event System action in SyteLine for simple, in-ERP triggers, or a BOD through ION for cross-system context and richer routing. - For the Event System route, create the event on the relevant IDO in the Event Handlers form, add a condition on the changed values, and add the notification action your release supports. - For the ION route, confirm the connection point publishes the BOD for that document, then define the alert or workflow in ION Desk against that BOD with a filter on the change. - Resolve recipients from roles or attributes, such as the order planner field, instead of hard-coding user names. - Add throttling: dedupe by document and field within a window, and batch low priority notices into a digest. - Test with real users in a non-production tenant, and track open and action rates before widening the audience. ## Sections ### Two routes and when to pick each **Body:** The in-ERP route uses the SyteLine event system. An event fires on an IDO such as a customer order line update, a handler evaluates a condition and an action runs. This keeps everything in one product, is easy to unit test and works well when the trigger and the recipient both come from SyteLine data. The ION route publishes the business document as a BOD, and ION decides who is notified and how. It suits alerts that need data from other systems, multiple channels, or workflow tasks rather than a simple notice. It adds components to monitor, so only choose it when the extra capability is needed. If email is enough, a plain event with an email action is the least fragile option. ### Designing the trigger so it is not noise **Body:** Most alert projects fail by sending too much. A trigger on every update of an order line will fire on trivial edits and train users to ignore the channel. Trigger on a meaningful state change: a date moved by more than a threshold, a status moving to hold, a quantity shortfall at allocation, a quality hold on a lot. In an event handler, compare old and new values for the specific properties rather than reacting to any save. Include enough context in the message that the user can act without opening the ERP: the document number, the old and new value, the customer and a deep link where your release supports one. **Code:** Alert spec Trigger: SLCoItems update where Due Date changed and abs(new - old) > 3 days Recipients: planner on the order line, plus customer service owner Message: CO {CoNum}-{CoLine} due date moved from {OldDate} to {NewDate} ({Customer}) Throttle: one alert per line per day; digest for the rest ### Recipients, roles and privacy **Body:** Resolve recipients from SyteLine data such as the planner, buyer or sales rep fields, mapped to Infor OS identities. Hard-coded user names rot when people change roles. Test what happens when the field is empty or the user is inactive, and route those cases to a team mailbox. Think about data in the message. A notification can carry customer names, prices or margins to people who should not see them, and notifications may persist outside the ERP's permission checks. Include only what the recipient is entitled to see, and prefer identifiers with a link to the secured screen. ### Operating the alerts **Body:** Review alerts like any other production process. Keep an owner for each alert, a list of thresholds and a quarterly review of open and action rates. Retire alerts nobody acts on. Monitor failure. If the event handler throws, the ION document flow stalls or the user is missing, the alert simply never arrives and nobody notices. Add a heartbeat test alert weekly and watch failed documents in ION Desk. Silence is the worst failure mode for a notification system. ## Pitfalls - Triggering on every update instead of a meaningful change in a specific property. - Hard-coding user names rather than resolving recipients from role fields. - Putting sensitive prices or margins in a notification visible outside normal permissions. - Using ION when a plain event with an email action would do the job. - No monitoring, so a failed handler or document flow silently stops all alerts. ## Ai Angle An AI assistant grounded in SyteLine can help find which alerts are worth building by analyzing history: how often due dates move, where holds occur and who acted on them. It can also draft the alert specification and answer follow-up questions from the notification in plain language. ERPray is read-only by default, and creating or changing event handlers remains a reviewed human step. ## Faq ### Should I use the SyteLine event system or ION for alerts? **Answer:** Use the event system when trigger and recipient both come from SyteLine data. Use ION when you need other systems' data, workflow tasks or multi-channel delivery. Simpler is usually more reliable, so start with the in-ERP route. ### Why are users ignoring our alerts? **Answer:** Usually volume. Triggering on every save sends low-value messages. Narrow to meaningful changes, throttle duplicates, batch minor notices into a digest and retire alerts nobody acts on. ### How do I know an alert failed? **Answer:** Add a heartbeat test alert and monitor failed documents in ION Desk. Without that, a failed handler or inactive recipient looks identical to nothing happening. ### Can a notification include a link to the order? **Answer:** Where your release and Infor OS configuration support drill-back links, yes, and it is preferable to copying data into the message. The link enforces normal permissions when the user opens it. ## Search terms SyteLine Ming.le alerts, Infor OS notifications SyteLine, SyteLine event handler notification, CloudSuite Industrial alert user, ION Desk alert BOD, SyteLine due date change alert, Infor Ming.le social notification, SyteLine event email action --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json