Fluent Forms MCP for forms, submissions and payment records

Closing a Fluent Forms registration form on time

Event and course sites ask the same thing every season: open registration on a date, stop it at a number of places or on a closing day, and show a sensible message afterwards. In Fluent Forms those rules sit under restrictions in the formSettings blob, with scheduling under restrictions.scheduleForm and login gating under restrictions.requireLogin. The agent reads them with fluentforms-get-form-settings, then patches only the restrictions key with fluentforms-edit-form-settings, which shallow-merges and reports any key it dropped.

Read the restrictions object in full before writing, because the merge works at the top level: sending a restrictions object replaces the stored one, so a new submission limit sent alone could clear the schedule that was already there. Then load the form as a visitor once the window has closed, or on staging with the dates moved, to see the message Fluent Forms shows. An unpublished form, by contrast, renders nothing at all, which is why switching status is the wrong way to close registrations.

Routing notifications by what the visitor chose

A contact form that should email sales for quotes and support for problems needs one notification per destination, each with its own conditionals. fluentforms-list-notifications shows every notification with its recipient summary and whether it has conditionals, and include conditionals returns the rules themselves. fluentforms-create-notification adds a new one with sendTo, subject, message and conditionals, and sendTo can be a plain address or a merge tag that takes the address from a field.

Each notification is its own row, so adding the support route cannot disturb the sales one, and notification ids never renumber when one is removed. Test every branch: submit once choosing quote and once choosing problem, and check both mailboxes. A condition that names a field by the wrong key silently never matches, so the symptom is an email that never arrives rather than an error.

Learning from abandoned save-and-resume drafts

On long forms with Fluent Forms Pro's save-and-resume enabled, abandoned drafts say where people give up. fluentforms-list-draft-submissions filters by form and by used, where false means the visitor never came back to submit, and each row includes the step reached, the source page and the device. Counting abandoned drafts by step_completed points at the page of a multi-step form that loses people. Drafts can hold personal answers, so keep that analysis to counts, and remember deleting a draft breaks the visitor's resume link for good.