Formstack customization services cover the work beyond configuration: theming and custom CSS, bespoke validation, tailored respondent experiences, and Salesforce-side extensions in Apex, Lightning Web Components and Visualforce. Twopir Consulting builds those extensions so the managed packages can still be upgraded — because a customization that blocks the next release is not a feature, it is a liability with a delivery date attached.
Formstack customization is anything that changes behaviour or appearance beyond what the product's own settings express. In practice that spans three levels: presentation work such as theming and custom CSS; behavioural work such as bespoke validation, tailored respondent experiences and custom scripting; and Salesforce-side development in Apex, Lightning Web Components or Visualforce that extends what the managed packages do inside your org.
Every one of those carries an ongoing cost, because it is something the vendor will not maintain for you. That does not make customization wrong — it makes it a decision that should be justified, isolated from the parts the vendor upgrades, documented, and reviewed periodically to check it is still needed.
The first question we ask is whether configuration can do it. A surprising proportion of customization requests turn out to be capabilities the platform already has, asked for in different words. That is not a criticism of the person asking — feature surfaces are wide and change regularly. It is simply the cheapest possible outcome, and it is worth ten minutes of checking before anyone writes code.
The three levels differ in who can change them, what happens at upgrade time, and what it costs when the person who built it leaves. Knowing which level a request sits at is most of the decision.
| Dimension | Configuration | Customization | Custom development |
|---|---|---|---|
| What it is | Settings the product exposes: fields, logic, routing, themes, delivery options. | Custom CSS, tailored experiences, bespoke validation, scripted behaviour. | Apex, Lightning Web Components, Visualforce, external services that extend the platform. |
| Who can change it | A trained administrator. | Someone comfortable with front-end code or the specific customization. | A developer, with a deployment path and tests. |
| Upgrade behaviour | Carried forward by the vendor. | May break when the underlying markup or behaviour changes. | Yours to regression-test against each package release. |
| Ongoing cost | Effectively none beyond normal administration. | Low but real — someone must own it and re-test it. | Highest: tests, deployments, documentation, upgrade regression. |
| When it is the right answer | Nearly always, when it can express the requirement. | Brand consistency and respondent experience beyond the theme editor's reach. | Logic that must run inside a platform transaction, or behaviour nothing else can provide. |
| Warning sign | Configuration so convoluted it needs its own documentation. | CSS that targets deeply nested generated selectors. | Code that reimplements something the platform already does. |
Forms and documents that look like they belong to your organisation rather than to a form builder.
Presentation work that survives a platform update rather than breaking silently on a Tuesday.
Rules that cannot be expressed in standard field validation, enforced at the point of entry.
Platform code that extends the managed packages without preventing them being upgraded.
Forms that arrive knowing who the respondent is, without exposing more than they should.
The register that stops customizations accumulating faster than anyone can remember why.
Formstack ships package updates — including compatibility with each Salesforce seasonal release. An org that cannot take those updates has a problem that compounds every quarter.
Hundreds of lines of overrides, no comments, targeting selectors that no longer exist in half the cases. Removing any of it is a gamble, so it accumulates instead — and every platform update becomes a nervous week.
The org cannot take a package update because something custom depends on current behaviour. Compatibility fixes and new capability both stall, and the gap between installed and current widens every release.
Custom logic doing something the platform has done natively for two years. It was justified when written; nobody has reviewed it since, and it is now pure maintenance cost with no benefit.
Focus outlines removed because they looked untidy, error states signalled by colour alone, contrast reduced for aesthetics. The form looks better in a screenshot and fails for keyboard and screen-reader users.
The rule runs in the browser and nowhere else. Anyone who bypasses the form — a direct submission, a script, a disabled JavaScript session — writes invalid data straight past it. Validation that matters has to exist server-side too.
No documentation, no tests, no stated justification. The customization cannot be safely changed or safely removed, so it stays — and it constrains every decision made around it from now on.
It should not, and the way to keep it that way is to extend alongside the package rather than depend on its internals. Custom Apex and components live in your own namespace and call supported surfaces; custom CSS targets the most stable selectors available. Then each customization gets a specific entry in an upgrade regression checklist and is tested in a sandbox before production. This matters because Formstack ships package updates including Salesforce seasonal-release compatibility — an org that cannot take those updates falls further behind every quarter, and the cost of catching up grows faster than the cost of staying current.
Substantially. Formstack provides theming with design and CSS tools, and with custom CSS on top of that you can generally match a brand closely enough that a respondent cannot tell the form was not built as part of your site. The two constraints worth stating up front are accessibility — focus states, contrast and error signalling are not negotiable and we will push back if a design removes them — and maintenance, because styling that fights the platform rather than extending it is what breaks on the next update. A theme applied consistently across the estate is worth considerably more than a bespoke treatment on one form.
Yes — cross-field rules, format and check-digit validation, and lookups against an external source before submission are all achievable. The design principle we insist on is that validation which actually matters must also exist server-side or in the destination system. Client-side validation improves the experience by catching mistakes early; it does not enforce anything, because any path that bypasses the form bypasses it too. If a rule protects data integrity or a compliance obligation, it needs a second enforcement point behind the form.
Inventory before you touch anything. We catalogue every customization, work out what it does, and — the important part — assess whether the platform now provides it natively. In inherited estates a meaningful share of custom code turns out to be reimplementing something the product has since shipped, and retiring those is pure reduction in maintenance cost. What remains gets a written justification, a named owner and an entry in the upgrade regression checklist. That is usually a short, well-defined engagement, and it is the right first step before any new customization is added on top.
Three cases. When configuration can express the requirement, even slightly less elegantly — the elegance is rarely worth the ongoing cost. When the customization exists to preserve a process that should itself be changed, which is customization paying to keep a bad process alive. And when nobody in your organisation will own it: an unowned customization is a future incident with a date on it, and the honest answer there is either to find an owner or not to build it.
Tell us the behaviour you want rather than the customization you have in mind. A useful share of these turn out to be configuration, and where they genuinely are not, we will build the extension so it does not block your next package upgrade.
Built by a Salesforce Gold Partner. Every customization we deliver arrives with a justification, an owner and a documented removal path.
