SharePoint Forms365 vs Plumsail Forms: an honest comparison
A side by side comparison of two SharePoint forms products, including the places where Plumsail is still the better choice.
Plumsail Forms is the long-standing incumbent in the SharePoint forms space. We built SharePoint Forms365 partly because we ran out of patience waiting for features in Plumsail. So this comparison is not impartial, but it tries to be honest. Where Plumsail wins, we say so, and there are several places where it does.
The overlap is large, and that matters
Both products do the same fundamental thing: replace SharePoint's default list form with a designed, rule-driven one. Both ship a drag-drop designer with broadly similar canvas behaviour, conditional rules for visibility, enable state and required state, a JavaScript runtime API for author-defined behaviour, binding onto an existing SharePoint list, and publish/draft separation with rollback.
That overlap is worth stating plainly, because if your requirements sit squarely inside it, none of what follows decides anything. The choice comes down to licensing, support quality, and which designer your team prefers to sit in all day. Nobody should migrate a working forms estate over a feature they will not use.
Four places we are genuinely ahead
AI form generation. Drop in a Word document or describe the form in a sentence, and the AI emits a starter schema. Plumsail has nothing equivalent. If you are migrating dozens of legacy forms, this is the difference between a fortnight and an afternoon.
Parent and child editing. Our LinkedList component treats parent/child workflows, invoice line items, attendee lists, delivery lines, as a first-class concept. Plumsail's nearest equivalent is the List or Library control, which is more general but harder to wire correctly when the child rows must save atomically with the parent.
Schema reconciliation. When someone renames a column, retypes it, or edits a choice list, our schema reconciliation re-derives every schema-driven property on form load. Plumsail needs a manual republish for many of the same scenarios. This one rarely shows up in a side-by-side demo and shows up constantly in year two.
Pricing shape. We price per workspace. Plumsail prices per form, which quietly penalises exactly the tenant that has forty small forms rather than four big ones.
Three places Plumsail is still the better answer
Maturity. Plumsail has been in market since around 2016. Its edge cases are documented, and there is a decade of community Q&A to search when something behaves oddly at 5pm on a Friday. We are newer. On some scenarios you will be the first person to hit them, and that has a real cost.
Cross-site lookups. Plumsail's Cross-site Lookup column is a mature answer to SharePoint's inability to look up across site collections. We handle it through the f365 JavaScript API, which works, but it is code rather than a designer-native control. If that requirement is central to your forms, Plumsail solves it more cleanly today.
Looking exactly like SharePoint. Plumsail's designer aligns tightly with the Office visual language by default. We have our own visual identity. Most customers prefer ours, but "it must be visually indistinguishable from SharePoint" is a legitimate requirement, and if it is yours, Plumsail wins it.
Feature parity matrix
| Feature | Plumsail Forms | SharePoint Forms365 |
|---|---|---|
| Drag-drop designer | Yes | Yes |
| Visibility / enable / required rules | Yes | Yes |
| Custom JavaScript API | Yes | Yes |
| AI form generation | No | Yes |
| AI in-form components (chat, button) | No | Yes |
| Cross-site lookup column | Yes (mature) | Via f365 API |
| Linked-list parent/child | Via List/Library control | Yes (dedicated) |
| Signature capture | Yes | Yes |
| Theme tokens + per-form CSS | Yes | Yes |
| Multi-page / tabs / accordions | Yes | Yes |
| Schema reconciliation on load | Manual republish often needed | Yes |
| Per-workspace pricing | No (per-form) | Yes |
| Mature community + docs | Yes | Growing |
So which one
Starting fresh in 2026: we think we are the better fit, unless you are already a Plumsail house and the procurement fight is not worth winning. The AI authoring and the pricing shape are durable advantages rather than features Plumsail will ship next quarter.
Already running on Plumsail: do not migrate just because. The migration cost is real and it lands on the same team that has other work. Wait for your renewal cycle and re-evaluate then, by which point our maturity gap will have narrowed further.
Coming off InfoPath and considering both: the decision is different again, because you are rebuilding regardless. We wrote up the realistic replacement paths in InfoPath end of life in 2026, including where Nintex and Power Apps fit.
If you want to test a migration on one form before committing to anything, the 5-minute quickstart covers the import path.