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.
Survey what exists. The list shows email, name, owning customer, status, last sign-in and a summary of the rights. The three statuses are Invited, Active and Suspended.
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
Three masks, three resources: the invitation, the permission grant and the status switch. 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. |
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 | Which project, which contract. With customer the field stays empty — the row then covers the whole customer. With project and contract the mask demands a choice. |
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 | 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. |
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. |
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.
- No access without an invitation. A contact record never creates access by itself.
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.
Can a portal account reach the internal application? No. The two sign-in areas are separate; there is no crossing.