Why FormBeacon Never Stores Your Form Responses

What FormBeacon stores—and what it deliberately does not

A no-storage claim is meaningful only when the complete data path is explained precisely. You will be able to trace a submission from Google Forms through FormBeacon to a messaging provider, identify the data stored at each boundary, and evaluate whether chat delivery is appropriate for your form.

FormBeacon operates a delivery API; it is not a direct Apps Script-to-provider shortcut. The add-on calls that service so it can validate identity, licensing, form and destination limits, idempotency, and delivery. The service does not persist form answers or rendered notification bodies.

PostgreSQL stores configuration and redacted delivery metadata. Channel credentials and templates are encrypted with versioned AES-256-GCM keys. Google document properties used for retries are restricted to form ID, response ID, idempotency key, and attempt count, and the response is re-read from Google.

Follow the data through FormBeacon

In FormBeacon's no-answer-storage design, Google invokes a user-owned installable form-submit trigger after configuration. The add-on reads the submitted response, renders the selected message, and sends it to FormBeacon's delivery API. The service applies plan limits and idempotency, uses the encrypted destination configuration to call the selected provider, and stores redacted delivery metadata rather than submitted answer content or rendered notification bodies.

That architecture is the diagnostic map for FormBeacon's no-answer-storage design. FormBeacon is not a direct browser-to-webhook shortcut, and it does operate a delivery service. At the same time, response answers do not become a searchable FormBeacon database. Google Forms remains the record you inspect or correct; the provider receives the message you explicitly send; FormBeacon retains only the bounded configuration and redacted operational data required to deliver and diagnose it.

1. 1A respondent submits the Google Form and Google records the response.
2. 2The verified form owner’s installable trigger runs for that submission.
3. 3The add-on prepares a request containing the form and response references needed for delivery.
4. 4FormBeacon validates identity, form entitlement, quota, destination configuration, and idempotency.
5. 5The service calls the provider using the credential and destination required by the selected provider.
6. 6On success, the service records redacted success metadata and counts one successful outbound destination delivery as one notification.
7. 7On failure, the failed attempt does not consume the Free successful-delivery quota; an idempotent retry must not count the same delivery twice.

Before publishing FormBeacon's no-answer-storage design, check provider behavior against the provider's current official documentation, because provider interfaces, permissions, limits, and policy wording can change. Check FormBeacon's product behavior and prices on the pricing page and in the current add-on rather than inferring them from an old screenshot.

Map every place submitted data can appear

The practical goal is You will be able to trace a submission from Google Forms through FormBeacon to a messaging provider, identify the data stored at each boundary, and evaluate whether chat delivery is appropriate for your form. A notification becomes useful only when a named person knows what to do after it arrives. Before changing the form, record the form owner, the destination owner, who may see the submitted information, and the action expected from the first reader.

For FormBeacon's no-answer-storage design, keep Google Forms as the response system of record. FormBeacon delivers a notification; it is not a CRM, ticket database, applicant-tracking system, booking engine, or conditional workflow builder. If the process needs assignment state, approvals, capacity enforcement, scheduled reminders, or answer-based branching, keep those controls in a suitable system and use the message as the prompt to act.

When rehearsing FormBeacon's no-answer-storage design, use a copied form and a private test destination. Enter obviously fictional answers. That keeps setup separate from real personal, customer, health, hiring, or payment-related information and makes it safe to repeat tests while permissions are being corrected.

Decide what the notification truly needs to contain

Control access at Google and the destination provider

For FormBeacon's no-answer-storage design, treat every webhook, bot token, and access token as a password. Restrict destination membership and rotate a credential after suspected disclosure.

Every delivery created by FormBeacon's no-answer-storage design is a new copy of the notification. Google Form sharing does not automatically restrict a Slack channel, Discord channel, Telegram group, WhatsApp recipient, or webhook receiver. Before choosing Insert all fields, review every form question and assume every destination member can read the rendered values. For sensitive workflows, send a minimal reference and instruct authorized staff to open Google Forms rather than copying all answers into a notification.

