Custom Forms
Custom forms for MSPs and the organizations they support: build the extra questions a ticket, change, asset, site or project needs, attach them by rule, and keep every answer against the version of the form that asked it.
The problem
Every service desk has questions the standard fields cannot hold. A new-starter request needs a start date, a manager and the licences to assign. A firewall change needs the maintenance window and the rollback plan. A laptop intake needs the serial off the box. Today those answers arrive in the description field, or in a reply three days later, or on a spreadsheet nobody attached. The technician asks again, the requester answers again, and the record still cannot be reported on because none of it is a field.
What Solidlio does about it
An administrator builds a form from 20 question types, publishes it, and attaches it to records by rule: tickets filed under a category, changes of a given risk, assets of a type, sites, projects and project tasks. The form appears where the rule says, to the audience the rule names, and can be required before the record is created. Each published version is frozen. Answers are stored against the version that asked them, so editing a form never rewrites history, and a question deleted last month still shows its answer under the label it was asked with. Display rules show or hide questions as the responder answers. A hidden question never blocks submission and never stores a stale answer.
Capabilities
| Capability | What it does |
|---|---|
| Form builder | Builds a form from 20 question types and 3 layout blocks, grouped into sections, with a live preview that uses the same renderer people will fill in. |
| Validation rules | Sets required, length, range, date bounds, selection counts, and file count, size and type limits per question. |
| Display rules | Shows a section or question only when earlier answers match, with all-of or any-of matching across eight comparisons. |
| Versioned publishing | Freezes each published version. Edits go into a single draft that goes live only when you publish again. |
| Publish checks | Refuses to publish a form with a duplicate field key, a choice with no options, a broken pattern, or a rule pointing at a question that does not exist. |
| Placement rules | Attaches a form to tickets, change requests, assets, sites, projects or project tasks, narrowed by your own categories, queues, templates, types, priorities, risk levels and statuses. |
| Category prefix matching | A rule on a parent ticket category keeps matching after deeper categories are added beneath it, and never claims a sibling whose name merely starts the same way. |
| Audience | Shows a form to the person raising the record, to staff working it, or to both. Staff-only forms and their answers never reach the customer portal. |
| Required at creation | Holds a ticket, request, change, asset or project until a required form is answered. Optional forms are saved only when someone actually filled them in. |
| On the record | Shows answered forms read-only on the record, with Fill in, Edit and Remove, rendered against the version that collected them. |
| File answers | Collects screenshots, photos and signed paperwork up to 25 MB per file, stored privately and streamed only to signed-in members of the organization. |
| Record pickers | Asks for a person, an asset or a site from the organization’s own lists and stores the reference. |
| Responses and export | Lists every response per form with its record, submitter and time, and exports a CSV whose columns are the live version’s questions. |
| Publish to clients | Shares a form into the client organizations an MSP manages. The client sees it in its own library, marked with the provider’s name, can copy it, and can never change the questions. |
| Attached-here labels | Ticket categories, queues, change templates and project templates each show which forms they collect, linking back to the rule. |
| Safe delete | Deletes a form nothing was ever submitted against. Archives one that has responses, so the answers stay on the records they belong to. |
Built for MSPs and their clients
The MSP portal and the organization portal use the same form library and the same editor. The difference is reach. An MSP working a client’s record sees the client’s forms and answers them on the client’s behalf, and the answers belong to the client. An MSP that publishes a form to its clients keeps the questions under its own control.
| Organization | MSP | |
|---|---|---|
| Authors forms | For its own records | For its own records |
| Attaches forms | To its tickets, changes, assets, sites, projects and tasks | To its own records, by the same rules |
| Publishes to others | — | To any client organization it manages, one tick per client |
| Receives a shared form | Sees it in its library marked with the provider’s name; can copy it into its own; cannot edit it | — |
| Works a client’s record | — | Sees the client’s forms on the client’s tickets, changes, sites, projects and tasks, and answers them |
| Reads responses | Its own | Its own, plus every managed client’s responses to the forms it published |
| Sees the other’s drafts | Never | Never |
How it works
- Create it — Settings → Forms → New form. Name it. It opens as an empty draft nobody else can see.
- Build it — Add questions from the palette, group them into sections, mark what is required, set validation, and add display rules so a question appears only when it matters. Preview shows exactly what responders will see.
- Publish it — Problems are listed until they are fixed. Publishing freezes version 1 and makes the form available to placement rules.
- Place it — On the Placement tab choose a record type, narrow it by your own categories, queues, templates, types or statuses, choose who sees it and when, and tick Must be filled in if creation should wait for it.
- Collect answers — The form appears on the create page and holds submission until required questions are answered. On an existing record it appears under Additional information, with Fill in, Edit and Remove.
- Review — The Responses tab lists every response with its record, submitter and time. Export CSV downloads them all, with the live version’s questions as columns.
- Change it safely — Editing opens a new draft while the live version keeps serving. Publish again to release it. Old answers keep the questions they were asked with. Discard changes returns the draft to the live version.
Editions
Custom forms carry no plan gate. Every capability above is available on every tier, including Free. File answers count toward the account’s storage allowance, which is the one place plan size matters.
| Capability | Free | Starter | Growth | Scale | Enterprise |
|---|---|---|---|---|---|
| Form builder, validation and display rules | ● | ● | ● | ● | ● |
| Versioned publishing and publish checks | ● | ● | ● | ● | ● |
| Placement rules on six record types | ● | ● | ● | ● | ● |
| Audience control and required-at-creation | ● | ● | ● | ● | ● |
| File answers and record pickers | ● | ● | ● | ● | ● |
| Responses table and CSV export | ● | ● | ● | ● | ● |
| Publishing to managed clients | ● | ● | ● | ● | ● |
| Storage allowance for file answers | 1 GB | 25 GB | 100 GB | 500 GB | Unlimited |
MSP tiers shown. End-customer tiers carry the same capabilities with storage allowances of 1 GB, 10 GB, 50 GB, 250 GB and unlimited. A file upload that would exceed the allowance is refused before anything is written, and the form says so.
Integrations
- Solidlio Ticketing — forms on new tickets and on the ticket record, matched by category, type, priority and queue
- Customer portal — the new-request page asks the requester’s forms and holds the request until required ones are answered
- Solidlio Change Management — forms on the new-change wizard and the change record, matched by type, category, risk level and template
- Solidlio Assets — forms on asset intake and the asset record, matched by asset type and status
- Solidlio Sites & Locations — forms on a site’s record, matched by location type
- Solidlio Projects — forms on new projects, the project hub and task editing, matched by template and status
- Settings screens — ticket categories, queues, change templates and project templates show the forms attached to them
Compliance and audit
- Published versions never change. Every edit goes into a draft. Publishing creates a new version and leaves every earlier one intact.
- Every answer is pinned to the version that asked it, and renders under that version’s questions in the record view, the responses table and the export.
- Who and when, on both sides. Each version records who published it and when. Each response records who submitted it, when, and who last changed it.
- Hidden questions leave no trace. An answer to a question the responder could not see is dropped rather than stored, so reports count only what was asked.
- Archiving over deletion. A form with responses cannot be deleted, only archived. The answers stay on the records they belong to.
- Customer-portal separation. Staff-only forms and their answers are excluded from every customer-portal read, including on a record the customer can open.
- Tenant boundary. A form, rule or response in another tenant reads as not found. Naming another tenant’s organization is refused rather than honoured.
- Private files. File answers are never served from a public address. They are streamed to signed-in members of the owning organization only.