You’re thinking about this exactly the right way — and your concerns are valid.
What you’re trying to build is a very common Dataverse pattern, and Microsoft already has a fairly established “best-practice” way to do it without custom code and without fighting the platform.
Below is the clean, supportable, mostly out-of-the-box architecture that scales well and avoids fragile stage GUID logic.
✅ Core principle (very important)
Business Process Flow ≠ security boundary
A BPF is only:
-
a UI guidance tool
-
a stage indicator
It does not control who can edit a row or move stages.
So the correct pattern is:
Security is enforced by Dataverse row ownership and access teams — not by the BPF itself.
The BPF simply reflects that state.
✅ Recommended architecture (Microsoft pattern)
✔ Dataverse security controls access
✔ BPF reflects lifecycle
✔ Power Automate performs orchestration
✔ No hard-coded stage IDs
✔ No plugins required
✅ Final recommended design
1️⃣ Use Owner-based security on Rental
Set the Rental table to:
Ownership = User or Team
This is required.
2️⃣ Use an Access Team per Rental
This is the key piece most people miss.
Create an Access Team Template for Rental:
Example roles:
Access teams allow you to:
3️⃣ Submission stage logic
When the user submits the rental:
Cloud Flow (or BPF action) does:
-
Identify the pet owner’s manager
-
Create (or reuse) the Rental Access Team
-
Add:
-
submitter → read-only
-
manager → contributor
-
Optionally remove broader access
At this point:
✅ User can still see the record
❌ User can no longer edit it
✅ Manager now has edit rights
No BPF trickery required.
4️⃣ Approval stage access control
Now only the manager can:
-
edit the record
-
advance the BPF stage
-
complete approval fields
Because only they have write access.
Even if someone clicks the stage:
Dataverse will block it automatically.
5️⃣ Trigger approval flow (best practice)
✅ Do NOT trigger from “When row modified”
You are absolutely correct — this causes:
-
performance issues
-
unreliable stage detection
-
unnecessary ProcessStage queries
-
environment-specific GUID problems
✅ Preferred trigger: BPF Action Step
Inside the Business Process Flow:
Add an Action Step:
Start Approval
This action:
This is the recommended approach.
Why Action Step is better
| Reason |
Benefit |
| Explicit trigger |
No false positives |
| Runs once |
No re-trigger issues |
| No GUIDs |
Fully solution-aware |
| No ProcessStage query |
Better performance |
| Clear audit trail |
Easy support |
| Designed for BPF |
Microsoft-intended use |
6️⃣ Approval flow logic
The approval flow:
-
Receives Rental ID
-
Reads manager from lookup
-
Sends approval (Approvals connector)
-
On approve:
-
On reject:
7️⃣ Scheduled execution requirement
Because everything is server-side:
You can also trigger the same approval logic from:
-
Scheduled flow
-
Manual admin flow
-
Button
-
API call
No dependency on UI.
✅ What you should NOT do
❌ Hard-code BPF stage GUIDs
❌ Query ProcessStage on every update
❌ Use BPF as a security mechanism
❌ Change record ownership repeatedly
❌ Trigger approvals on generic modified events
Your instincts here are 100% correct.
✅ Final recommended stack
Dataverse Security
├─ Owner-based table
├─ Access Teams (per Rental)
↓
Business Process Flow
├─ Guides user
├─ Shows current stage
├─ Triggers actions
↓
Cloud Flow
├─ Approval
├─ Access updates
├─ Status transitions
✅ Summary answers to your questions
✔ How to restrict BPF progression?
By restricting row write access, not by the BPF itself.
✔ How to restrict access after submission?
Use Access Teams, not ownership changes.
✔ How to trigger approval?
✅ BPF Action Step (best practice)
✔ Is querying ProcessStage bad?
Yes — avoid it.
✔ Are stage GUIDs unsafe?
Yes — they change across environments.
✔ Is your concern valid?
Completely. You’re thinking at enterprise-architecture level.
🧠 This is the same pattern Microsoft uses internally for:
Share
Report
2
All responses (
Answers (
