Skip to main content
Question

Business Events working inconsistently!

  • August 8, 2026
  • 4 replies
  • 36 views

Jupiter
Freshman I
Forum|alt.badge.img

Hi All, this question relates to our customisation and business events, so not sure if it already covered in general topic, but it is then happy for one of you to direct me there.

Now in our setup of 2023R1 (I know its old and we are planning to upgrade) we have added a custom field to the customer screen.  Based on the value of this custom field couple of business event gets fired up in the back ground that updates the Payment methods on the customer with certain logic.  Our problem is related to ARDD payment method where in-consistently on a small number of customers these ARDD payment methods are not linking to the customer even when the business even has run and finished.

I have been going back and forth with MYOB Support for months and now the final gist that we are being told is that we should not use business events but instead get MYOB Support to customise the same via code which is more reliable.  Is this true?  For something that has been working flawlessly for 3 years, now is an unreliable way to customise?  Is there any way to debug business event as user level?  All I know is the name of the business events that run, but have no idea on how to diagnose why it works on most and not on all.

4 replies

darylbowman
Captain II
Forum|alt.badge.img+17

If your question is whether code is more reliable than a Business Event, the answer is yes. I've seen a miriad of issues causing BEs to fail for no apparent reason.

I RARELY recommend BEs as a reliable way to change data. If they do work, they often trigger concurrency warnings (e.g. this record had been modified by another user). What they are really useful for is sending notifications.


Forum|alt.badge.img+4
  • Jr Varsity II
  • August 9, 2026

Hi ​@Jupiter ,
Business events are absolutely a supported mechanism for automation - they're not inherently "unreliable." The issue you're describing sounds like a silent action failure rather than a platform problem. Here's how to diagnose:
Debugging Steps:
1. Enable Trace Logging (SM201060) - set to Verbose, reproduce the issue, then review for exceptions tied to the affected customer records.
2. Request Profiler (SM205070) - capture the actual web service calls the business event makes. You'll see if the API call to add the payment method returns an error that the event swallows silently.
3. Check Business Event History Details - in SM302050, drill into the specific event execution for a failed customer. The "Details" tab should show individual action outcomes, not just the overall trigger status.
Most Likely Root Causes:
- Record locking - if another user or process has the customer open, the payment method update can fail silently. Check if affected customers are being edited around the same time.
- Validation failure - ARDD payment methods often require specific fields (bank details, mandate references). If any required field is empty or invalid for certain customers, the action fails without surfacing the error.
- Duplicate detection - if the payment method partially exists (e.g., from a prior partial run), the event may error on trying to add it again.

 

Hope above helps!!


darylbowman
Captain II
Forum|alt.badge.img+17

...they're not inherently "unreliable."

I would argue that failing silently for any reason is the definition of 'unreliable'.


Jupiter
Freshman I
Forum|alt.badge.img
  • Author
  • Freshman I
  • August 9, 2026

Hi ​@Jupiter ,
Business events are absolutely a supported mechanism for automation - they're not inherently "unreliable." The issue you're describing sounds like a silent action failure rather than a platform problem. Here's how to diagnose:
Debugging Steps:
1. Enable Trace Logging (SM201060) - set to Verbose, reproduce the issue, then review for exceptions tied to the affected customer records.
2. Request Profiler (SM205070) - capture the actual web service calls the business event makes. You'll see if the API call to add the payment method returns an error that the event swallows silently.
3. Check Business Event History Details - in SM302050, drill into the specific event execution for a failed customer. The "Details" tab should show individual action outcomes, not just the overall trigger status.
Most Likely Root Causes:
- Record locking - if another user or process has the customer open, the payment method update can fail silently. Check if affected customers are being edited around the same time.
- Validation failure - ARDD payment methods often require specific fields (bank details, mandate references). If any required field is empty or invalid for certain customers, the action fails without surfacing the error.
- Duplicate detection - if the payment method partially exists (e.g., from a prior partial run), the event may error on trying to add it again.

 

Hope above helps!!

Thanks ​@Rakshanda, MYOB support also mentioned something similar, and it is worth trialing because we would prefer to stay on BE as the coding effort from MYOB is a bit blown up and on they can do it for us.  But more importantly we do not have the full documentation of the BE which is a challenge to begin with.