Portal administration
Portal administration is the set of settings that define how the whole company works in LadVen OS: module rules, access, email, and sign-in. They are changed by the owner or administrator; this requires administrative rights.
This page is an overview of what you can configure. The access model is described in detail in the Access and roles section, and the second sign-in factor in the Two-factor authentication section.
Module rules
The administrator sets rules by module — how the portal behaves by default for everyone:
- Tasks — rules for distributing work (whether tasks can be assigned downward, upward, or across departments), the automation mode for regular employees, and default requirements (result review, preliminary estimate).
- CRM — the default access mode (strict or open) and role rights to client data.
- Chats — who is allowed to have private conversations: active employees, colleagues from their own or a related department, only within a project, or nobody (
deny_by_default). - AI — whether the module is enabled and who can use AI connections.
- Documents and files — rules for working with the company's documents and files.
Change a module rule as a company-wide policy, not for a single situation: it affects all users at once.
Workspaces
Workspaces separate large perimeters inside the portal. For each one you can set members and their roles, as well as the rule enforcement mode: off (off), staged (staged), or strict (strict). Staged mode leaves reads unrestricted while workspace boundaries govern write and manage actions; strict mode blocks violations. Start with staged, review the impact, and then enable strict when needed.
Security
In the security section the administrator sets:
- the default access mode for modules (see Access and roles);
- department visibility —
all(the whole structure) orself_chain(the employee's own branch); - the two-factor authentication policy, separately for employees and external participants:
off,optional,required_for_admins, orrequired_for_all(see Two-factor authentication).
Access policies open in Portal Settings (/portal-settings?tab=policies). The older /access-policies and /admin/access links redirect there.
The global mode is the fallback for modules. CRM, tasks, workflows, chat, and AI can keep that value or use their own Strict/Open mode; when a module value is absent, the global value applies. If any mode is Open, the portal shows a risk warning before saving. Check the resulting module mode, then narrow it with an explicit access policy where needed.
System email
System email is how the portal sends messages (notifications, invitations, process emails). The administrator configures sending profiles, templates, and email subjects, and monitors delivery. Correctly configured system email is needed so that invitations and notifications reach employees and clients.
Open the general center at /portal-settings; the dedicated sending page is /portal-settings/system-email.
While capability data is loading, the status may briefly be “Checking email channel”; this is not an outage. Trust Active or Unavailable and its reason only after the check finishes.
A test email is not considered sent immediately after you click. Use a synthetic recipient and run tests only in a test environment: “Queued” and “Waiting for sender” mean the worker has not processed it yet, “Sent” is a confirmed outcome, and “Not sent” gives the rejection reason. If the queue worker is off, the message will not leave the queue; “Still queued” is not a failure—wait for a delivery-log entry or stop waiting and check again later. An empty or invalid recipient is rejected before queueing.
If more than one profile occupies the same scope + purpose slot, the portal rejects the save: an administrator must choose the profile to keep and consolidate or remove duplicates. Retrying is not available for every delivery: with an active lease, wait for the current outcome; after a conflict, refresh the page; when a record is not retryable, check the delivery log first. Use synthetic addresses and content only; never put real customer recipients or messages into tests, screenshots, or instructions.
Custom fields
The administrator can add extra fields to employee profiles — for example, a free-form job title, an internal identifier, or a start date. Different types are supported: text, number, date, a list of values, a reference to a user or department; a field can be made required or multiple.
Before creating fields en masse, agree on why each one is needed and who fills it in: where exactly a field is shown to employees depends on the portal configuration, so introduce fields deliberately rather than in reserve.
Create and order fields on the administrative /custom-fields page; where a filled field appears can still depend on portal configuration.
Corporate sign-in (SSO)
LadVen OS supports sign-in through an external identity provider (corporate SSO). Some deployments expose a Single sign-on (OIDC) connector in CRM → Integrations; others still require the portal provider to enable it. Availability and fields depend on the deployment, so follow Single sign-on (OIDC) and confirm the flow with the portal owner.
Good practices
- Change module rules as a company-wide policy, thinking through the impact on everyone in advance.
- For sensitive modules keep the strict default access mode.
- Set up and test system email before mass invitations and process launches.
- Introduce custom fields for a specific need, not in reserve.
- Accompany policy and rule changes with a clear reason — it stays in the history.
Common mistakes
- Changing a module rule for one case, forgetting that it applies to everyone.
- Leaving an open access mode where there is client or financial data.
- Sending invitations before setting up system email — the messages do not arrive.
- Creating custom fields with no purpose, and the profile turns into a dumping ground.
- Assuming every deployment configures SSO the same way — first check whether the OIDC connector is present.
Related sections