Buttons and Dynamic Form Rules Issues

You're saying that you're ending up with a conflict in form rules.  You haven't directly explained what the conflict is, but in general in these form rule conflict situations you want to rewrite the rules to put in a a single rule which handle whether the form element (Field,  section or page) should show or hide. 

Personally, I hate having multiple forms. In my experience, it creates all kind of problems. For example, when the user goes to view a record, which form is it going to use. These records are no doubt going to be used for viewing as well as during the data entry process. Also, it's unfair to the user experience to assume that they will proceed exactly linearly step-by-step through the form and never stop partway and have to come back to it later. If they come back to it later, how does the system know what form to use.

I would strongly suggest pushing form rules to their limits before giving up and going to multiple form route.  

The cleanest and most maintainable way to build your multi-stage process (Draft → In Development → Under Review → Approved/Rejected) is to move away from relying heavily on many Dynamic Form Rules and helper checkboxes. Instead, use a combination of multiple Form Views, Action Buttons, and minimal, well-organized Dynamic Form Rules. This approach reduces conflicts significantly and creates a much smoother user experience. Start by creating three dedicated Form Views in your table: Intake Form, Proposal Form, and Review Form. Each form view should be designed for a specific stage. For example, the Intake Form should only show the Intake section by default, the Proposal Form should focus on the Proposal section, and the Review Form can show all sections but with previous ones set to read-only. Next, use native Action Buttons as the main drivers of progression. On the Intake Form, add a “Start Proposal” button that is only visible when Status = “Draft”. When clicked, the button changes the Status to “In Development”, saves the record, and automatically re-opens the record using the Proposal Form. Similarly, on the Proposal Form, create a “Submit Proposal for Review” button that changes the Status to “Under Review” and opens the Review Form. This method is far more reliable than helper checkboxes because the buttons directly control both the status change and the form navigation in one action.

Finally, use Dynamic Form Rules sparingly and scoped to each individual form view. In the Intake Form, create a simple rule that shows only the Intake section when Status is Draft. In the Proposal Form, have a rule that shows only the Proposal section when Status is In Development. In the Review Form, use rules to make earlier sections read-only once the status moves forward. By keeping your rules simple, non-overlapping, and tied to specific form views, you avoid most conflicts that occur when everything lives on a single form.This redesigned approach makes your app easier to maintain as you add more stages in the future and provides clearer guidance to users at each step of the demand lifecycle. If you implement it this way, you should see far fewer rule conflicts and a more professional workflow.

Rochelle, I continue to believe that you can solve you conflicts using this method here:

https://community.quickbase.com/discussions/quickbase-discussions/dynamic-form-rules-and-or/81433