Custom Question security and prohibited data

Custom Questions are powerful but come with rules. Don't capture highly sensitive PII (SSN, full driver license numbers, payment cards) — SALT blocks Custom Questions that look like they collect prohibited data. Anything you do collect exports with the record and flows to integrations, so only collect what you have a business reason to.

Updated Aug 26, 2026 • For agency admin

In short: Don’t put SSN, full driver license numbers, or payment card data in a Custom Question — SALT blocks questions that look like they collect prohibited data. Use the Insured/standard fields for regulated PII. Anything you do collect exports with the record and flows to integrations, so only collect what you need.

What’s prohibited

Don’t capture this data in Custom Questions. SALT actively blocks questions whose name, description, or input labels look like they collect it:

  • Social Security Numbers (SSN) — SALT doesn’t capture SSN as a standard field for a reason. Capturing through a Custom Question creates regulatory exposure for your agency without the encryption and consent flows SALT applies to standard PII.
  • Full driver license numbers — there’s a standard Insured field for this with appropriate encryption. Use it instead.
  • Payment card data (PAN, CVV) — never. Payment data goes through the proper PCI-compliant channels (Stripe), not free-form fields.
  • Full bank account or routing numbers — same reasoning.
  • Health information (HIPAA-covered) — generally outside SALT’s scope and creates regulatory complications.

These restrictions protect both your agency and the consumer.

What happens if you try

When you create or edit a Custom Question, SALT scans the question’s name, description, and input labels for patterns that look like prohibited data. If it finds one, the question can’t be published until you remove it — and a previously-published question that trips the check is unpublished. This is a guardrail on what you collect; it runs when you define the question, before any consumer sees it.

How the data you collect is handled

Once a Custom Question is published and answered, its answers are part of the Submission:

  • They export with the Submission’s CSV or PDF alongside standard fields. Exporting requires the one-time export-consent step — a blanket acknowledgment on the export action, not a per-question setting.
  • They flow to integrations (Webhooks, Zapier) in the event payload, delivered directly to the endpoint you connect. There is no per-field consent gate on integration delivery.

There is no way to mark an individual question as “sensitive” to hold its answers back from an export or an integration. Treat Custom Questions as visible-and-exportable by design: collect only what you have a clear business reason to, and rely on the prohibited-data block above to keep the worst categories out.

What about consumer privacy?

Custom Questions are subject to the same privacy principles as standard questions:

  • Data is encrypted at rest where applicable.
  • Data is only visible to authorized users.
  • TCPA and other consent requirements apply when applicable.
  • The consumer can request data deletion subject to standard policies.

Don’t ask for data you don’t have a clear business reason to collect. “Nice to have” data adds liability without meaningful upside.

Common questions

I need to capture something prohibited for a specific use case. What do I do? Don’t work around the block with a differently-worded Custom Question. Contact SALT support to discuss whether the standard library can be extended, or whether your use case needs a different approach.

Will my Custom Question answers show up in exports and integrations? Yes. Answers export with the Submission and flow to integrations directly. There’s no setting to mark an individual question as sensitive and hold it back — so only collect what you need.

Can I see who exported data and when? Yes — exports are logged (who, when, IP), and an admin or compliance officer can review. See Exporting Submissions.