Forms and submissions

Use this guide when the workspace is already in place and the next job is getting a real form flow live. The goal is not just to create a record in Mountly, but to make sure the user-facing form, the dashboard configuration, and the team's review process all describe the same workflow.

Create a form your team will recognize later

When you create the form in Mountly, fill it out as if someone else will need to understand it a month from now. A clear name, a useful description, the correct redirect destination, and the intended notification behavior make the dashboard far easier to work with once there are multiple forms in play.

It helps to think of the form record as shared operational context, not just a technical configuration screen. If a teammate opens it later, they should immediately understand what this form is for and what should happen after a successful submission.

Treat redirects and notifications as part of the contract

Redirects and notifications are easy to treat as polish, but they are really part of the form's behavior. Redirects determine what the user experiences after a successful submission. Notifications determine how quickly your team notices new entries and whether those alerts stay helpful or turn into noise.

If the frontend promises one destination and Mountly sends users somewhere else, people will notice. The same is true for notifications: too little visibility creates blind spots, while too much noise trains the team to ignore the signal. Configure both with the real operating workflow in mind.

Test the whole flow with one realistic submission

Before you call the form done, send one believable test submission through the real frontend flow. Then confirm that the user lands on the expected redirect, the entry appears in Mountly, and the right person or channel receives the notification behavior you configured.

This end-to-end check is the fastest way to catch a mismatch between the frontend and the dashboard. It also gives the team a concrete example of what "working" looks like before traffic increases.

Review entries in the dashboard until the pattern is clear

After launch, the entries view becomes the daily source of truth. It tells you whether submissions are arriving, whether the payload looks complete, and whether the current process is still manageable by hand. Early on, that manual review step is valuable because it shows you the actual shape of the data before you automate anything around it.

Once the workflow feels stable, the dashboard will also tell you when it is time to move beyond manual review. If the same follow-up work happens over and over again, that is usually your signal to introduce an integration.

Move to the API when the workflow is repeatable

The dashboard is the right place to configure and verify a form. The API becomes useful when you need repeatable exports, downstream integrations, or automated follow-up work driven by accepted entries.

That handoff tends to go smoothly when you already have one form behaving the way you expect. In practice, the cleanest first milestone is simple: one configured form, one accepted test submission, and one team member who knows where to review new entries.

Next step

Continue with Automation playbooks if you are ready to move beyond manual review, or open the API reference if you need the exact public contract now.