Skip to content

Give customers and partners access with a portal ​

The real problem ​

Northwind's customers should sign in, see only their own invoices, raise requests, upload documents and talk to the team. Partners need a different view. Nobody should see another company's records, and an administrator at the customer should be able to invite their own colleagues.

A portal is a website with an audience and rules. It adds people, roles and access policies to the website, so the same designer builds the pages.

The idea in one minute ​

  • A portal user is a website member with a portal membership: roles, and the business record they belong to (for example a customer).
  • Registration is closed, by invitation, or open. Invitations carry roles and the business record, can be sent in bulk (up to 500 lines or a CSV), resent, revoked, and used once.
  • Access policies decide what a role may read and write. A read runs through a data view or entity with the person's record scope added as a mandatory filter, and hidden fields removed. A policy can narrow further with row rules.
  • Blocks show the data: My records (list, detail, add, edit, history, files), Summary tiles, Catalog of requests, Messages, Notifications, Search, Document library, Our team, API tokens, and surveys and "was this helpful" for help pages.
  • Pages, sections and blocks can require roles, membership tiers or a kind of business record. A whole page can be gated too.

Designer path (Studio) ​

  1. Open Portals from Home or the Explorer tree and use the wizard: portal type, name, data source, sign-in, theme, template. Starting points include portal home, My records, Requests, Documents, Help article and Search.
  2. Access policies: add a policy per role, pick the data, the scope (own record, parent record, every record) and the visible fields. Each policy has a plain-language summary.
  3. Test access: pretend to be a user with given roles and record. Studio shows allowed or refused, the exact scope, the hidden fields and the first rows.
  4. People: invite one person or many, see who has access, switch access off.
  5. Security checklist: it flags broad policies, open registration, missing second sign-in step, missing bot check and similar. It is advice, not a block on publishing.
  6. Run it: announcements (now or later), conversations with users, usage and monthly active users, service levels, and a retention setting for old data.

Documents in a portal ​

  • A document library block shows folders from document management for everyone or chosen roles. Members can search and download.
  • Video and audio files show a Play button. Playing uses a signed address that expires and follows the same folder access as the download.
  • Members can upload files to their own records, within type and size rules, and sign a file by typing their name. Share links are time-limited and counted.

Code path (CLI and MCP) ​

bash
erp plugin op portal-members     --portal customers
erp plugin op portal-invitations --portal customers
erp plugin op portal-invite      --portal customers --json '{"email":"buyer@example.com","roles":["customer"],"partyType":"customer","partyId":"C-1001","acceptUrl":"https://portal.example.com/accept"}'

A portal definition ships in a plugin like any other artifact. People and invitations are runtime data and are never part of a package.

Safety and limits ​

  • Reads and writes always go through the policies. A role with no matching policy gets nothing.
  • Sign-in options: password, emailed code, emailed link, authenticator app, text message; consent capture; cookie banner; network rules; a bot check.
  • Personal API tokens are optional, read-only unless chosen, hashed, and stop when the owner's access stops.
  • Actions such as invitations, uploads, share links and signing go to the audit trail.
  • A customer company's administrator can manage only the people of their own company.

What is not built ​

  • Passkeys and recovery codes for authenticator apps.
  • Virus scanning of uploaded files.
  • Portal forms that start a workflow, beyond creating a record that a workflow can pick up.
  • Looking up party records by default. An id is accepted as typed unless a plugin registers the record kind.
  • Playing a library video with a real member session has been tested in code but not yet end to end in a browser.

Where next ​