Portal access
Overview
Portal access accounts belong to your customers in the customer portal — not to your staff. The two worlds are separate: their own sign-in, their own layout, their own rights. For staff there is Users.
That separation is deliberate and not duplication. By construction, a portal account cannot reach the internal application — not even through a wrongly set permission.
Core tasks
Invite. Invite creates an invitation for a contact. A contact alone has no access; only the invitation creates it. Until it is taken up, the access sits at Invited.
Grant rights. Access is not granted wholesale but per object. Rights are possible on a customer, a project or a contract, each with individually selectable capabilities — viewing projects, for instance. An invited person therefore sees exactly the slice they were invited for, not the whole customer.
Use access templates. At the top of the page you maintain access templates — fixed sets of rights per customer type, e.g. "Commercial contact" (approve quotes, view invoices, sign contracts) or "Technical contact" (projects, tickets, acceptances, files). When inviting and when granting rights you pick a template; it pre-fills the rights, and you can still add or remove single rights afterwards. Changing or deleting a template does not affect rights already granted — every row stays as it was granted.
Out of the box there are two templates, "Kaufmännischer Kontakt" (commercial contact: approve quotes, download files, sign contracts, view invoices and own prices and terms) and "Technischer Kontakt" (technical contact: view projects, view and create tickets, confirm acceptances, upload and download files); they carry the Standard tag and apply in all brands. You can freely adapt name, description and rights — updates do not overwrite your version. If you delete a standard template, it stays deleted; later updates do not create it again.
Enable group customers. If the customer of an access belongs to a group (company hierarchy on the customer), the same access can see further customers of that group — but only the ones you explicitly enable. Open grant permissions, leave the area on Customer and choose the subsidiary or sister company in the Customer field. The rights apply to that customer only: whoever may approve quotes at the parent may do so at the subsidiary only once you grant it there as well. In the portal the person chooses at the top right which customer they are currently working for. Whoever may approve quotes in the group customer also gets the approval link when a quote is sent to their address; it opens the portal right in that customer. Write actions (approvals, uploads, replies, settings) and downloads within a group customer are recorded in the portal log — with customer, action and result —, plain page views are not. If the group link on the customer is removed, access to that customer ends immediately.
Survey what exists. The list shows email, name, owning customer, status, last sign-in and a summary of the rights; time-limited rights show their expiry date ("… · until 04/11/2026"). The three statuses are Invited, Active and Suspended. Whoever was invited via Invite appears only after redeeming the invitation; accounts taken over from an old system are listed as Invited beforehand.
Send invitations. Accounts from an old system (see Data import) are set to Invited without anybody having received an email. Send invitations sends every invited account of your brands an invitation (valid for 7 days) — only after a confirmation. Accounts with a still valid invitation are skipped, active and suspended ones are never contacted. You invite a single account via the envelope icon in its row. At most 200 invitations go out per run; the feedback says how many are still pending.
Keep track of open invitations. The section Open invitations lists every invitation that was sent but not yet accepted — with customer and validity; expired ones carry the marker expired. Resend sends a new invitation with the same permissions (valid for another 7 days); the previous one stops working, so there is always exactly one valid link. Revoke invalidates the link after a confirmation — for example when the address turns out to be wrong. You only see and act on invitations of the brands in which you may invite.
Suspend. Access can be suspended without being removed — the right route when a contact person changes and the history should stay intact.
Fields in detail
Four actions: the invitation, the permission grant, the status switch and send invitations. A portal account itself has no edit form on this page — it comes into being through the invitation and is steered through permissions and status.
Invite
| Field | Required | Values / format | What it does |
|---|---|---|---|
Email email | yes | email address | The sign-in address of the portal access. The invitation goes there, and it later serves as the sign-in name. |
Customer customerId | yes | an existing customer | Who the access belongs to — and therefore what it can see at all. A portal user sees only that customer's cases. |
Contact contactId | no | a contact of the chosen customer | Which person is behind the access. The choice is limited to the contacts of the chosen customer; without a customer it is empty. |
Brand brandId | no | one of your brands | Which brand the invitation runs under. Empty means it follows the customer's brand. It stays brandless only for a brandless customer — and only if you are authorised across brands. |
Access template accessTemplateUlid | no | an access template of the brand or a brandless one | Fills the pre-set permissions with the template's rights. In the mask the template is a pre-fill you can change afterwards; via the API its rights are added to the ones sent. A template of another brand is rejected. |
Pre-set permissions intendedAccess | no | list of capabilities | Permissions the access already receives with the invitation. The mask creates them as one row at customer level; extending them later through grant permissions is always possible. |
Grant permissions
Access is not granted wholesale but per object. A row consists of area, assignment and capabilities.
| Field | Required | Values / format | What it does |
|---|---|---|---|
Area scopeType | yes | customer · project · contract | What the row refers to. Project and contract are only offered when the respective module is active. |
Assignment scopeId | conditional | a project or contract of the customer; with customer a customer of the same group | Which project, which contract. With customer the field stays empty — the row then covers the whole own customer. If you choose another customer of the same group in the Customer field, the row enables exactly that customer with exactly these rights. A customer outside the group is rejected. With project and contract the mask demands a choice. |
Access template accessTemplateUlid | no | an access template of the access's brand or a brandless one | Pre-fills the rights with those of the template. Via the API its rights are added to the ones sent. Later changes to the template do not change this row. |
Permissions capabilities | yes | view projects · view tickets · create tickets · approve quotes · confirm acceptance · upload files · download files · view quota · sign contracts · view invoices · create returns · view licences · view orders and shipments · view own prices and terms | What the person may do in this area. At least one capability; a row without one would have no effect. |
Expiry date expiresAt | no | date | From when the row no longer applies. Empty means open-ended. |
Access templates
| Field | Required | Values / format | What it does |
|---|---|---|---|
Name name | yes | text, up to 120 characters | The template appears under this name when inviting and granting rights, e.g. "Commercial contact". |
Description description | no | text, up to 255 characters | Short note on what the template is for. |
Permissions capabilities | yes | list of capabilities (as in grant permissions) | The rights the template pre-fills. At least one. |
Brand brandId | no | one of your brands | Selectable only for accesses of this brand. Empty means all brands — only users authorised across brands may do that. |
Suspend and reactivate
| Field | Required | Values / format | What it does |
|---|---|---|---|
Status status | yes | suspended · active | Whether the access can sign in. Suspend is the right move when a contact person changes: the access and its history remain, only the sign-in is closed. An access belonging to another brand cannot be reached this way. |
SMS and WhatsApp
An access can request its notifications in the portal profile additionally by SMS or WhatsApp — only with its own consent. The list then shows a SMS or WhatsApp badge; its hint names the date of consent. With portal.user.suspend you switch the channel off (speaker button in the row, with confirmation), for example when the customer withdraws on the phone: mobile number and consent are removed, notifications then only go via portal and email. Only the access itself can switch it on — consent can only be given by whoever receives the messages. Sending runs through the configured SMS/WhatsApp channel; every short message is recorded with its delivery status in the contact's history. Outside the 24-hour window WhatsApp only accepts approved templates: enter the template (content SID HX… or its name at Twilio) in the system settings under portal.notifications.whatsapp_template; every WhatsApp notification is then sent as that template with the variables {{1}} title, {{2}} text and {{3}} portal address. Empty means free text.
Send invitations
| Field | Required | Values / format | What it does |
|---|---|---|---|
Customer customerId | no | existing customer | Only the invited accounts of this customer. The interface leaves the field empty — then all of your brands. |
Accounts ulids | no | identifiers of single accounts, at most 500 | Only these accounts — this is how the send icon in a row works. Accounts that are not Invited stay untouched. |
The response states sent, skipped (a valid invitation already existed) and remaining (above the limit of 200 per run — run again).
Open invitations
| Item | Field | What it means |
|---|---|---|
email | Who the invitation went to. | |
| Customer | customerId, customerName | For which customer the account is to be created. Via the API, customerId narrows the list to one customer. |
| Brand | brandId | The invitation's brand — it decides who sees and handles it. |
| Status | status, expired | pending = sent, not yet accepted; expired (yes) = the link has expired, Resend helps. |
| Valid until | expiresAt | Until when the link works. |
| Sent on | createdAt | When the invitation was created. |
| Identifier | ulid | For Resend (POST …/invitations/{ulid}/resend) and Revoke (DELETE …/invitations/{ulid}). |
The list itself shows email, name, the related customer, status (invited, active, suspended), the last sign-in and a summary of the granted permissions. As long as an invitation is unredeemed, the access stays invited.
A portal access is not a staff account. It lives in a separate realm with its own sign-in and its own permissions; it cannot reach the back office, not even with the same address. And it sees nothing you have not explicitly released.
Settings & permissions
- Permission
portal.user.invite. Without it the page is unreachable. - **Granting permissions needs
portal.access.grant, suspending and reactivating needs
portal.user.suspend.** Seeing the page therefore does not yet mean being allowed to do everything on it.
- Rights are object-bound, not role-based as in the internal area. There are no portal roles;
there are releases onto specific customers, projects and contracts.
- Files need their own release. Seeing a customer in the portal does not make that customer's
documents visible — each file carries its own portal marker for that, see Documents.
- Access templates are visible to everyone with
portal.user.inviteorportal.access.grant;
creating, changing and deleting needs portal.access.grant, and only in the brands where you hold it.
- Group enablements need
portal.access.grantand a company hierarchy on the customer. Without a
group link no other customer can be chosen; portal users see in a group customer only what is enabled there; write actions and downloads there are recorded in the portal log, page views are not.
- No access without an invitation. A contact record never creates access by itself.
- Two-factor requirement for finance rights. The switch at the top of the page (setting
portal.mfa.finance_required, permission platform.settings.manage) requires set-up two-factor sign-in for viewing invoices and approving quotes. Accesses without it are not locked out: they sign in, are led to the setup, and until then exactly these two rights have no effect. Default: off.
FAQ & troubleshooting
The invited person sees nothing. Check the rights granted. Access without a release onto a customer, project or contract is valid but shows nothing — the list reports that as No rights.
A customer cannot see a document. The document is not released to the portal. Portal rights and file release are two separate decisions.
The invitation does not arrive. Check the spam folder and the mail dispatch. The status stays at Invited until it is taken up.
The email names a different company than expected. The customer has no brand. The email then names the company from the system settings (system.company_name), without it the only or the default brand. Assign a brand to the customer or maintain the company name.
The customer deleted the invitation or it has expired. Under Open invitations, click Resend — the new link is valid for 7 days again, the old one no longer.
Taken-over accounts did not receive an email. That is intended: the import sends nothing. Trigger Send invitations when the customers should be invited.
**The Customer field is missing in the permissions dialog.** The customer of the access does not belong to a group. Link the companies on the customer as parent and subsidiary first; then the group customers can be chosen.
A changed access template has no effect on existing accesses. That is intended: the template only pre-fills. Change existing rights on the access via grant permissions.
Can a portal account reach the internal application? No. The two sign-in areas are separate; there is no crossing.