Guide
Workspace basics
Define the workspace boundary and understand how Mountly organizes forms, entries, tokens, and billing.
Mountly is easiest to run when a workspace has a clear job. Before you create forms or hand out tokens, decide what this workspace represents in your organization. In most cases, it should map to a single website or a single environment so the team can answer simple questions quickly: which forms live here, who reviews entries, who manages integrations, and which plan pays for the traffic.
Start with a boundary your team can explain
Think of a workspace as the operating boundary around a set of forms. It is where Mountly stores the form configuration, accepted entries, access tokens, and billing for that slice of work. If production and staging need different rules, or if two websites have different owners, create that separation deliberately from the beginning. A workspace name should make that boundary obvious to someone who did not create it.
That small decision pays off later. When a teammate needs to rotate a token, review submissions, or understand plan usage, they should not have to guess whether they are looking at the right place.
Decide who owns each operational area
Mountly does not model teammates inside the product, but your team should still agree on who owns each part of the workflow before the first form goes live. Usually that means the person who reviews submissions, the developer or operator who handles tokens and integrations, whoever is responsible for redirects, notifications, or downstream routing, and whoever watches billing once traffic starts.
That agreement keeps the workspace grounded in reality. When real submissions start arriving, nobody should have to guess who is on point for review, integrations, or plan usage.
Learn the four objects you will use most
Once the workspace exists, most of the dashboard becomes easier to understand if you keep four core objects in mind:
| Object | What it controls |
|---|---|
| Forms | The submission behavior for a specific form, including redirects, notifications, and whether it is currently accepting entries. |
| Form entries | The accepted submissions stored for that form. |
| Access tokens | Programmatic access for integrations, internal tools, and backend workflows. |
| Subscription limits | The number of forms and submissions available on the current plan. |
If your team understands those four pieces, the rest of the product tends to feel much more straightforward. Forms define behavior, entries show what happened, tokens let systems participate, and subscription limits tell you how much room you have.
Decide how the first live form should behave before you build it
The first form tends to expose every unresolved assumption. Before you connect a frontend, agree on where the user should land after a successful submission, how the team wants to hear about new entries, and who owns the day-to-day review of incoming data.
These are not cosmetic settings. They determine the shape of the user experience after submit and the operational path your team will follow when real traffic arrives. If you can explain those choices clearly, you are ready to move on.
Next step
Continue with Forms and submissions to create the first form, configure its behavior, and verify that Mountly stores the resulting entries.