Quick answer
Do not assume a field is private because it is hidden on the initial form or labelled "internal." Review the workflow display settings and every outgoing template separately. Use a unique fictional marker in an internal field, then confirm that it never appears in customer emails, public confirmations, or unauthorized entry views.
Identify what counts as an internal note
Start with a short data inventory. A reviewer's assessment stored in a form field is different from a workflow note or a WordPress administrative note. Record where each piece of information is entered, who is supposed to read it, and which business action needs it. Do not treat every paragraph of entry data as equally suitable for a customer message.
Keep this inventory minimal. It can list field IDs and purposes without copying real assessments. Separate useful operational details from sensitive material that should never have been collected in the form. Reducing unnecessary collection is a better long-term control than relying on a large collection of exclusion rules.
Review display and editing independently
Gravity Flow's User Input settings distinguish editable fields from display fields. Its display-all option can include hidden or administrative fields. That is why hiding a field from the original visitor form does not establish the audience for later workflow screens.
Check the view as the actual reviewer role and as another role that should not have access. An administrator preview is not an access-control test. Include tokenized or email-based entry links if the workflow uses them, and do not publish those links in a ticket or screenshot. Treat them as potentially sensitive access paths.
Audit the customer message templates
Inventory the immediate confirmation, submission acknowledgement, acceptance email, decline email, and any later follow-up. Inspect recipient selection, subject, body, attachments, and merge tags. A carefully written body can still leak information through a copied field in the subject or an automatically generated attachment.
Prefer an explicit set of customer-approved fields. Review broad "all fields" output and custom merge-tag behavior rather than assuming one exclusion applies everywhere. A plugin, integration, or later template edit can use a different set of fields. Keep the intended content policy close to the template so the next editor understands the boundary.
Use a canary entry, not a real client record
On staging, submit a fictional inquiry and put a marker such as INTERNAL-REVIEW-TEST-SEP13 in the reviewer assessment. Use different markers for different note types. Route all email to a controlled inbox and all integrations to a sandbox or disabled destination.
Run both acceptance and decline paths. Search the received subject, body, headers where relevant, and attachments for the marker. Also inspect the public confirmation and the workflow entry as the customer or unauthorized role. Keep screenshots redacted and record only the result and field identifiers needed to reproduce it.
- Initial submission acknowledgement contains no internal review marker.
- Acceptance and decline messages contain only approved customer-facing fields.
- An unrelated reviewer cannot open or search the entry.
- Generated PDFs, exports, webhooks, and CRM notes follow their own audience policy.
Do not stop at the website
List every destination that receives the entry: CRM, shared mailbox, help desk, spreadsheet, storage folder, or webhook processor. A correct website template does not prevent an integration from sending the entire entry elsewhere. Inspect the field mapping and destination access with the owner of that system.
Test forwarding and reply behavior for internal notifications. A reviewer may reasonably reply to a message without noticing that a customer address is in Reply-To or CC. Make recipient purpose obvious and avoid placing confidential review content into messages that are routinely forwarded externally.
Repair and retest the exact boundary
When a marker appears where it should not, identify the smallest responsible template, field mapping, or access setting. Save the previous configuration, correct that surface, and repeat the same fictional entry test. Then verify that the intended internal reviewer still has enough information to perform the task.
Do not delete live evidence while investigating an actual disclosure. Preserve appropriate restricted records and follow the organization's incident process. For routine prevention, keep the canary test in the release checklist and repeat it after template, workflow, or integration changes. The pass condition is correct audience separation, not merely a hidden input on the first page.
Illustrative diagnostic example, not customer measurements.When to bring in help
If real confidential notes were exposed, involve the person responsible for privacy and incident handling. HandL WP can trace the technical output paths, but a template fix alone does not determine whether notifications or other response duties apply.
Related troubleshooting
Check notification recipients and empty-role behavior.
Helpful references
User Input step settings. Notification step and event behavior.