Portal Administration

Portals are created and configured in the Portals section (/portals), available to administrators in the "Application Management" menu.

Portal list

Each portal in the list shows: name, a link like /p/slug, status (Active / Disabled), and authorization type. Available actions:

• Configure — open the portal settings
• Copy link — copy the portal's public address to the clipboard
• ✕ — delete the portal

The Create Portal button opens the form for a new portal.

Creating a portal

1. Go to the Portals section
2. Click Create Portal
3. Fill in the basic settings
4. Click Create Portal
5. Add at least one page with a form

Basic portal settings

Field	Description
Name	The portal's display name, e.g. "IT Support Portal"
Slug (URL)	The portal's address segment: /p/slug
Authorization	Public / Magic Link / Registration — see below
Primary Color	The portal's accent color (buttons, highlights)
Logo URL	An optional link to a logo image
Portal Active	Toggle — a disabled portal isn't reachable via its link

How to require login (authorization)

The login requirement is set via the Authorization field on the portal settings page — this is a toggle at the level of the whole portal, not a single page:

Value	Behavior
Public (no authorization)	Anyone can submit a request via the link, without logging in
Magic Link (email link)	The visitor enters an email, receives an email with a passwordless login link — this is the "portals requiring login" described in Submitting a Request Through a Portal
Registration	The visitor goes through full registration

After changing the value, click Save.

Portal pages

A portal consists of one or more pages. The Portal Pages section on the portal settings page lets you add, edit, and delete pages.

1. Click + Add Page (or Edit on an existing one)
2. Fill in the page parameters
3. Click Save

Page parameters

Field	Description
Name	The page title, e.g. "Submit a Request"
Slug	The page's address segment within the portal
Page Type	Request form, Service catalog, or Info — see below
Page Active	Toggle for page visibility

Page types

Type	What the visitor sees
Request form	A form creating a record of the chosen entity (request, incident, etc.)
Service catalog	Tiles of records of a chosen catalog entity; clicking a service opens a request form tied to that service
Info	A static text block — an announcement, instructions, contacts

Request form

After choosing the Entity, a checklist of its fields appears: checked fields are shown to the visitor, unchecked ones are hidden (see "Linking a form to an entity" below).

Service catalog

A catalog page has two parts:

1. The source entity — the catalog itself (e.g. a "Services" reference): its records are shown to the visitor as tiles.
2. Request types — which requests can be submitted for a catalog item. Each request type is an entity related to the source (candidates come from relations) with its own set of visible form fields. With several types, the visitor is asked "What would you like to submit?" after picking a service.

A record created through the catalog is automatically linked to the chosen catalog item via the configured relation — the operator immediately sees which service the request is about.

Example — an IT catalog: source "Services" (Email, VPN, Hardware), request types "Incident" and "Service request", both related to "Services". The visitor picks "VPN" → "Incident" → fills the form; an incident referencing the VPN service appears in the system.

Info

A text block with a configurable style (neutral/info and other color variants) and an optional display schedule — start and end dates. Handy for temporary announcements like "Support is closed on Dec 31": the block appears and disappears on the given dates by itself.

Linking a form to an entity

The portal form is built directly from the entity designer: after selecting an Entity, a list of all that entity's fields appears with checkboxes. Checked fields are shown on the public form; unchecked ones are hidden from the portal visitor.

The portal form doesn't separately configure which fields are required — a field's required status is inherited from the entity itself (the "Required" flag in the entity designer). If a field is marked required in the entity and visible on the portal, the visitor won't be able to submit the form without filling it in.

Not all field types can be shown on a portal form — system types (state model, designer-specific types, files, images, map point) aren't displayed or required on the public form, even if marked required on the entity itself. The supported field types (text, multiline text, email, date, yes/no, list, and a number of relations — company, department, user, related entity) match the basic set described in Submitting a Request Through a Portal.

After the form is submitted

When the form is submitted, the system:

1. Creates a record of the selected entity
2. Automatically starts the business processes linked to that entity and marked as auto-starting
3. If the portal's authorization isn't public (Magic Link or Registration) and the visitor provided an email — creates a portal visitor and sends them an email with a tracking link

For more on what the visitor sees and receives after submitting, see Submitting a Request Through a Portal and Tracking a Request.

Other features

• The portal visitors section stores the email, name, and login history of visitors who submitted requests or logged in via a magic link
• The portal link (the Copy link button in the portal list, or the address field on the settings page) leads to /p/slug — you can publish it on your company website or send it to customers