Request portal

This second tutorial builds a complete mini-app: a public request form, a staff backoffice queue, and an e-mail when status changes. It assumes you already completed My First App.

What you will build

Public visitor ──► Submit request ──► Staff reviews ──► Status e-mail to requester

• Portal Public — anyone can submit a request
• Portal Backoffice — staff list, open, and update requests
• Object Request — the shared data
• Object Operator — staff who log into the backoffice

1. Data model

Create object Request with fields:

Field	Type	Notes
title	Text	Short summary
description	Long Text	Details
requester_email	E-mail	Where notifications go
requester_name	Text	Optional
status	Choice	New, In progress, Done, Rejected — default New
staff_notes	Long Text	Internal only
submitted_at	Date and Time	Optional; set via form task or auto field

Create object Operator with at least:

Field	Type
email	E-mail
password	Password
name	Text

Add yourself as an operator record in the Builder.

2. Public portal

1. Create a top-level page Public (leave it without login).
2. Add a Rich Text intro (“How to submit a request”).
3. Add a Form that creates a Request.
4. Show title, description, requester_name, requester_email. Hide status and staff_notes from the public (or omit them and set defaults with a form task).
5. On submit, add a form task that sets status to New if needed, and optionally notifies staff at a fixed inbox.
6. Configure follow-up to a thank-you child page with a short confirmation message.

Open the public portal URL and submit a test request.

3. Staff backoffice

1. Create a top-level page Backoffice.
2. Enable login on that portal using the Operator object.
3. Add a Grid of Request records: columns title, status, requester_email, submitted_at. Enable filters on status.
4. Add a child Request detail page with:
   • a Detail widget for the request;
   • a Form that updates the request — include status and staff_notes (and keep requester fields read-only if useful).

Log in as your operator and open the test request.

4. Status e-mail to the requester

On the update form (or an object-level task run from a grid button), add a task:

• Condition: status changed to Done (or run only when status is Done / Rejected on submit)
• Action: Send e-mail to {requester_email} with a short template explaining the outcome and including {title} / {staff_notes} as appropriate

Mark a request Done and confirm the message arrives. If it does not, see Troubleshooting.

5. Polish (optional)

• Role-aware Menu on the backoffice home
• Chart of requests by status for managers
• Display rules to require staff_notes when status is Rejected
• Protect staff-only fields so they never appear on the public form

Checklist

• Public form creates a New request
• Staff can log into Backoffice and see the queue
• Staff can change status and notes
• Requester receives an e-mail on completion (or rejection)

Next steps

• Turn this into a richer blueprint: Customer portal tutorial
• Lock down access patterns: Security overview
• Promote safely later: Production playbook