We have an interface running on Sales Orders, Item Data and Customer Data (business partner data). We enriched the standard BOD (or developed a complete customized BOD) and use triggers on "related tables" to get updates.

Focused on the SalesOrderBOD: every line added changes the order amount and thus triggers a BOD update (and yes, we did add triggering on SO status < confirmed, so we are to blame).

Focused on Item Data (for webshop) every change in the Item Data (including stock levels, pricing, ISA or IPU data) does trigger a BOD, and often they are quick one after another and (almost) identical (and also here we added additional triggering on related tables).

I tried to implement a mechanism to recognize "premature data" in the BOD (like no customer name stored yet) and in such cases do not enrich the BOD with the extension, but I was wondering, is there a way to "group" BODs in one BOD instead of have a (incomplete) BOD after each intermediate commit?

How do you cope with "redundant or premature BODs"?

The session BOD Implementation Registration offers a staging option (for some BODs). Is that useful here? What is the LN version here?

I have 10.7 on prem, staging will just hold BODs, but not filter them, as far as I could see. So no, it will not be useful.

1 prevent triggering a premature BOD
2 there are Public Interface functions for staging as well: BOD.HandleStagingBeforeProcessingIncomingRequest and BOD.HandleStagingAfterProcessingIncomingRequest. This can be used in case the last trigger of the BOD result is a good version and not a premature one.

1 prevent triggering a premature BOD
Easier said than done. Like we insert a "skeleton" BP record to update it later with relevant data from different other sources. Each update on the BP record initial and later will trigger a premature BOD. Only after we filled the last data the BOD is no longer premature.
So that was one of the hooks for this question: is there a way to tell the STP/DAL Not to send a BOD in case of .... no name filled, no start date or things like that?

2 there are Public Interface functions for staging as well: BOD.HandleStagingBeforeProcessingIncomingRequest and BOD.HandleStagingAfterProcessingIncomingRequest. This can be used in case the last trigger of the BOD result is a good version and not a premature one.I may have misunderstood this, but staging is a mechanism to group the processing of BODs, but not the filtering of BODs. I do not think it is possible to "kill" some BODs before they are send based on their content? BTW in our case it is LN who is system of record, so we are talking about outgoing BODs we want to eliminate.

1 I just wanted to list it. Skipping a standard trigger is not possible as far as I'm aware.
2 This will work also in other processes, not just while processing an inbound BOD.
"Only after we filled the last data the BOD is no longer premature." are the multiple updates done in 1 process/bshell? Do you know when the last one did happen. If so then you could finish the staging process and release the staged BOD.
If the updates happens by different users then staging will not help.

Skipping standard trigger is possible in Infor LN 10.8 and Cloud. See KB 2267552.

Not exactly related but related to BOD Suppression.

Can I implement in my Dataflow not to publish ConfirmBOD for that flow? Reason is to avoid such 'known' instances showing up in Oneview.