Portal settings and automation admin center
Use Portal settings (/portal-settings) to configure module behavior, default
security rules, MFA, workspaces, and access-policy links. The tabs
/portal-settings?tab=policies and /portal-settings/system-email open local
policies and the system-mail channel status. Older links to the policy page redirect
to this section.
While /portal-settings/system-email is checking the channel, the loading state is
normal and is not an error; wait for the result or retry before treating it as a failure.
Use the technical center (/portal-settings-tech) to inspect effective automation
rights, run a non-mutating rights check, manage scoped kill switches, and
review chat policy. It is an admin diagnostic surface, not a replacement for the
automation hub, rule editor, or workflow pages.
Safe change sequence
- Record the owner and reason for the change, especially for CRM permissions.
- Read the current value and confirm its scope: company, department, project, pipeline, stage, or user.
- Change one related group at a time and test with a synthetic record and role.
- Re-read effective access after saving. A missing tab or button means that the current account lacks read/manage rights; it does not prove that a setting is off.
/portal-settings
The access-control center has General, Access rights and local rules, and System email sections. General module tabs are shown according to the current account: Security, Tasks, CRM, Chat, AI, Documents, Files, and Workspaces.
Module tabs and workspace scope
| Tab | User-facing controls | Safe verification |
|---|---|---|
| Security | fallback behavior for global/CRM/tasks/workflows/chat/AI and staff/extranet MFA | test a role where no local rule exists |
| Tasks | hierarchy, up/down/sideways assignment, extended time planning, review and preliminary-estimate defaults, non-admin automation mode | create a test task and verify visibility and assignment |
| CRM | company role level: default, none, read, write, or manage; deal visibility is separate: all deals in the pipeline, own and subordinates, own only, or none | open test deals owned by you, a subordinate, and another employee; when rules overlap, verify that the strictest rule wins |
| Chat | direct-member policy plus links to channel and outbound operations settings | verify that only the intended chat context is readable |
| AI | module availability and links to Assistant capabilities | run a no-write prompt, then check effective capabilities |
| Documents / Files | module and file-governance controls | test copy, download, and delete boundaries |
| Workspaces | enforcement mode and workspace membership | test off, staged, and strict with a non-admin user |
Workspaces
The workspace modes are off (no access effect), staged (limits write/manage,
not read), and strict (limits read/write/manage). Configure a workspace, then add
members as viewer, member, admin, or owner; add a backup administrator before
using strict.
For the Files tab, also choose a governance profile: simplified for small teams with minimal overhead, managed for a regular lifecycle, or strict for regulated operations. Separate controls allow direct delete, force-delete of linked files, and a reason requirement in the pending-delete or final-cleanup flow. These switches change destructive boundaries, not viewing rights; compare them with the file lifecycle before saving.
Task assignment restrictions
In the assignment block you can allow work to move between departments and choose whether the scope is related departments or the same department only. Only these departments opens a searchable list of human-readable department names. Select departments there; a previously saved department that no longer resolves remains separately marked unavailable so the restriction is not silently dropped. That marker does not mean assignment is allowed, and you do not need to enter a technical identifier. Set the target role separately: any user, a head, or an employee.
Below that, search employees and mark Who may be assigned and Who may not be assigned. An empty employee list is a distinct state, not permission for everyone. When values are inherited from a parent policy, these controls are read-only. After saving, re-read effective access and test with a synthetic task.
The same card separates planning For themselves from For other people. A person plans their own work themselves applies when the person is an assignee or co-executor; changing it does not change a task due date. Scope and target role for other people are separate controls. Allow userIds and Deny userIds are still text lists of identifiers, not name-based employee pickers: do not put real IDs in demonstrations and do not treat an empty list as permission for everyone. Saving requires task-settings manage permission; re-read effective access afterward.
Fallback and MFA
When no local policy matches, strict denies the action until it is explicitly allowed; open permits read/write by default and is risky for production. The fallback can be global or module-specific. Staff and extranet MFA can be off, optional, required for admins, or required for everyone. Test login and step-up behavior after changing MFA, and do not overwrite an existing legacy policy while saving unrelated settings.
AI connection access
The AI tab separately enables the module and lists available connections. For a
connection in policy mode, grant access to the admin, head, and employee
roles; this is a company-level grant and does not replace the separate Assistant
rights for replies and actions in local policies. In module-based access,
mode, access follows the module mode and role checkboxes are not editable. No
connections is a valid empty state: configure one in AI connections
without exposing keys. Re-check the effective right and a safe no-write prompt.
CRM voice-communication policy.
The CRM tab has a separate voice-communication policy. Contact record required permits a call only when the contact has its own eligibility record; Law permits by default makes contacts without a record callable and requires a named legal basis. The portal warns about the scope of that mode but does not promise a contact count. Changing it requires manage permission; without it, values are read-only. On load or save failure, reread or retry instead of enabling the mode blindly. Use only synthetic Demo Client North and Anna Test Employee for review, with no save, PII, telephony, or real call.
Local access policies
The policy tab layers a rule for a role or subject over the global setting. Choose the module and scope, save a clear reason, and then inspect effective access. A narrower department/project/pipeline/stage/user rule can override a company rule. For Assistant, check the reply and action rights separately: having AI enabled does not grant CRM write actions.
/portal-settings-tech
The technical center provides:
- a rights matrix with search, denied-only filtering, and groups by action type;
- a scoped rights check (diagnostic only; it does not grant a right);
- scoped automation kill switches for company, project, pipeline, stage, or user;
- direct-chat policy review;
- a privileged diagnostic console. Never paste tokens, personal data, or real mutation commands into it.
The Assistant rights check opened from AI Hub shows the same information. Use an allow/deny result only for the displayed scope and current deployment.
Recovery and acceptance
- If access is denied, request the required read/manage permission; do not bypass it with a different address.
- For partial loading, re-read all modules before accepting a change.
- For a conflict, compare the current value and change reason instead of blindly overwriting another admin.
- If a kill switch is active, stop the risky run, fix the rule, and remove the switch in a separate reviewed action.
Verification
The change is ready when the intended right is effective, the allowed scenario works, the denied scenario is blocked with a useful message, out-of-scope roles did not gain access, and owner/reason/time/result are recorded.
Related pages
Conceptual guidance, not a UI screenshot or state evidence.