• Use the narrowest private destination that still supports the workflow.
• Remove webhook URLs, bot tokens, access tokens, and real phone numbers from screenshots and screen recordings.
• Do not submit real customer or employee data while testing.
• Review provider retention, export, moderation, and member-access settings separately from FormBeacon.
• Rotate an exposed credential at the provider, update FormBeacon, and run both tests again.
• Delete test messages that contain even fictional data if they could confuse the operational channel later.

The privacy boundary for FormBeacon's no-answer-storage design is specific: FormBeacon encrypts channel credentials and templates with versioned AES-256-GCM keys. It does not persist form answers, rendered notification bodies, raw provider payloads, OAuth or identity tokens, or complete billing webhook payloads. Retry storage in Google document properties is limited to form ID, response ID, idempotency key, and attempt count; the response is re-read from Google for a retry.

Those controls do not automatically make every form suitable for FormBeacon's no-answer-storage design. You remain responsible for lawful collection, notices, consent where required, access control, retention at Google and the provider, and any industry-specific rules. This article explains product behavior and operational precautions; it is not legal advice.

Identify the original response record

Google Forms receives the submission and remains the system of record. FormBeacon does not replace Google's response retention, sharing, deletion, export, or workspace administration. Review those controls first because removing a chat message does not delete Google's response.

Follow the user-owned trigger

The intended form owner authorizes a Google installable submit trigger. The trigger runs under that owner and prepares the delivery request. It is incorrect to describe this as a simple trigger that lives only in a linked Sheet or as a script that never contacts FormBeacon infrastructure.

Understand server validation

FormBeacon's Go service verifies the Google identity and relevant plan and workspace contracts, enforces form and destination capacity, applies successful-delivery quota rules, and makes idempotent delivery decisions before calling the provider adapter.

Separate content from metadata

The content needed for a delivery exists in memory for processing but is not written as a FormBeacon answer archive, rendered-body log, or raw provider-payload store. Redacted operational records can include stable references, provider type, outcome or error code, timestamps, attempts, and other bounded metadata that does not reproduce the answers.

Account for the destination copy

Slack, Discord, Telegram, or WhatsApp receives and retains the delivered message under that provider's controls. Destination members may read, export, quote, forward, screenshot, or retain it according to provider features and organizational policy. 'FormBeacon does not store answers' does not mean the destination stores nothing.

Review retry behavior

A retry does not keep a copy of the rendered answer body in Google properties. It retains only the bounded form and response references, idempotency key, and attempt count, re-reads the source response, and ensures an idempotent retry does not count twice.

The limits of a no-storage design

• No system can promise that a delivered provider message was not read, exported, or screenshotted.
• FormBeacon's no-answer-storage design does not remove the customer's legal and security responsibilities.
• Deleting a Google response does not automatically recall provider messages.
• This product explanation is not a legal opinion, DPA, or certification.

If FormBeacon's no-answer-storage design requires a behavior listed here as a limit, do not hide the gap with copy or assume a future feature exists. Change the workflow, separate the forms, or choose a system that owns the missing behavior. Clear boundaries make setup and incident response easier.

Verify privacy controls with fictional data

To accept FormBeacon's no-answer-storage design, run both a saved configuration test and a real form submission because they answer different questions. The saved test checks whether the current credential, destination, and message can reach the provider. A real submission additionally checks the Google trigger, form binding, response rendering, and delivery path. Both results must succeed.

1. 1Create a private test destination or tell the intended channel that a harmless test is coming.
2. 2Use a copied form with short fictional values, including one blank optional answer and one value containing punctuation.
3. 3Save the simplest supported mode first. Do not begin with a complex provider-specific Advanced structure.
4. 4Run the destination test and confirm a harmless notification at the intended destination.
5. 5Open the public responder view of the copied Google Form and submit it like a respondent would.
6. 6Confirm that exactly one new message appears, that the form title and submission time are plausible, and that the message is visible only to the intended audience.
7. 7Repeat once with a multiline answer and non-ASCII text. This catches formatting assumptions that a one-word test will miss.
8. 8Return to the add-on and review the visible delivery status without pasting credentials into a support conversation.

