1. Introduction
1.1 Purpose
This document defines the functional requirements, user roles, and user stories for the Forms Module of the DSP platform. It is intended to serve as a reference for product, development, and quality assurance teams to understand what the module must do, who it must do it for, and the acceptance criteria that define successful delivery.
1.2 Scope
The scope of this document covers all four form types offered by the Forms Module Order Forms, Intake Forms, Onboarding Forms, and Contact Forms including field types, account/payment handling, sharing and embedding, pre-filling, and the cross-cutting Form Field Rules engine. It covers the module’s behaviour across all three access levels defined in Section 3: Super Admin, Workspace Admin, and Client Portal. Adjacent modules Services, Order Management, and Workspace Management are referenced only where necessary for context and are out of scope for detailed requirements in this document.
1.3 Document Conventions
- Each functional requirement is identified with a unique ID: FR-OF-## (Order Forms), FR-IF-## (Intake Forms), FR-ONB-## (Onboarding Forms), FR-CF-## (Contact Forms), FR-FLD-## (Form Field Rules), or FR-GEN-## (general/cross-cutting).
- Each user story is identified with a unique ID in the format US-<Role Code>-##, where Role Code is SA (Super Admin), WA (Workspace Admin), or CP (Client Portal).
- Priority levels follow the MoSCoW method: Must Have, Should Have, Could Have, Won’t Have (this release).
The Forms Module provides four distinct form types, each designed for a specific stage of the client journey. Knowing which one to use, and when, is central to a smooth client experience.
| Form Type |
Purpose |
Frequency |
Creates / Triggers |
| Order Form |
Clients select services and pay for them on the same page. |
Per purchase |
A new order (and client account, if new) |
| Intake Form |
Collects project-specific details inside the order, after payment. |
Per order |
Order status change: Pending → Submitted |
| Onboarding Form |
Collects static information (brand assets, company background) once per client, reused across all future orders. |
Once per client |
Reusable client profile data |
| Contact Form |
Sits outside the order flow entirely support requests, quote inquiries, general feedback. |
Any time, no purchase required |
A support ticket |
3. User Roles & Access Levels
The Forms Module is used by three distinct classes of users, each with a different purpose and level of access, as summarized below.
| Role |
Description |
Access Level |
| Super Admin |
The agency owner / top-level account holder with unrestricted access to the entire workspace, including all Forms Module configuration (Order, Intake, Onboarding, and Contact forms). |
Full create, read, update, delete, publish, share |
| Workspace Admin |
Internal team member operating under a configured role (e.g. Admin, Manager, Contractor, or a custom role) with permissions granted by the Super Admin. |
Permission-based ranges from full form management to read-only or no access |
| Client (Client Portal) |
An external customer or prospect who fills out order, intake, onboarding, or contact forms either as a purchaser, an existing client, or an anonymous visitor. |
Fill & self-service only no form-building or configuration access |
4. Functional Requirements
The following requirements are grouped by form type, then by cross-cutting behaviour that applies across all four types.
| Req ID |
Requirement Description |
Priority |
| FR-OF-01 |
The system shall allow a Super Admin / authorized Workspace Admin to create a new order form via Forms → Order Forms → + Order Form. |
Must Have |
| FR-OF-02 |
The system shall provide a drag-and-drop (or click-to-append) form builder where fields can be added to the form, with changes visible in real time. |
Must Have |
| FR-OF-03 |
The system shall support an Option Group service field where exactly one of the attached services/options must be selected. |
Must Have |
| FR-OF-04 |
The system shall support a Checkbox Group service field allowing one or multiple attached services (e.g. add-ons) to be selected. |
Must Have |
| FR-OF-05 |
The system shall support a Multi-Dropdown service field allowing the same service to be added multiple times, each with a distinct pricing-variant selection. |
Must Have |
| FR-OF-06 |
The system shall require at least one service field on an order form before it can be saved/published. |
Must Have |
| Req ID |
Requirement Description |
Priority |
| FR-OF-07 |
The system shall include an Email account field on every order form by default, and shall not allow it to be removed. |
Must Have |
| FR-OF-08 |
The system shall treat all account fields other than Email (e.g. Name, Password) as optional. |
Must Have |
| FR-OF-09 |
The system shall send the client a magic login link by email when no Password field is present on the order form used at signup. |
Must Have |
| FR-OF-10 |
The system shall support an Email Opt-In field that records marketing consent and syncs to a connected ActiveCampaign or MailChimp integration. |
Should Have |
| FR-OF-11 |
The system shall require the Billing Address field only when tax options are enabled for the workspace. |
Should Have |
| Req ID |
Requirement Description |
Priority |
| FR-OF-12 |
The system shall allow a Payment Options field to be added so clients can pay directly on the order form. |
Must Have |
| FR-OF-13 |
The system shall redirect clients to a separate payment page when no Payment Options field is present on the order form. |
Must Have |
| FR-OF-14 |
The system shall support general-purpose Data Fields for collecting supplementary information (e.g. ‘How did you hear about us?’) not tied to a specific service. |
Should Have |
| FR-OF-15 |
The system shall allow specific order form fields (e.g. a service selection) to be pre-filled via a custom-generated link, configured from the form’s Share options. |
Should Have |
| FR-OF-16 |
The system shall allow a published order form to be shared via a public link and via an embeddable iframe code. |
Must Have |
| Req ID |
Requirement Description |
Priority |
| FR-IF-01 |
The system shall allow an authorized user to create an intake form via Forms → Intake Forms → + Intake Form using the form builder. |
Must Have |
| FR-IF-02 |
The system shall allow an intake form to be attached to one or more services. |
Must Have |
| FR-IF-03 |
The system shall keep an order in ‘Pending’ status when its service requires project data, until the client submits the attached intake form. |
Must Have |
| FR-IF-04 |
The system shall automatically change an order’s status to ‘Submitted’ as soon as the required intake data is provided. |
Must Have |
| FR-IF-05 |
The system shall send the client an automated email reminder if the intake form has not been completed within 24 hours of purchase. |
Should Have |
| FR-IF-06 |
The system shall display submitted intake data within the order details for the team to review. |
Must Have |
| FR-IF-07 |
The system shall restrict access to an intake form to clients who have purchased the associated service. |
Must Have |
| Req ID |
Requirement Description |
Priority |
| FR-ONB-01 |
The system shall allow an authorized user to create an onboarding form via Forms → Onboarding Forms using the form builder. |
Must Have |
| FR-ONB-02 |
The system shall collect onboarding form data once per client and automatically reuse it across all of that client’s current and future orders. |
Must Have |
| FR-ONB-03 |
The system shall allow an onboarding form to be assigned to a service, automatically checking whether the client has already completed it and prompting them if not. |
Must Have |
| FR-ONB-04 |
The system shall allow an onboarding form to be shared directly via link with a signed-in client, or assigned manually from the client profile (Actions → Add an onboarding form). |
Should Have |
| FR-ONB-05 |
The system shall allow a client to view their previously submitted onboarding data from their dashboard and update it if information changes. |
Must Have |
| FR-ONB-06 |
The system shall allow an authorized admin to edit a client’s submitted onboarding data directly from the client profile including editing fields, adding new fields, exporting data, or deleting the submission without requiring the client to resubmit. |
Should Have |
| FR-ONB-07 |
The system shall apply admin edits to onboarding data immediately, without any client-side confirmation step. |
Should Have |
| Req ID |
Requirement Description |
Priority |
| FR-CF-01 |
The system shall allow an authorized user to create a contact form via Forms → Contact Forms, independent of the order/service flow. |
Must Have |
| FR-CF-02 |
The system shall automatically create a support ticket for every contact form submission. |
Must Have |
| FR-CF-03 |
The system shall allow a contact form to be shared via a Public Link, accessible to anonymous visitors. |
Must Have |
| FR-CF-04 |
The system shall support a ‘Public link (log into portal)’ sharing mode that automatically logs the submitter into the client portal after submission. |
Should Have |
| FR-CF-05 |
The system shall generate an Embed Code (iframe) for a contact form that automatically applies the platform’s standard styling with no additional configuration. |
Must Have |
| FR-CF-06 |
The system shall generate a Support Widget code that displays the contact form as a popup widget in the corner of an external website. |
Should Have |
| Req ID |
Requirement Description |
Priority |
| FR-FLD-01 |
The system shall allow a rule to be defined that shows a specific form field when a condition on another field’s value is met. |
Must Have |
| FR-FLD-02 |
The system shall automatically hide a rule-controlled field whenever its associated show condition is not met, without requiring a separate hide rule. |
Must Have |
| FR-FLD-03 |
The system shall support form field rules uniformly across all four form types: Order, Intake, Onboarding, and Contact forms. |
Must Have |
| FR-GEN-01 |
The system shall block submission of any of the four form types when a required field is left empty, and shall display a clear inline validation message. |
Must Have |
| FR-GEN-02 |
The system shall confirm payment server-side before an order is created from an order form; no order shall be created from an incomplete or unconfirmed payment. |
Must Have |
5. User Stories & Acceptance Criteria
User stories are grouped by role to clarify who benefits from each capability and what conditions must be met for the story to be considered complete.
5.1 Workspace Admin User Stories
| ID |
User Story |
Acceptance Criteria |
| US-WA-01 |
As a Workspace Admin (Admin role), I want full access to all four form types, so that I can build and maintain the agency’s entire forms setup. |
- Admin-role users can create, edit, publish, share, and delete Order, Intake, Onboarding, and Contact forms.
- Access matches Super Admin capability unless explicitly restricted.
|
| US-WA-02 |
As a Workspace Admin (Manager role), I want scoped access to the Forms module based on my granted permissions, so that I can support form maintenance without full administrative control. |
- Manager can access only the form types/actions explicitly permitted.
- Restricted actions are blocked server-side, not just hidden in the UI.
|
| US-WA-03 |
As a Workspace Admin (Contractor role), I want no access to Forms configuration by default, so that form-building responsibility stays with authorized staff. |
- Contractor cannot view or reach any Forms builder screens, including by direct URL.
|
| US-WA-04 |
As a Workspace Admin, I want to edit a client’s submitted onboarding data directly from their profile, so that I can correct outdated or inaccurate information without waiting on the client. |
- Fields can be edited, added, exported, or the submission deleted, directly from the client profile.
- Changes apply immediately without requiring client resubmission.
|
| US-WA-05 |
As a Workspace Admin, I want to see a client’s submitted intake data directly inside the order, so that my team can begin fulfillment work as soon as it’s available. |
- Intake responses are visible in the order details view.
- No separate export/lookup step is required to see the client’s answers.
|
5.2 Client Portal User Stories
| ID |
User Story |
Acceptance Criteria |
| US-CP-01 |
As a client, I want to select the service(s) I need and pay in the same step, so that checkout feels quick and effortless. |
- I can complete service selection and payment on a single order form.
- The total price reflects exactly what I selected before I pay.
|
| US-CP-02 |
As a client, I want to sign up without creating a password, so that I can get started faster and never worry about forgetting a password. |
- I receive a magic login link by email immediately after signup.
- Clicking the link logs me in successfully with no password required.
|
| US-CP-03 |
As a client, I want to be reminded if I forget to complete my intake form, so that my project doesn’t stall unnecessarily. |
- I receive an email reminder if I haven’t submitted the intake form within 24 hours of purchase.
|
| US-CP-04 |
As a client, I want to provide project details after I’ve already paid, so that checkout itself stays quick and I’m not overwhelmed with questions before I’ve committed. |
- I’m only asked project-specific questions inside my order, after payment is complete.
- My order clearly shows as pending my input until I submit the intake form.
|
| US-CP-05 |
As a client, I want to fill out my brand/company information once, so that I never have to re-enter the same details for every new order. |
- Onboarding data I submit once is automatically shown/reused on all future qualifying orders.
- I am not asked to resubmit information I’ve already provided.
|
| US-CP-06 |
As a client, I want to update my onboarding information from my dashboard if something changes, so that the agency always has my current details. |
- I can view my previously submitted onboarding data from my dashboard.
- I can edit and resave it, and the update is reflected on future orders.
|
| US-CP-07 |
As a prospective client, I want to submit a contact/quote request without needing to create an account first, so that reaching out to the agency is effortless. |
- I can submit the contact form via a public link with no login required.
- My submission is received, and I’m not blocked by any account requirement.
|
| US-CP-08 |
As a client, I want a form to show me only the questions relevant to my previous answers, so that I’m not confused or slowed down by irrelevant fields. |
- Fields governed by a rule appear only when their condition is met and disappear cleanly when it isn’t.
|
| US-CP-09 |
As a client arriving from a specific pricing page, I want my intended plan already selected on the order form, so that I don’t have to search for and reselect it myself. |
- Opening a pre-filled link shows my intended service/option already selected on the order form.
|
6. Business Rules & Assumptions
- An order form must always contain at least one service field; it cannot be published as a pure lead-capture form (that is the purpose of a Contact Form).
- Intake forms are strictly per-order; data expected to remain constant across a client’s orders (e.g. brand assets) belongs on an Onboarding Form, not an Intake Form.
- Onboarding form data is per-client, not per-order; once submitted, it is reused automatically and does not need to be re-collected unless the client updates it.
- A single Form Field Rule per field is sufficient a ‘show when’ rule inherently implies ‘hide when the condition is false’, so no separate hide rule is needed.
- Only Contact Forms create support tickets; Order, Intake, and Onboarding form submissions feed orders and client records, not the ticketing system.
- An order remains in ‘Pending’ status and fulfillment does not begin until any attached Intake Form has been completed.
- Access to an Intake Form is always gated to clients who have purchased the associated service; it is never publicly accessible.
7. Non-Functional Requirements
- Usability: All four form builders shall be usable by non-technical agency staff without developer assistance, with real-time preview of changes.
- Performance: Form field rule evaluation (show/hide) shall apply instantly as the client interacts with the form, with no perceptible lag or page reload.
- Security: Intake forms shall enforce purchase-based access control; contact form public links shall not expose any authenticated client or order data.
- Reliability: The 24-hour intake reminder email shall trigger consistently based on order timestamp, without manual intervention.
- Consistency: Embedded forms (order form iframe, contact form embed/support widget) shall visually match the platform’s standard styling by default, requiring no additional CSS from the agency.
- Availability: The Forms Module shall be available whenever the client portal is available, as all four form types are core to both new client acquisition and existing client fulfillment.
8. Assumptions & Constraints
- This document assumes the Forms Module operates within the existing DSP platform architecture and integrates with the Services, Order Management, and Helpdesk (ticketing) modules described separately.
- Payment processing itself (Stripe/PayPal integration) is assumed to be handled by the platform’s payment layer and is out of scope here.
- Marketing integration behaviour (ActiveCampaign/MailChimp sync from the Email Opt-In field) is governed by the connected integration’s own configuration and is referenced but not detailed in this document.
- Multi-language and multi-currency rendering of form content is governed by workspace-level settings and is referenced but not detailed in this document.
Appendix A: Glossary
| Term |
Definition |
| Order Form |
A client-facing form where services are selected and paid for in the same step. |
| Intake Form |
A per-order form collecting project-specific details from the client after payment, before fulfillment begins. |
| Onboarding Form |
A per-client form collecting static information (brand assets, company background) once, reused across all future orders. |
| Contact Form |
A form outside the order flow used for support requests, quote inquiries, or general feedback; each submission creates a ticket. |
| Form Field Rule |
A conditional rule that shows or automatically hides a form field based on the value of another field, applicable across all four form types. |
| Magic Link |
A one-time login link emailed to a client in place of a password, used when an order form’s account fields omit a password field. |
| Prefill Link |
A specially generated order form link that pre-selects or pre-populates specific field values for the client opening it. |
| Service Field |
A field on an order form (Option Group, Checkbox Group, or Multi-Dropdown) used to add one or more services to checkout. |
| Support Widget |
An embeddable popup widget, generated from a contact form, that opens in the corner of an external website. |
| Ticket |
A support/inquiry record automatically created whenever a contact form is submitted. |
