One web address, one dataset, and every client seeing only their own rows. That is the outcome, and you get there by describing the rule in plain English rather than writing access-control code. Taskade Genesis matches the signed-in person to their records and hides everything else before the page renders.
Client Portal is a live Taskade Genesis app you can try on this page, and it is the most useful starting point for this build. Filter it, sort it, see a real signed-in surface behaving like a working system, then choose "Use this app" to clone it in about ten seconds and layer your own scoping rules on top. Trying a finished app first is the whole advantage over a blank canvas.
The build gives you three things that usually take a developer. First, a signed-in identity: Taskade Genesis Auth confirms who the visitor is and turns them into an App User your app can recognize. Second, a match rule: the client's verified email maps to their row in the connected project, so the portal knows which records belong to them. Third, tag-based gating: people tagged client see the client screens, people tagged vendor see the vendor screens, and anyone untagged sees the sign-in page. You describe those rules to Taskade EVE in sentences like "only show the billing tab to people tagged client" and it wires the checks for you.
Here is how it behaves with two customers. Acme's contact signs in and the page renders the four projects, six documents, and two open invoices where their email appears in the contact field. Northwind's contact opens the identical web address a minute later and sees their own three projects and one invoice. Neither request ever carries the other account's rows, because the filter runs before the page is built rather than hiding rows in the browser. Add a tag and the same mechanism gates whole pages: your vendor contacts reach work orders and never see the billing tab at all.
Workspace DNA is what keeps the rules honest over time. Memory holds the client records and the tags. Intelligence interprets your plain-English rule and turns it into a repeatable check. Execution applies it on every request, including the request that arrives at 2am from a phone.
The scoped data still renders across every layout you need:
- Table view for your internal roster with the owner, tag, and access status per client
- List view for the tidy single-client feed your customer actually reads
- Board view for grouping accounts by tier or lifecycle stage
- Mind Map view for seeing how parent accounts relate to their sub-accounts
- Plus Calendar, Gantt, and Org Chart across the 7 project views
Automations keep access current. Connect Taskade automations so a new signed contract tags the client automatically, a closed account revokes the tag, and a change of contact reassigns the record to the new email. Across 100+ bidirectional integrations, your CRM or form tool pulls the new account in, while Slack and email push the access confirmation out.
Decide your match key before you invite anyone. Most teams use the client contact email because it is already verified at sign-in, but an account code works well when several people share one account. Whichever you choose, make sure every row has it filled in, since a blank match field is the one way a record becomes invisible to the client who owns it.
The AI agents in the app carry 34 built-in tools including persistent memory, file analysis, and custom slash commands. Ask the agent inside the portal a question and it answers from the signed-in client's records only, so an agent never leaks one customer's numbers into another customer's chat.
Clone the app, invite your team, and the data stays yours. App users are tracked separately from workspace seats, so scoping access to a hundred clients does not multiply your bill. App Users is in beta, and client sign-in is available on Business plans and up, $25/mo billed annually.
Read the mechanics in App Users and Build a Customer Portal, learn how project permissions work in Permissions, or start a fresh build at Taskade Genesis. Pair this with Build a Branded Client Portal With Sign-In for the shell around it and Set Up App User Invites and Access Tags to manage who gets in.
Frequently Asked Questions
How does the app know which records belong to a client?
It matches the verified email from sign-in against a field in your connected project, usually a client email or account owner column. Anything that matches renders. Anything that does not match never reaches the page.
Can one client see several accounts?
Yes. Map one signed-in email to more than one row, or tag a person as the owner of a parent account and let them see every child record beneath it. Describe the shape you need and Taskade EVE builds the rule.
Do I have to write any code for the access rules?
No. You describe the rule in a sentence, for example "clients only see rows where their email is in the contact field, and only people tagged vip see the roadmap page." Taskade EVE wires the checks into the app and you test them from the preview.
What stops a client from editing another client's data?
Two things. The gating rule means other rows are never sent to their page in the first place, and the role you give them in the portal decides whether they can write at all. Most portals set clients to read plus submit, so they can add a request but not touch the roster.
Can I test the rules before inviting anyone?
Yes. Invite a test address of your own, sign in as that person, and confirm the scoped view is what you expect. Only after that do you paste in the real client list.
Which plan do I need to scope access this way?
Client sign-in and custom domains are available on Business plans and up, $25/mo billed annually, and both sign-in and App Users are in beta. Building and previewing the app works on every plan, and the Free plan includes 3 Taskade Genesis apps and up to 6,000 one-time AI credits with no monthly reset.
What if my client list lives in a spreadsheet today?
Import it. The connected project behind the portal is a real database with a Table view, so a CSV of accounts becomes the roster, and the email column becomes the match key for gating.
What happens if someone signs in with no matching record?
They reach a friendly empty state rather than an error, and you see them in the App Users table as signed in with nothing assigned. That is usually a data problem, such as a contact email that does not match the roster, and it takes one edit to fix.
