that sounds like a bit of a bold undertaking and I would discourage the approach you lay out.
Here is my reasoning:
Are you aware of the potential performance drops when using the sales cloud AMPscript functions? Be sure to test "updateSingleSalesforceObject" at scale if you want to use this in larger sendouts to ensure this doesn't slow your sendout.
I doubt that the IER data is created in real time but have not tested.
Even if the creation of the IER record were realtime, the retrieve performance is pretty slow. Example from my own dabbles: in a non-sending context, in order to create a Personaccount, and retrieve a field value from it directly after creation requires around a second of waiting. Totally inadequate for bulk sendouts.
so - avoid this pattern. Don't try to build performant, scalable, real-time sendout processes involving your Sales Cloud via AMPscript.
I have not tried the following (and there are unsolved questions), but the alternative that I could see would probably be largely custom and it would involve the following patterns:
Logging the relevant information for your sendout into a send logging DE (e.g. campaign ID alongside the features that define a sendout event (jobid, subscriberkey, listId, batchid).
In an asynchronous process, try to retrieve the IER id by your logged data in the sendlog.
Here is the problem: When checking the schema generator in Sales Cloud for the IER object, unfortunately, none of these things that define a sendout event uniquely are present on IER. (Except subscriberkey). So you would have a hard time matching your sendout event to an IER record.
You would have to make "proxy" lookups to things like Email ID, subject line etc. which are represented on IER to find the right IER record for your recipient / sendout, but this is highly error prone.
assuming you find that this matching can be done somehow - then asynchronously push data into the sales cloud object, in small numbers via Journey Builder, in large numbers via the Bulk API, see here:
Account Activity or Object Activity in Journey Builder has limits to update like Data Loader?
You would have to test such an operation in conjunction with the existing API calls that populate IER by default (which is managed by MC Connect), be aware there could be conflicts by trying to update something while the connector is busy with it. This is a bit of a blackbox, so I would also steer clear.
With all that effort in mind, I would first consider a cost-benefit analysis of the underlying requirement. If it stands that test -
Second, fallback to maybe a custom object that basically mirrors your Send Log. This can clear the roadblocks in terms of "finding the right IER record" and avoids conflicts with the standard MC connect API. Consider that data storage could be a problem here, which btw is true also for IER.
I understand a custom object might not have all the bells and whistles of standard IER, but again, cost / benefit.
Third, fallback to a BI tool where you can tie your data together in a meaningful way.