A Modify scenario fills or changes the value of a field while the form is being filled in. Instead of relying only on what the user types, PalDock can write a value into a field based on other fields, or fetch it from an external service.
Modify is a scenario attached to a field. It is not the same thing as the Modify node, which is one element inside a scenario. A Modify scenario often contains a Modify node, but it does not have to, and a Modify node can be used in any scenario, not only this one.
The field being filled is usually hidden, but it does not have to be.
This feature is especially useful when you want to:
- Keep forms shorter and simpler for users, while still capturing all required data.
- Add extra business context without manual input.
How Modify works
A field can be set to fill automatically when another field is completed and the form is submitted. For example, entering a company ID may trigger an API call that fills in the company name, address, and postal code into their respective fields without the user needing to fill them up manually.
This is done through Connection Creator, where you build the scenario and connect it to specific input and output fields.
Examples include:
- Looking up company details from a business registry.
- Retrieving mobile carrier.
- Completing address details based on ZIP code.
- And many others.
More than one scenario on a field
A field can have several Modify scenarios, and they run in the order you set. Use this when the value is built in steps, for example one scenario fetches the company record and a second one formats the address it returned.
The order matters. A scenario that reads a value another scenario has not written yet will find the field empty.
Changing a value you already have
Not every Modify needs an external service. When the value is already in the form and only needs reformatting, trimming, or combining with another field, use the Modify node’s operations instead of an HTTP request. That keeps the form fast, because nothing has to wait for a third party.
See List of modifications for what the operations can do.
What to watch out for
⚠️ Modify through an external service can break the entire system if it is set up incorrectly, preventing the form from being processed and the lead from being sent to offer.
- External service outage. If the service is unavailable, the form can be submitted, but cannot be processed until a valid response is received. To avoid this, configure a fallback response for the failure case, for example on status codes 4xx or 5xx, so the scenario finishes even when no value was filled.
- Timeouts. If an external service takes too long to respond, users are stuck waiting with a loading spinner until the request finishes. This creates a poor user experience and increases the risk of abandonment. Set the timeout on the HTTP node, and keep in mind that the whole scenario runs while the visitor waits, so it has to finish inside the synchronous limit. See Limits and timeouts.
- Combination with validation. If Modify from an external service fails, the field will not be populated. If validation is also enabled on that field, it will fail as well, preventing the form from being submitted. Both features must be configured correctly with this risk in mind.
