I am implementing a single, deterministic Power Automate workflow triggered by “When an item is created or modified” in a Power Apps–driven SharePoint solution, where Power Apps is the authoritative source for all state transitions and data mutations, and Power Automate operates strictly as an event processor for notifications and audit persistence. The flow enforces concurrency control (degree = 1), isolates logic using scopes, and avoids Get item entirely, relying instead on “Get changes for an item or file (properties only)” with trigger window semantics to detect state transitions and field-level deltas. A critical requirement is conditional audit logging: audit records must be generated only when an item has previously been returned for amendment and is subsequently modified and resubmitted, and only for a defined subset of business fields; initial creation, standard forward routing, reviewer actions, and status changes must be excluded. The audit gate is implemented by evaluating the previous state value and confirming a forward transition from a returned condition, followed by explicit column-level change detection using HasColumnChanged flags to generate one audit record per modified field. During implementation, the platform repeatedly auto-injects Apply to each when binding ID or trigger window values into the Get changes action, despite the flow being strictly single-item driven, and earlier iterations exhibited duplicate notifications and ID resolution issues when Get item was used. These have been partially mitigated by using trigger output expressions directly and emitting notifications only on state transitions, but I am seeking confirmation that this architecture represents the correct, platform-aligned approach for building a production-grade, single-flow, state-driven workflow with deterministic execution and conditional auditing, and whether there are any recommended refinements to avoid implicit array handling and loop injection in this pattern.
