Protect answers that only your team should change
Prefill a Request answer, keep it visible to clients, and protect it from client edits.
Use the padlock in Prefill to save an answer and keep it read-only for clients. For example, enter an agreed budget, then lock it before sending the Request.
Clients can still read the answer. Use Encrypt Answer to mask a sensitive Short Text answer, or a private Request to limit who can open the form.
Protect and prefill an answer
Team members with access to the client account can prefill and lock answers. Reopen a completed Request before editing it.
- Open the Request's Preview and choose Prefill.
- Enter the real answer you want clients to read.
- Select the padlock beside the question. Its label is Read-only for clients.
- Wait for the save and lock to finish.
- Check the client view with Test before publishing.
The padlock saves a valid answer before locking it. If it's unavailable, add a valid answer and let any pending save finish. Prefill saves real answers; Test uses sample answers that aren't saved to the Request.
A locked answer is read-only in team Prefill too. Select the padlock again to unlock it before making a change. Unlocking also lets clients edit that answer. Lock it again after saving if it should stay read-only.
All answer fields support locking, including File Upload and Signature. Section is a heading, so it has no answer to lock. The builder has no protection switch; lock saved answers in Prefill.
Fill required protected answers before sending
Locking an answer turns Required off for that question. Unlocking doesn't turn Required back on. If the client needs to answer it, unlock it and review its Required setting in the builder.
An older Request may still have a question that's both required and locked. If publishing asks for that answer, review its Required setting in the builder. To supply it in Prefill, unlock it first, enter and save the answer, then lock it again if needed. You can do this in Prefill even when a rule hides the question from clients. This is a recovery step for older Requests.
What your client sees
Clients can read locked answers but can't change them. Existing sensitive-answer masking still applies. An older blank locked answer may show Not provided.
Locked questions don't count as work the client needs to do. Their saved values can still show or hide later questions. If no client questions remain, the client can choose Complete Request. A progress bar at 100% alone doesn't change the Request to Completed.
If you lock a question while a client is typing, their old page can't save over your answer. Ask them to keep any unsent text and refresh the Request. Your team can review that text, unlock the answer, and save a change in Prefill if needed.
Reuse the setting
Templates and copies of Requests keep the questions and supported form settings, but leave out answers and answer locks. In each new Request, prefill and lock its own answers before sending it to a client.
Review protection changes
Open the team Request's Timeline to see lock and unlock changes alongside answers and other Request events. Each lock change shows who made it and when.
Older protection activity can expire after 180 days. The saved lock can remain after those entries expire. Locking or unlocking doesn't send a client alert or complete or reopen the Request.
Fix a common problem
The padlock is unavailable: add a valid answer and wait for pending edits to save. A completed Request needs to be reopened first.
A team member can't change an answer: open Prefill and unlock it first. Check the saved answer before locking it again.
Publishing asks for a protected answer: follow the older-Request recovery steps above.
You see “Saved. Refresh the request to see the latest details.”: the lock saved, but the page couldn't reload it. Keep unsent text before refreshing.