Make Automation Landing Page Edits

This was the second of four workflows (create, edit, close/revive and featured) built to allow non-technical users to manage website content directly from their regular Monday work environment by simply filling out an embedded Jotform. This Make automation was the most complex of them all, providing the ability to edit all aspects of an existing landing page.

• Make
• Monday and Monday CRM
• Jotform
• WordPress
• Cloudinary
• Kinsta
• Advanced Custom Fields
• CPT UI
• FIFU
• Postmark
• Code Snippets/PHP

The requestor fills out a detailed form that is segmented into content edits and four types of question edits. The question edits here were treated differently due to API and Jotform limitations.

ELIGIBILITY GATES

Once the form triggers the scenario, there are two gates before it fully fires. It queries the post based on post ID number (the main unique identifier used throughout) to determine if the post is closed or the post is an incompatible type. If either of those prove true, the requestor is notified of such.

CONTENT EDITS

Once the request passes the eligibility gates, it can enter the first router which checks to see what changes were requested. If requests were entered on the form for content, it flows through the spokes. This portion of the edit scenario allows the requestor to edit one or as many of these parts as desired...content, title, image, location, etc. with one exception: the slug cannot be changed. Given how rarely slug changes come up, building full redirect support wasn't worth the build effort.

QUESTION EDITS LIMITATIONS

This is where some of the limitations arose. Due to how Jotform's API worked as well as question/field IDs worked, there was limited functionality.

• Limitation 1: There was not a way to effectively display existing questions on a Jotform within the edit form. For reordering questions, this requires the end user to manually see/know "this is question 1, etc."
• Limitation 2: Jotform fluidly adds new fields and "forcing" order is very specific. This aspect is the reason for the "10 question cap" to keep question field IDs within a predictable 5.0–5.9 range the automation can reliably target. This ensures the editing occurs between the evergreen fields such as email and reCAPTCHA.
• Limitation 3: This same fluidity means multiple question changes can't be requested at once — submitting several together risks timing out the API call, and there's no reliable way to predict which change Jotform applies first.
• Limitation 4: If a question is deleted, ALL historical data is also deleted. This is a core Jotform platform limitation. This makes hiding, rather than deleting, the only way to preserve historical data for auditing.

Limitation Conclusion: Given how rarely these edge cases occur, asking a requestor to resubmit a form — a few extra minutes — is a better trade-off than building fixes for problems that might not even be solvable within Jotform's own constraints.

QUESTION EDITS

Given the above, the edit Jotform contains its own conditional logic to surface only one type of question edit at a time. As a safeguard, the scenario also runs a second router inside Make, re-checking the submitted data against that same one-option-only rule before processing — a double-check in case anything slips past Jotform's own front-end restriction.

Edit Question(s): Change the content or wording of an existing question.

Delete (Hide) Question(s): Remove a question from the form.

Add Question(s): Add up to five new questions, checked automatically against the 10-question limit.

Reorder Question(s): Move the order of the questions.

As with the create form, this solution lets the requestor update a landing page without a middle-man. Jotform's limitations keep the UX from being fully optimized, but resubmitting a form in a few extra minutes is still a huge improvement over waiting on an IT employee to manually execute the change. Edit volume swings widely — some weeks are a handful of small tweaks, others bring a batch of 50 pages needing the same shared content fixed everywhere. Either way, the requestor handles it directly, with no IT turnaround and no queue to wait behind.