# How to Set Up Business Events and Actions in IFS > Source: https://netray.co/erp-help/ifs-how-to-set-up-business-events-and-actions > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer IFS Business Events fire when a defined condition on a Logical Unit is met, such as a new record, an update, or a specific attribute changing, and Actions subscribe to those events to send email, invoke a workflow, or call an external service. Both are configured in Solution Manager (or the Events and Actions work area in IFS Cloud) without requiring custom PL/SQL for most standard cases. ## Kind how-to ## System small-erp ## Erp IFS Applications / IFS Cloud ## Module Extensibility / Events and Actions ## Query How to set up Business Events and Actions in IFS ## Alternate Queries - IFS Events and Actions configuration - IFS Cloud trigger email or workflow on data change - IFS Applications event action setup - IFS Cloud webhook on record update ## Applies To IFS Applications 9 and 10, and IFS Cloud ## Steps ### Configure a Business Event and Action in IFS **Items:** - Open Solution Manager, or the Events and Actions work area in IFS Cloud. - Under Business Events, locate or create an event tied to the target Logical Unit (LU) you want to monitor. - Define the trigger condition: New, Modify, Remove, or a change to a specific attribute value. - Add a filter condition or expression if the event should only fire under certain business rules, not on every matching transaction. - Enable the event; events are created inactive by default and do nothing until explicitly turned on. - Under Actions, create a new action and select its type, such as Email, Workflow, Connect, or a custom method call. - Bind the new action to the business event created above. - Use the event's available attributes and tokens to populate the email body or workflow parameters dynamically. - Test by performing the triggering transaction in a non-production environment and confirming the action fires as expected. ## Sections ### Business Events vs Workflows **Body:** Business Events are the trigger layer: they detect that something happened on a Logical Unit and hand off to one or more Actions. Workflows, by contrast, are the process layer, often started as one of those actions, modeling a multi-step approval or task sequence with its own state. Using an event to kick off a workflow, rather than trying to build multi-step logic directly inside a single action, keeps each piece doing one job and easier to maintain. ### Available action types **Body:** Email actions send a templated message using event attribute tokens, which covers the majority of simple notification use cases with no development effort. Workflow actions launch a defined process instance, useful when the event should start an approval chain rather than just alert someone. Connect (webhook-style) actions call an external endpoint, which is the usual pattern for integrating IFS with a message queue, another SaaS system, or a custom microservice reacting to ERP changes in near real time. Custom method actions call a PL/SQL procedure directly for logic too specific for the built-in action types. ### Performance considerations **Body:** Every enabled event adds evaluation overhead to the transaction that could trigger it, since the platform has to check the event's condition on each relevant insert, update, or delete against that Logical Unit. Broad trigger conditions, such as any Modify with no filter, on a high-volume LU like a sales order line can measurably slow down normal transaction processing across the system, not just the specific record being watched. ### Troubleshooting events that do not fire **Body:** The most common reason an event appears broken is that it was never enabled after creation, since the default state is inactive. After confirming the event is active, check that the filter expression actually matches the test transaction, and confirm the action itself is bound to that specific event rather than a similarly named one left over from testing. ## Pitfalls - Leaving a test event enabled in production, causing unexpected emails or workflow starts on real transactions. - Overly broad trigger conditions, such as any Modify, firing on routine system housekeeping updates rather than meaningful business changes. - Forgetting that new events are created inactive; nothing happens until the event is explicitly enabled. - Referencing attributes in an email template that are not exposed by that particular event, producing blank tokens in the output. - Chaining many events and actions across the same transaction path, creating hidden performance drag that is hard to trace back to a cause. - Not testing in a lower environment first, since events fire immediately as part of the live transaction rather than after it fully commits. ## Ai Angle ERPray for IFS, grounded on the actual Logical Unit fields and existing event and action configuration, can help draft a filter condition in the right syntax and explain why a specific event did not fire for a given transaction, saving the back-and-forth of manually walking through Solution Manager screens to compare a broken event against a working one. Enabling an event in production, or binding a new action to it, stays a change made deliberately by an administrator, since it affects live transaction behavior. ## Faq ### Can IFS Business Events call an external REST API? **Answer:** Yes, using a Connect or webhook-style action type, which lets an event push data to an external endpoint such as a message queue or another SaaS system, making it a common integration pattern for near-real-time synchronization out of IFS. ### Can event and action configuration be version-controlled? **Answer:** Yes, event and action definitions are typically exportable as part of an IFS configuration or solution package, which lets teams move them between environments in a controlled way rather than recreating them manually in each one. ### Do Business Events fire on bulk or batch imports? **Answer:** It depends on the API path the import uses; imports that go through the standard business logic layer typically trigger events normally, while some low-level bulk load paths can bypass event evaluation, so this should be verified for the specific import method in use. ### How do I debug an event that isn't firing? **Answer:** Confirm the event is enabled (new events start inactive), verify the filter condition actually matches the test transaction, and check that the action is bound to that exact event rather than a similarly named leftover from testing. ## Search terms ifs business events and actions, ifs cloud events and actions setup, ifs applications event trigger, ifs solution manager business event, ifs webhook action, ifs workflow trigger on data change, ifs logical unit event, ifs connect action --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json