The problem: requests arrive in a shared inbox
The composite we hear on discovery calls, not a customer quote: requests come in through a shared inbox and a web form that emails the same inbox. Somebody copies each one into a sheet. The person who submitted it never hears back unless they write again. When two people answer the same one, the customer is the one who says so.
Intake is the oldest business app there is: a form the outside world can fill in, a queue the inside world works from, and a record of what happened in between. Surveys are the same shape with fewer follow-ups.
What gets built: a public link out, a worked queue in
Data-entry and survey apps have run on this platform for years: public forms with anonymous submissions and multi-tenant handling, plus change-log auditing on the records. Yours is assembled the same way, one named operation at a time.
- Objects:
ink_submission,ink_follow_up— real tables, with a lookup from follow-up to submission and the standard columns underneath. - Forms: the intake form is public — anyone with the link submits without an account, and each submission lands in the right tenant. The follow-up form is internal.
- Workflows: a new submission emails the submitter an acknowledgement with their reference and emails the triage queue; assignment emails the owner. Templated with the record’s own fields.
- Audit trail: the change log is on for submissions, so every status change and reassignment is a row you can read.
- Grids and groups: new submissions newest first, by category, my open follow-ups; triage sees all, owners see theirs — gated on the grid, not hidden in the UI.
For a survey, drop the follow-up object, keep the public form and the change log, and add a grid per question you want to read.
Starter prompt
Build a solution called Public Intake for a team that receives requests from the public through a shared email address.
Objects: Submission (submitter name, email, phone, category as multiple choice: complaint / request / question / other, description, attachment, consent checkbox, status as multiple choice: new / assigned / closed); Follow-up (submission, owner, note, outcome, closed at).
Make the Submission form public so anyone with the link can submit without signing in, and turn on the change log for Submission.
Create a Triage group that sees all submissions and a Case Owners group that sees submissions assigned to them.
Add a workflow that emails the submitter an acknowledgement with their reference and emails the triage queue when a submission lands, and one that emails the owner when a submission is assigned.
Add grids for new submissions (newest first), submissions by category, and my open follow-ups. Preview the diff before you commit.
Ship it: publish, and the link does not change
The public form gets its own link. Put it on your site, in an email, on a poster. The internal side — queue, follow-ups, grids — is the same app behind sign-in, on a laptop or a phone.
publish-solution copies Current to Testing and Production in one step, and the public form’s link does not change. Adding a question next month is a staged edit, previewed as an entity-level diff and committed as one save; the submissions already in the table stay exactly where they are.
Integrations used
The acknowledgement and the triage notice are both workflow activities. When a submission should also open a ticket or land in a spreadsheet, an ExternalService activity posts it to Zapier, Make, n8n or any HTTP endpoint — asynchronously, with an activity log you can read, and no delivery guarantee claimed. A PDF of a closed case can be generated by the same workflow when the submitter wants a copy.
Related
- Blueprint: Intake form and survey — the copyable primitives map and prompt.
- Closed in 24 Hours: A public intake portal live in 16 hours — an illustrative build of this shape.
- Previous use case: Workflow and approvals — when the submission needs a sign-off.
- Next use case: Dashboards and custom frontends — when the numbers need a different look.
Your IT lead will ask who can publish this, who can see the data, and what the agent is allowed to touch. The answers are written for them: the IT brief · security and governance.