Answer
A few other patterns are worth considering depending on the specific case: if it's feasible for your scenario, trigger your logic off a different, related table instead of the one still mid-transaction (for example, a history or journal table that gets written to as part of the same operation, rather than the table your event's own trigger fired on); or wrap the offending code in a procedure marked with PRAGMA AUTONOMOUS_TRANSACTION, which runs it in its own independent transaction context, sidestepping the mutating-table restriction (with the usual autonomous-transaction caveats around it committing independently of the calling transaction). Looking at how IFS's own replication jobs are built is also worth exploring, since they face the same mutating-table constraint from their own triggers and have established patterns for working around it.