Portals reference

A portal is a website with an audience and rules: signed-in outside people (customers, vendors, partners, employees) who see only their own records. This page documents the Explorer branch Portals and the portal editor. A portal is hosted on a website, so its pages, theme, sign-in and security options are the website's; the portal adds people, roles, access policies and operations. For a walkthrough see Give customers and partners access with a portal.

Where to find it

Workspace > Portals lists the portals (portals that belong to an application also appear in it). New portal name, for example customer-portal, creates one. A portal wizard offers portal types (Employee, Customer, Vendor, Partner), a template gallery and a theme choice. Expanding a portal opens its editor. A portal is a versioned artifact: while it is a draft its settings can be edited; operational panels (people, announcements, conversations, usage) work on the published portal.

Portal settings

Field	Description
Description	Free text.
Portal type	Drives the template suggestions: Employee, Customer, Vendor, Partner and similar.
Pages, Forms, Reports, Dashboards	The artifacts that belong to the portal.
Custom domain	For example portal.company.com. Verified from the website.
Login page	Where signed-out people are sent. Publicly reachable.
Registration page	A page with the registration form block.
Navigation menu	An existing menu reused as the portal's navigation.
Self-registration role	Automatically granted to a self-registered visitor. Unset disables self-registration even if a registration page is set.

Access settings

Field	Description
Hosted on website	The website whose pages, theme and sign-in the portal uses.
How people join	Closed — administrators add people: nobody joins on their own and there are no invitations. By invitation: people join through an e-mailed invitation. The safe default for customers and vendors. Open — anyone can register: anyone creates an account, needs a self-registration role, and is not linked to a business record, so record-scoped policies show them nothing until an administrator links them.
Roles	The roles people in this portal can hold.
Kinds of business record a user can be	For example a customer. Empty allows any.
Company administrators	Roles that can invite and switch off colleagues of their own company from the portal.
Personal API tokens	Lets people create read-only personal tokens for their own data (the API tokens block).

Files and limits

Field	Description
Cabinet for uploads	A document cabinet by name. Empty means no uploads.
Largest file (MB)	1 to 50.
Allowed file types	For example pdf, png, jpg, docx, xlsx. Empty means common documents and images. The content must match the type.
Require a virus check	Needs a scanner plugin. Without one, uploads are paused.
Most active users per month	0 means no limit. People already active this month always get in.

Service

Field	Description
Reply within (hours)	0 to 720. Messages waiting longer show as overdue. Empty means no target.
Keep data for (days)	Usage statistics, Record history, Closed conversations. At least 31 days.
Document library	Folders of the files cabinet to show: Folder, Shown as, Only for roles.

Approvals, delegates and provisioning

Field	Description
Needs your approval	Rows with Label, Entity, Field, Waiting value, Approve sets, Decline sets (optional): a record whose field holds the waiting value appears for approval, and approving or declining sets the field.
Escalate overdue conversations to (email)	Used when the assignee has no e-mail. Needs a reply target.
Users may let someone act for them (delegates)	At most 1 to 20 delegates, default 3.
Let an identity system create and switch off users (SCIM 2.0)	Enables the SCIM endpoints.

Access policies

A policy says what a role can do with data. Without a matching policy a role gets nothing.

Field	Description
Name	For example My invoices.
Who (roles)	Roles the policy applies to. Add roles to the portal first.
On	Data service (read) or Entity (write). A data service must be backed by a data view or entity that can be scoped.
Operations	read, and for entities create, update and delete.
Which records	Only the user's own business record, Only records about the user themselves, Records matching conditions, and a parent scope ("order lines whose order belongs to my orders").
Row rules	Conditions that narrow further and never widen.
Visible fields	Fields hidden from the user are removed from every result.

A read runs the data service with the person's record scope added as a mandatory filter. Writes stamp the owner on create and verify it on update and delete.

People

Control	Description
Invite someone	Email, Roles, They are a (kind of business record, or (not linked to a record)), Which one (record id), Sign-in page address (a page of the portal's website with the member account block).
Invite many	One person per line or a pasted CSV: email, roles (separated by ;), record type, record id. Up to 500, each checked and sent like one invitation, failures listed.
Members	Roles, record type and id are editable per person; access can be switched off and on.
Invitations	Resend, revoke. An invitation is single use.

Test access

Pretend to be a user and see allowed or refused. Choose On (data service or entity), Action, The user's roles, They are a and Record id, optionally their e-mail, and Also show the first rows. The result shows allowed or refused, the exact scope, hidden fields and a sample of rows.

Security checklist

Reviews the portal and its website and flags: policies on every record or every field, writes beyond the user's own records, policies naming roles the portal does not have, open registration (and whether it reaches an every-record policy), no two-step sign-in, no bot check, no session timeout, no agreements and no cookie banner. It is advice and does not block publishing.

Operations

Panel	Content
Announcements	Title (up to 200 characters), Message (up to 2000), Link (optional, a page of the portal), Only people with these roles, Also send it by email, Send later (optional). Scheduled announcements can be cancelled until sent.
Conversations	Messages from people. Assign to a person, reply (up to 4000 characters) and close. Chips show Urgent, Waiting for us, Answered and Closed. A team reply lands in the person's inbox, and by e-mail if they asked. People see "Team", never a staff name.
Usage	People with access, Active in the last 7 days, Active in the last 30 days, Invitations waiting, calls per day, most used data, and monthly active users with a CSV download.
Service levels	Conversations answered, first reply (median and 90th percentile), overdue now, requests picked up and the median time to first touch, searches, and the share answered by help content.
Health	Daily health over the last days.

Generate from my application

Starter kit builds a portal's policies and pages from one of your applications: for each of its entities you give the owner field that ties a record to a business party. The result is a portal you review and publish.

Move to another environment

Application that carries it and Promote to show a differences preview and promote the portal definition through environment promotion. Members and invitations are runtime data and are never part of a package.

Permissions

Designing portals is an authoring action on the portal artifact type. Portal people's rights are the portal's own roles and policies, not workspace roles. Actions such as invitations, uploads, share links and signing are recorded in the audit trail with category portal.

API and CLI

/api/v1/authoring/portals for the definition; /api/v1/portal-access-admin/{portal}/... for members, invitations, announcements and conversations; public portal endpoints under /api/v1/public/portal-*. CLI operations portal-members, portal-invitations, portal-invite (see Operations reference).

Related

Websites, Give customers and partners access with a portal, Permissions, Documents.