FormWork evaluates form rules on the server. An embedded form and a custom application using the API can share the same calculations, visibility conditions, and validation rules. Your interface collects input; the form engine decides what the current answers mean.
Example: a quote that depends on several answers
Imagine an accountancy quote that asks about business structure, turnover, and selected services. A useful implementation separates three concerns:
- Inputs: collect the business facts and service selections in typed fields.
- Rules: calculate a quote from those answers; show additional questions only when relevant; validate required details before submission.
- Result: display the calculated quote and use the submitted result in the next workflow step.
Changing a displayed total in a browser is not a substitute for changing the inputs that the server accepts. Keep the pricing rules in the form configuration and validate the entry on the server.
Our accountancy services quote demonstrates this pattern with a fictional practice. It is an example, not a customer result or an accounting recommendation.
Rules are expressions, not arbitrary backend code
Use operators and calculations to derive values, conditional logic to control visibility, and validation rules to constrain answers. These rules are part of the form schema. External business systems can be reached through API Connectors.
Server-side processing requires a connection to the hosted service. It does not provide offline evaluation, nor does it remove the need to author and test your rules. For a custom interface, handle validation responses and loading states deliberately.
Keep rules and old entries understandable
Publish rule changes as a form version. Existing entries remain associated with their version, so a new calculation does not silently redefine the form behind an older entry.
Start with the quick start, inspect the REST API, or compare the full product capabilities.