Change a rule. Know in seconds what else moved.
A form with thirty rules is hard to change with confidence. The honest way to check the other twenty-nine is to open the form and click through it — which is slow enough that in practice nobody does, so regressions get found by the people using the form. Modern DFFS lets you write down what a form is supposed to do and re-run those checks whenever you want.
Key capabilities
- Set values, then check what happened — whether a rule fired, whether a field became required, visible or read-only, whether a tab appeared, whether the form passes validation, or whether a rule would have sent its email.
- Record instead of writing — fill the form in the way a user would, and Modern DFFS proposes the checks for you. Values a rule worked out are ticked; ones you typed yourself are not, because checking your own input proves nothing.
- Read a failure without guessing — every failure shows the rule condition that broke, with what it expected beside what it actually found.
- Nothing real is touched — no email is sent, nothing is written to another list, no Flow or webhook fires, your custom JavaScript is never run, and the item is never saved.
- Runs before a save, if you want it to — failures warn rather than block, because mid-change you will legitimately have failing tests.
- Travels with the configuration — tests are stored with the form, so they survive export, import, and promotion from DEV to UAT to PRD.
A failure tells you which condition broke
Not just that a rule did not fire — expanding a failure shows a condition table like the one Rule Debug gives you, so you can see the rule expected Rejected and actually found Pending.
Test the email without sending one
Rule actions that reach outside the form are recorded rather than run, and listed afterwards with the configuration they would have used. You can prove a rejection would notify the requester without anyone receiving anything.
Worked example
An approval form has a rule that makes Approver required once Status is Approved, and another that emails the requester on rejection. You write two tests — Approving requires an approver and Rejecting notifies the requester — and tick Run these tests before saving. Six months later someone edits the status choices. The next save warns that one test no longer passes, and names the condition: the rule wanted Rejected and found Pending. The regression is caught in the configuration screen rather than by whoever submits the next request.