Hello,

    I cleared all errors and monitor 1 step by step.
I found the error happens when I am saving a new payment with invoice to apply.

   So my question turns to
 Why it would trigger a push notification when I am saving a payment?

I just fell down the same rabbit hole. I discovered this trying to track down why so many resources were going into Push Notifications via a Long Running Process.

My paranoid side was worried this might be some built-in webhook to extract our data to the mother ship. I would hope this is not the case.

The more likely culprit seems to be failed Business Event logic, I can’t find much if any documentation, but it seems that Business Events “Trigger by Record Change” uses this system level “Business Process” Push Notifications to “trigger” said event.

1. If this is the case, can we get the errors pushed up to our Business Events?
2. Can we get some expanded documentation on this Push Notification Destination that doesn’t exist in our defined Push Notifications?
3. Can we get elaboration on “More than one inserted or deleted row matched”? My only Business Event on the page in question tracks the change of one field (Status), I wouldn’t care about any Inserted or Deleted records.

@Chris Hackett can you point us to the right person for a response here?

Hi @dmurray - we need to rely on our experts here to chime in. I am not sure who that might be. As this post is rather old, if you don’t get response you may consider posting a new question and referencing this post. Thank you

@dmurray I’m certainly no expert on any of this, but I have peaked under the hood of the Acumatica Framework a bit. Acumatica has been making more extensive use of SignalR Hubs in recent releases. I wouldn’t be surprised if what you’re seeing is a failure related to an internal messaging process, rather than one you setup yourself. The term “push notification” is kind of a catch-all end user term that could describe a lot of different things. However, I think the underlying technology that enables it is mostly based on SignalR (and in previous releases MSMQ). It’s not clear that the error you’re pointing out is a hard failure, as opposed to an informational message from the logging process attached to the the SignalR Hub saying “I cannot disambiguate the information I’m getting, so I’m not going to try to log this information”).