01 · DEFINE THE FIRST VERSION
Give the app one useful job.
A service request app gives customers a place to describe what they need and gives a team a consistent way to follow up. For this first version, the customer chooses a service and submits contact details. The team reads the request and changes its status as the work progresses.
Keep payments, complex scheduling and automated notifications outside this first flow. Write down who can submit a request and who can view or update it. Those decisions affect both your screens and your data connection’s access rules.
02 · PLAN THE REQUEST TABLE
Start with the information you need to keep.
Create a table for requests in the project’s database tools, or use a suitable existing data connection. The names below are example fields you choose for this app. Keep the record’s identifier available for later reads and updates, and use a consistent set of status values across the form and team screens.
| Field | Type | Purpose and source |
|---|---|---|
customer_name | Text | The name entered in the request form.Name Text Field |
contact_email | Text | The address your team will use to reply.Email Text Field |
service | Text | One of the services your team offers.Service Dropdown |
details | Text | The customer’s description of what they need.Details Text Area |
status | Text | The current stage: New, In progress or Resolved.Initial value, then status control |
03 · DESIGN THREE SCREENS
Make the next step clear on every screen.
Use the visual editor’s form, input, button and list components to build the journey. Keep the customer’s submission view focused on the request, and give the team a separate place to work through the records.
Request form
Add Text Field components for the name and email, a Dropdown for the service, a Text Area for the details and a Button to submit. Label every input and explain which fields are required. Keep the form short enough that a customer can complete it on a phone.
Request list
Use a list layout to show the service, customer name and status for each request. Make each item open the corresponding detail screen. Include an empty state that explains where new requests will appear, and decide which records each signed-in team member should be allowed to read.
Request details
Show the selected request’s fields and a control for changing its status. Keep the record’s identifier available to the workflow, even if you do not display it. That identifier is what lets an update change the intended request rather than every record with the same customer name.
04 · CONNECT THE WORKFLOWS
Connect the interface to saved records.
AppStruct’s workflow menu includes Data actions for Add row, Get row and Update row. Configure each action’s data connection, table, mapping and filters. The aim is to complete one create–read–update journey before adding more features.
Create the request with Add row
Attach a workflow to the form’s submit Button. Choose the Data action Add row and configure the table and field mapping. Map the current input values to the example fields below, and set a new request’s status to New. Check that the mapping uses the values from this form, rather than placeholder text.
Decide what the customer should see after a successful save. A confirmation message should follow the completed write. Keep the entered information available when saving fails, so the customer can correct the problem or try again without retyping the request.
Read saved requests with Get row
Configure a Get row data action for the request table. Set Type of response result to Multiple for the request list, then map the returned fields to its template elements. Define the filters needed for the intended team view and keep the returned identifier with each item.
Opening a request should read the selected record’s details. Use that record’s identifier in the navigation or selection data. Test two requests from the same customer: the detail view must still open the right one.
Change its status with Update row
Connect the status control or a save Button to Update row. Map the selected status to the status field, and filter the operation by the selected request’s identifier. Leave customer details unchanged when the action is only meant to update the status.
Read the record again after saving and check the list and detail views show the same state. If the process already lives in another service, an HTTP Request action can be an alternative connection point; follow that service’s authentication and data requirements.
05 · TEST THE COMPLETE JOURNEY
Check what happens after the button press.
Use fictional test details while building. Test the customer and team views as separate roles, and inspect the resulting records in your data connection. These checks help you find problems that a well-designed form can hide.
Valid request
Submit a request, reopen the list and open its details. Confirm that the name, email, service and description match the original input. Refresh the published app and check that the saved record is still available.
Missing or invalid information
Try an empty required field and a mistyped email address. Add the validation your workflow needs, explain the problem beside the form and confirm that incomplete submissions do not create misleading records.
Failed or repeated submission
Test an unavailable connection and a repeated button press. Show a useful failure state and review how your workflow handles retries. A success message alone is not a persistence check; reopen the saved record.
Access and a targeted update
Use a separate customer session and team session to check access to the list and details. Then change one request’s status and confirm that another request is untouched. Visibility in the interface should match the access rules enforced by your data connection.
06 · PUBLISH A WEB VERSION
Review the published app on its own link.
Open Publishing and choose Web App to build a web version. The publishing panel shows the project’s .appstruct.app address. Open that link and repeat the form submission, list and status-update checks in the published version.
Test on the screen sizes your customers and team actually use, including a phone keyboard for the form. Check navigation, loading states and access from a separate session. Review the current plan and publishing requirements before deciding on a larger rollout or a mobile-store release.
07 · TRY THE WORKFLOW PREVIEW
Explore the journey before building your screens.
This small preview demonstrates how the form, request details and status control fit together. It uses temporary example entries in this page. A real app needs the database connection, workflow configuration and access checks described above.
QUESTIONS & ANSWERS
A few decisions before you build.
Do I need to start from a template?
No. This walkthrough starts from the form, data fields and workflows the app needs. A template can help when it matches your process, but you should inspect its actual screens and data connections before relying on it. The steps here do not require a particular marketplace template.
Can customers submit requests while only the team sees the list?
That is a useful design for a service request app, and it requires deliberate access configuration. Define who can create, read and update records in your chosen data connection. Use separate test sessions to verify the policy; hiding a navigation link does not by itself establish access control.
Can I connect an existing system instead of using an AppStruct table?
The workflow tools include HTTP Request, and the database action settings include AppStruct and Supabase. Choose the connection your process needs, map its inputs and responses, and test its permission and error behavior. Authentication, field names and available operations depend on the system you connect.
Can the same project be published for mobile devices?
The publishing tools include Web App, Android App and iOS App. Start by checking the form and team views at their intended screen sizes. Android and iOS publishing depend on an eligible subscription, developer accounts, platform configuration and the relevant app store’s review process.