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.
Which Tool to Choose
| Tool | When to use | Where it's configured |
|---|---|---|
| Task rule | Event in a task + condition → action (assign, change a field, create a subtask) | Task rules |
| CRM robot | Event in a CRM deal + condition → action (assign, move to a stage, send an email) | CRM robots |
| Operation guard | You need to stop an operation from running until a condition is met | Operation guards |
| Workflow | A multi-step scenario with conditions, waits, and manual tasks for people | Workflows |
| Recurring task | Repeating work on a schedule (week, day of the month) | Recurring tasks |
| Template and checklist | Standardize a one-off recurring job without a schedule | Task Templates and Automation |
If you are unsure whether to use a rule or a workflow, a rule fits a single action for a single event, while a workflow fits several steps where part of them are performed by people.
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
Automation center: all rules, recurring scenarios and processes in one table.
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.
The summary shows the total automations, active rules, workflows, and records available only in read-only mode. Search and module, type, and status filters help build a focused view. The Create menu offers only types (task rule, CRM rule, operation guard, or workflow) that your permissions allow; an unavailable type is disabled. A Manage row is different from a Read-only row. No matches after a successful filter are not a loading error: a source failure or unavailable source has its own state and retry path.
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.
How to Enable a Rule Safely
Treat a new rule as a management pilot, not an instant company-wide change. Start with a small scope: one department, project, pipeline, task type, or user group.
Before activation, define:
- which result the rule should create;
- who owns the process and who can stop the rule;
- which objects are included;
- which message users will see if an action is blocked;
- how the first runs and skipped cases will be reviewed.
After launch, review the first results with the process owner. If the rule creates extra tasks, changes the wrong assignees, or blocks valid work, stop it and fix the scope before expanding.
What to Do When Rules Conflict
A conflict appears when several rules change the same object or set different expectations for the user. For example, one rule moves a task to review, another immediately changes the assignee, and an operation guard requires a file that should not be ready yet.
Resolve the conflict in this order:
- Find the exact object where the behavior was unclear.
- Check the change history, automation log, and active operation guards.
- Decide which rule should be primary for the business process.
- Disable the duplicate or outdated rule.
- Update the name, description, or message so the next user understands the reason.
If both rules are still needed, split their scope by department, stage, task type, pipeline, client process, or participant role.
Pause and Rollback
Automation should be paused not only for technical errors. Stop or narrow a rule when the team no longer understands why a status, deadline, assignee, or access level is changing.
Before rollback, keep an operational trace:
- which rule was changed;
- which objects were already affected;
- what needs manual correction;
- who should be warned about the temporary pause;
- when the process owner will review the setting again.
Do not leave paused rules without an owner. If a rule no longer supports the current process, disable it and describe the new work order.
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.
Automation is the upper steps of delegation: first the work becomes a task with acceptance and a template, then a schedule and a process. Which tool to choose and when is covered in the Delegation Ladder.
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.
Business Scenarios
- Automating recurring tasks
- Bring order to your work
- The business grew — and control slipped away
- All scenarios
Related Sections
Conceptual guidance, not a UI screenshot or state evidence.