An enquiry should
never disappear quietly.
Flowdesk makes one operational workflow inspectable: capture an enquiry, validate it, review it, and deliver it once — even after a temporary failure.
Try the working demo ↗The workflow
A small service business needs a person to approve enquiries before they reach its CRM. Webhooks can be repeated, input can be invalid, and the destination can be unavailable. Flowdesk makes those states visible and recoverable.
A 30-second test
- Submit the prefilled fictional enquiry.
- Replay the webhook. The queue still has one enquiry.
- Pause the CRM simulator, then approve the enquiry.
- Reload the page. The failed delivery is still pending.
- Restore the simulator and retry. One CRM record appears.
- Inspect the event trail and export that record as CSV.
The Run recovery demo button executes the same server requests for a quick guided tour.
What is implemented
- Validated inputs and server-enforced idempotency, including conflicting-payload rejection.
- Human approval/rejection and explicit delivery retries.
- Approval, pending delivery and audit events persisted atomically in one versioned state update.
- Optimistic concurrency control: simultaneous requests cannot overwrite a newer state.
- Session-level counts for deliveries, replays, validation failures and delivery attempts.
- Isolated visitor sandboxes with server storage, a 24-hour expiry and bounded records.
What this demo does not claim
This is a self-initiated engineering demonstration, not a paid client case. Contacts and businesses are fictional. The destination is an internal CRM simulator: no email, SMS, payment, external CRM or AI model is called. There is no measured customer ROI or production SLA. Business email deduplication is not implied: replay protection is keyed by the request's idempotency key.
Implementation & boundaries
The hosted version uses a JavaScript Worker API and Cloudflare D1. The original local prototype uses Python and SQLite. A visitor gets a random, HttpOnly cookie; only its hash identifies the server sandbox. This is a temporary demo session, not an account or cross-device login. Up to 20 enquiries and 150 actions are allowed per sandbox; the event feed retains the latest 80 events. Expired sessions cannot be read, and expired records are removed when a new sandbox is created.
Please use fictional information only. Demo emails must end in @example.com. Cloudflare Turnstile checks for automated traffic. Optional Google sign-in shares basic identity (name, email and Google user ID) with this demo; it does not connect Gmail, Drive or Calendar. The profile is stored only in the temporary sandbox and is cleared on sign-out or expiry. Google and Cloudflare process verification/sign-in requests under their own privacy policies. Short-lived hashed network identifiers support request limits; raw IP addresses are not stored by this application. Reset clears your sandbox's enquiries and events; it does not affect other visitors.
Access protection
Writes require successful server-side Turnstile verification, valid for 30 minutes. The server checks the challenge hostname, action and sandbox binding. Network limits apply to API requests and new sandbox creation. Google ID tokens are verified cryptographically for signature, issuer, audience, expiry and a session nonce. Session cookies rotate at sign-in/sign-out. Google sign-in identifies this temporary browser sandbox; it does not provide cross-device account storage.
From demonstration to delivery
A real engagement starts with agreed fields, validation rules, ownership of data, destination API, acceptance examples and operating constraints. The delivered system can then connect the actual CRM, alerts and deployment environment, with agreed monitoring and support.
Built by Dmitry Popov · Software & Applied AI Engineer.
More work at rokenshi.com ↗