Automation and Portal Settings
Automation in LadVen OS helps manage repeatable actions across tasks, CRM, and workflows. Portal settings define the boundaries: who can create rules, which actions are allowed, which guards stop unsafe transitions, and where administrators control risk.
Use this page as the governance map for automation. Task automation and workflows have dedicated pages; this page explains how to run automation safely.
Where to Find It
Main entry points:
- Automation (
/automation) - summary of task rules, CRM rules, workflows, and operation guards; - Operation Guards (
/automation/operation-guards) - rules that block transitions or actions when conditions are not met; - Portal Settings (
/portal-settings) - module settings, permissions, access policies, security, documents, files, and workspaces; - Task Technical Settings (
/portal-settings-tech) - advanced task and automation settings for administrators.
Available blocks depend on role and permissions. If an action is not visible, check both the page and the scope: company, project, pipeline, stage, or module.
Automation Hub
The automation hub shows which rules and processes exist, where they are active, and who can manage them. Use it to understand what affects tasks, CRM, and workflows.
Before changing a rule, check:
- module and scope;
- status: active or disabled;
- last run or update time;
- owner of the change;
- overlap with another rule or workflow.
Do not enable a rule unless the expected business result and owner are clear.
Operation Guards
An operation guard stops an action when the object is not ready: for example, a required field is missing, the status is wrong, or a transition requires another condition. It is a process safety control, not a punishment for the user.
A good guard explains what the user must fix. The message should be short and avoid technical codes or internal terms.
Use operation guards for:
- required data before closing a task or opportunity;
- status transition control;
- links between tasks and CRM;
- protection from incomplete object creation;
- consistent rules across teams and pipelines.
Permissions and Policies
Automation should be available to people responsible for the process. Regular users may run or view allowed scenarios, while rule and policy management should stay with process owners and administrators.
Before granting access, check:
- whether the user needs view, run, or manage access;
- which module the permission belongs to;
- whether it applies company-wide or only in a project, pipeline, stage, or workspace;
- who will review changes after activation.
Do not grant broad administrator rights for a single rule. Configure a precise policy instead.
Portal Settings
Portal settings affect module behavior: tasks, CRM, chat, AI, documents, files, security, and workspaces. Treat them as working policy, not as one-off technical changes.
Before changing a setting, answer:
- who will be affected;
- how the team will learn the new work order;
- how quickly the rule can be stopped or reverted if the result is wrong.
After a change, test a typical scenario on a safe object and confirm that users see clear messages.
Good Practices
- Enable automation in a limited scope first, then expand.
- Name rules by business meaning, not by internal action.
- Keep guard messages understandable for users.
- Check rule conflicts before publishing.
- Disable obsolete rules so they no longer influence the process.
- Use only prepared demo data and localized UI for screenshots.