A records office writes a perfect Events rule for com.oraclecloud.objectstorage.createobject, yet uploads never trigger the Function. What Object Storage requirement is most likely missing?

When the records office has a correct Events rule for com.oraclecloud.objectstorage.createobject yet uploads never invoke the Function, the most likely missing requirement is enabling emit events for object state changes on the bucket. Unlike many OCI resources that emit lifecycle CloudEvents automatically, Object Storage object-level create, update, and delete events are gated by that bucket setting (at create time or later). Until emit is on, no matching CloudEvent is produced for the rule to catch. Converting the bucket to Archive storage so Events emits on every PUT is unrelated: storage tier does not substitute for the emit-events flag, and Archive is about access/cost, not event generation. Publishing each object name to Streaming because Object Storage never participates in Events is false—Object Storage is a first-class Events emitter once object events are enabled. Attaching a dynamic group to the bucket user so Events can forge CloudEvents envelopes misunderstands IAM: dynamic groups authorize Functions or connectors to call APIs; they do not create the emission itself. Exam caveat: enabling emit on the bucket after the rule exists is sufficient going forward, but objects written while emit was off will not retroactively generate historical create events. Operational check: on the bucket properties, confirm “emit events for object state changes” is enabled, upload a small test object, and verify the rule’s Streaming or Function action receives a create-object CloudEvent with the expected bucket attributes.