Govforms is a digital service builder for teams creating guided online journeys. It brings service design, content, data collection, workflow, integrations and deployment into one place so teams can focus on the experience and operational outcome rather than rebuilding common patterns.

You work in the Builder to create a service, use User view to experience it as a participant would, and deploy a tested version to the appropriate environment.

What you can build

Govforms can support simple forms as well as more structured services, including:

• applications, registrations and requests;
• internal casework and data-management journeys;
• eligibility checks and calculations;
• surveys and structured data collection;
• task-list services with save-and-return behaviour; and
• services connected to APIs, data feeds, file storage and SharePoint.

Start with the smallest complete journey that solves the user need. Add branching, data lookups, notifications and automation only when they make the service clearer or deliver a genuine operational requirement.

The Builder model

flowchart TD
  A[Library] --> B[Service]
  B --> C[Pages]
  C --> D[Components]
  B --> E[Conditions]
  C --> F[Actions]
  B --> G[Environments]

A library groups related services and shared access, branding and integrations. A service is the journey you build and deploy. Pages contain content and components; conditions control decisions; actions perform work such as a lookup, message or document generation.

A practical way to start

1. Define who the service is for, what they need to achieve and what happens when they finish.
2. Choose or create the appropriate library.
3. Build the simplest sensible path through the journey.
4. Add clear questions, helpful validation and a completion route.
5. Use conditions for genuinely relevant branching and actions for required work.
6. Test in User view, then test real integrations in QA.
7. Deploy only the version that has been reviewed and approved for its intended environment.

The best early design question is not “Which setting do I need?” but “What must a person understand, provide or receive at this point?” The settings should support that answer.

Use this learning hub

Begin with Basic concepts and Build your first service. Use the how-to guides when you have a particular outcome in mind, then consult the settings reference when you need detailed configuration behaviour.

Keep the documentation map open while you work. It groups each article by the Builder area it supports.

Before a live release

Ensure the journey is understandable, content is accurate, errors explain how to recover, the completion page sets expectations and any connected systems have been tested safely in QA. A service is ready to move forward when both the participant experience and the operational process have been checked.