When checking FormBeacon's no-answer-storage design, a working saved test and a failed real submission point to trigger ownership, Google authorization, the selected form, or event eligibility. If neither works, inspect the destination credential and provider permissions first. If delivery succeeds but the content is hard to read, keep the credential unchanged and simplify the template. Changing one layer at a time preserves evidence.

If FormBeacon's no-answer-storage design still fails, use the provider-by-provider Google Forms notifications diagnostic guide. Record the test time, form name, destination name, and redacted error code. Never record submitted answers or the secret itself in a shared incident note.

Investigate delivery without collecting response content

Minimize the message before improving its presentation

For FormBeacon's no-answer-storage design, start with Basic mode. The variable picker includes form and response metadata plus every current form field keyed by stable Google item ID. Insert all fields creates provider-neutral rows; answer-based conditions and respondent-controlled routing remain unsupported.

The first message for FormBeacon's no-answer-storage design should identify the form, state when the response was submitted, include only the information the first reader needs, and supply a stable response reference when useful. Put the action before decorative context. On a phone, the first few lines should explain why the alert matters without requiring the reader to expand a card or decode internal abbreviations.

Advanced mode in FormBeacon's no-answer-storage design is provider-specific and schema validated. Variable substitution is context-aware and JSON safe, and respondent values remain text: they cannot become keys, object structure, credentials, destinations, template identity, or routing. Basic mode remains the most resilient choice when a workflow does not need provider-specific structure.

Understand how delivery metadata and quotas differ

Before launching FormBeacon's no-answer-storage design, match it to the pricing contract. Free supports one form, one active Basic destination on Slack, Discord, or Telegram, and 100 successful outbound destination deliveries per UTC calendar month. Standard supports up to 10 forms and Basic, Rich, and supported Advanced modes on Slack, Discord, and Telegram. Business adds WhatsApp approved templates, Webhook JSON, a shared 100-form workspace capacity, shared connectors, and unlimited explicitly invited workspace members.

For quota accounting in FormBeacon's no-answer-storage design, one notification is one successful delivery to one outbound destination. If one response is sent to three active destinations and all three succeed, that is three successful deliveries. A failed delivery does not consume the Free quota, and an idempotent retry of the same delivery must not count twice. The Free counter resets lazily when the UTC month key changes; there is no reset cron to wait for.

Multiple destinations attached to FormBeacon's no-answer-storage design use fan-out, not conditional routing. Every active destination on the form receives every eligible response. FormBeacon does not inspect an answer and select a destination, severity color, owner, or template branch. To keep different audiences separate, use separate forms or a workflow system that explicitly implements rules, and test that system with representative data.

Verify current FormBeacon amounts and included features for FormBeacon's no-answer-storage design on the pricing page. Product prices and provider charges are different: Meta or another provider may apply its own usage charges, taxes, or policies, and those charges are not replaced by a FormBeacon subscription.

Review access, retention, and ownership regularly

Treat FormBeacon's no-answer-storage design like a small operational system. Name a form owner and a destination owner, document the purpose without recording secrets, and schedule a periodic harmless submission. Retest after changing form ownership, Google authorization, questions, destination membership, channel structure, webhook or bot settings, Meta templates, or the FormBeacon plan.

• Keep a copy of the intended message structure without any credential or real response data.
• Review whether every destination member still needs access to the notification content.
• Remove unused destinations before creating new ones so fan-out remains understandable.
• Use provider audit or administration features to investigate credential changes where available.
• When an owner leaves, deliberately transfer the Google Form and recreate or verify the user-owned trigger under the intended owner.
• During an incident, preserve timestamps and stable error codes, but redact identities, credentials, answers, and complete payloads.

The fallback for FormBeacon's no-answer-storage design should remain visible: authorized staff can open Google Forms and inspect responses when chat delivery is delayed. Do not delete or mutate a form response simply because a notification failed. Repair the delivery path, make a harmless test, and use the response reference to reconcile operational action without copying the original answers into troubleshooting logs.