Build a client portal from a spreadsheet

A spreadsheet can describe projects, but a portal needs a deliberate boundary between each client and the information they may see. Treat ownership as part of the data model.

This is an illustrative workflow to adapt and test, not a timed product benchmark or a verified customer case study.

Define the information and the work

Give clients and projects stable identifiers. Connect documents and requests to both. Separate staff-only notes from customer-visible updates, and define which changes customers may make themselves.

Write these decisions into a brief before polishing the interface. A useful brief explains what someone can do, what should be saved, and how another person picks up the result. Keep the original material available while reviewing the first version so differences can be checked rather than guessed.

Try a concrete review scenario

Create two clients with different projects. Try direct links to the other client’s project and files. Submit a request, update it as staff, and verify that only the intended client sees the result.

Record the steps, expected result, and any difference you find. Ask for one focused correction, then repeat the same scenario. Include an empty state and a failure as well as the successful path. This gives the first version an acceptance test and later changes a practical regression check.

Give the result a home in your App Cloud

Bring the spreadsheet’s reviewed records into a database and connect project files to their owners. Authentication and access rules support the customer-specific experience. A support agent can draft answers using the current customer’s permitted documents; it should have the same information boundary as the person it is helping.

Create and refine this experience in Studio. Keep the first version focused enough to test with the scenario above.

Publish and keep learning

Check the account’s current allowance and the usage of the capabilities you selected. Publish the reviewed app from Studio, then repeat the essential task on the shared link.

Follow what people actually do with the app. Use observed problems and measured usage to decide the next change; completion times, savings, and business outcomes depend on your own workflow.

Continue with the related guide · Explore the building blocks · Understand your App Cloud