Build a customer portal with AI: private records and useful account journeys

A worked example: where the task becomes difficult

A fictional design studio wants clients to read project updates and download approved deliverables. Client A must not see Client B’s brief, even if a URL or record identifier is guessed. The first version needs a project list, one project detail and an update acknowledgement. It does not need invoices, messaging and team roles simultaneously. Use two controlled accounts and fake project material while establishing the access contract.

Decisions to make before implementation

Decide whether ownership belongs to a person, an organization or an invited project team. Those models produce different access rules. Enforce ownership in the receiving service or database policy, not only by filtering interface lists. File links need the same scrutiny as structured records. Expiring download access may be appropriate for private deliverables. Explain what happens to invitations and downloads when membership is removed.

A practical sequence for the work

Use the sequence below as a task boundary, not as a claim that the example has been executed. Work with approved inputs and the project’s actual architecture. If a required integration or permission is unavailable, keep that stage visibly incomplete rather than generating a plausible substitute result.

• Define account membership and the exact resource a customer can access.
• Implement authorized project listing and detail retrieval using controlled fixtures.
• Build loading, empty, expired-session and permission-denied states separately.
• Test access with two identities, then add the smallest useful customer action.

A detailed brief you can adapt for your agent

Replace the illustrative context with your approved facts and controlled inputs. Keep the stated boundaries when adapting the brief. The expected deliverable matters more than a particular tool name: ask for an explanation grounded in the inspected material and evidence for the requested outcome.

Build a client project portal using the current authentication and storage architecture. Map resource ownership first. Implement one authorized project journey and an acknowledgement action. Use fake fixtures for two accounts. Check direct record and file access, not only UI filtering. Do not add new identity providers or replace the existing authentication stack without a documented requirement.

Failure modes that an attractive preview can hide

A dashboard can hide another customer’s project in navigation while exposing it through a detail endpoint. Test direct requests, changed identifiers and download URLs independently of page visibility. Avoid displaying sample balances or activity as real account data. If a backend operation is unavailable, identify that limitation rather than generating plausible placeholder records after sign-in.

Technical references: MDN: sending form data

Acceptance checks and the evidence to retain

Provide the ownership model, authorization locations, two-account results and incomplete integration boundaries. The customer view should show only confirmed records and offer useful states when none exist.

Specific answers

Common questions