01 / Define the people and records
Start with customers, support staff, tickets, and replies. Describe which records each role can create, read, and update.
USE CASE · CUSTOMER PORTALS
Start a customer portal with one complete support workflow.
Give customers a place to submit a request, see its status, and read a reply. Define who can see each record before expanding into billing, documents, or business-system integrations.
Make the first version easy to check.
02 / Build one complete workflow
A customer opens a ticket, a staff member replies, and the customer sees the response. Use sample accounts and records to check every step.
03 / Review and release
Check the screens, direct API requests, and access boundaries. Review the application changes before arranging a managed preview deployment.
Worked example: a support request from start to finish.
Suppose a customer needs to update a delivery address. The customer signs in, creates a ticket with a subject and message, and sees an open status. A support staff member reads the request, adds a reply, and marks it resolved after the customer confirms the change.
The first release can stop there. A clear ticket history and correct customer access are enough to evaluate whether the workflow is useful. Attachments, email notifications, billing, and a CRM connection can become separate tasks once this path works.
| Action | Customer | Support staff |
|---|---|---|
| Create a ticket | For their own account | For an authorized customer |
| Read tickets and replies | Their own tickets | Tickets within the assigned support scope |
| Change the ticket status | As defined by the workflow | Within the assigned support scope |
Turn the workflow into a bounded agent task.
Give the coding agent the user roles, the ticket states, a few sample records, and the expected result of each action. Ask it to identify unresolved decisions before implementation: for example, whether a customer can reopen a resolved ticket and who is allowed to assign a request.
In Redgold’s managed application workflow, the data shapes, routes, and domain behavior remain visible in Git. The platform coordinates routing, execution, storage, and deployment during preview. You can review the application contract alongside the screens and tests.
Check the boundaries as well as the happy path.
Once the first workflow is ready, prioritize the next addition using actual customer needs. A portal with one reliable support path is a useful starting point for that conversation.
- Customer A cannot list or open customer B’s ticket, even with its identifier.
- The server enforces permissions when a request bypasses the interface.
- Empty messages, failed submissions, and repeated submissions have defined behavior.
- Status changes and replies remain visible after a refresh.
- Sample records and connected production data have a clear transition plan.