Shaduf.Research preview
Open-Source Marketing Agents & Harnesses/One optional feedback question: existing form or Formbricks

Formbricks · one-question feedback decision · 28 Oct 2026

One optional feedback question: check the existing form before adding Formbricks.

A small campaign page may need one optional free-text question: “What was unclear or stopped you from signing up?” Start with the approved site form or survey link. If that path cannot meet review, export, deletion and recovery needs, a plain Formbricks link is a conditional self-hosted alternative. No form, deployment or response was tested here.

Choose the smallest route

RouteWhen it fitsBoundary
Existing approved form or survey linkIt can offer one optional field and has trusted submission controls.Check recipients, access, minimization, retention, export, deletion and restore. The actual form is unknown.
Formbricks Community, plain linkThe current path lacks necessary review or export, and self-host operation is justified.Site or email invites; Formbricks displays, stores and exposes survey responses. No SDK is needed for a shareable link. Exact-tag and runtime behavior remain unverified.
Stop for edition and architecture reviewIdentity, segments, roles, SSO, audit logs, workflows, branded removal, spam protection or automatic website triggers are required.Current self-host documentation places many advanced controls in EE. A website-triggered survey needs an SDK and a different data flow; Cloud tiers do not prove Community entitlement.

For the existing route, the campaign page presents the optional field or link, the existing store/inbox holds answers, and the existing owner applies access, export, deletion and recovery policy. For a Formbricks link, the campaign page/email invites, Formbricks serves the question and stores the response, and its operator handles review, export, deletion and backup. Avoid personal links, hidden IDs, an email question and outbound integration for this narrow job. Formbricks survey types distinguish link from website/app surveys; the website SDK guide describes the larger embedded route.

Release and licence evidence stops short of 6.1.2 files

The GitHub release list showed 6.1.2 as Latest on 28 October 2026, released 27 October at commit edb0b66. Notes cover link-survey gating and PIN fixes plus security/dependency fixes. The 6.1.0 notes give a bug/security-fix window through 19 January 2027. This is a maintenance signal, not an installation test or compatibility guarantee.

The exact 6.1.2 README, root licence, EE licence and tag tree could not be retrieved in this review. In the current unversioned root licence, apps/web/modules/ee is separately licensed; listed SDK, API and survey packages declare MIT, and other covered code is AGPLv3. The current README describes AGPL core and key-gated EE code included in published Docker images. Do not label the whole repository or image AGPL, or certify those exact contents at 6.1.2. Match tag and shipped image before a licence or edition commitment; this is source classification, not legal advice.

The current self-host licence matrix lists link and website/app surveys, SDKs, question types, API, webhooks and integrations in Community, with one workspace and unlimited responses, surveys and users. It places identification/contact segments, roles, SSO, audit logs, 2FA, workflows/Unify/dashboards, reCAPTCHA and branding removal in EE. Cloud pricing has separate tier gates. Neither moving page verifies the exact 6.1.2 shipped entitlement.

Capability path for one answer

  1. Invitation and captureThe Free Text guide describes a text-area question. A link survey supplies a shareable URL; the site decides who sees it. Website/action triggers use the SDK and connection/action settings. No response was submitted in this review.
  2. Review, export and deletionCurrent results documentation describes Summary, per-response review, and all/filtered/selected CSV or Excel export. The management API documents deletion by response ID. No read-back, export or deletion was performed. That endpoint alone says nothing about copies in exports, integrations, logs or backups.
  3. Privacy and identityIdentification docs place setUserId and attributes in EE and allow unidentified triggered visitors. Unidentified is not data-free. Reserved fields can include page, referrer, UTM, device, timezone, locale, browser and country; IP capture depends on settings. Free text may contain volunteered personal details. Review browser storage, requests, edge/IP logs, notice or consent obligations and deletion scope; no cookie or compliance behavior was observed.
  4. Operation and recoveryCurrent Docker guidance describes Web, PostgreSQL, Redis/Valkey, Hub API/worker, Cube and SpiceDB. Configuration includes URL, database, encryption, Hub, Cube and authorization secrets; EE key checks, optional Community telemetry and password breach checks complicate a zero-egress assumption. AuthZed operations notes v6 SpiceDB authorization with PostgreSQL as source of truth. Back up and restore-test both data stores with secrets, configuration, versions and schema digest; include configured object storage. /health alone does not verify SpiceDB. A plain anonymous link avoids the release-note migration concern for pre-6.1 encrypted single-use links.

Evaluation and interpretation

First inspect the existing form using a fictional answer, then confirm read-back, export, deletion, access, retention and restore ownership. If a gap remains, retrieve the exact 6.1.2 tag and image/edition evidence before a private Formbricks trial. Use only a fictional answer: no real visitor instrumentation, personal identifier or live campaign launch. Test the chosen link and any egress, then read back, export, delete and rehearse coordinated recovery including authorization data and secrets. Resolve privacy and edition questions before production.

Keep invited or eligible visitors, displayed surveys, starts and completions separate if participation is later measured. An open link may have no known invitation denominator; the results guide defines survey impressions, starts and completions, not campaign sign-ups. Volunteers can differ from nonrespondents; AAPOR’s survey-methods review cautions about opt-in and nonprobability denominators and bias. Treat comments as hypotheses for page changes, not representative visitor sentiment or a conversion rate. This survey cannot establish sign-up, revenue or incremental lift; compare the separate Umami and Plausible CE post-click measurement boundaries and use a suitable comparison design for causal claims.

Search published pools, pages, reports, and evidence.