Automation hub
The automation hub is a single screen where you see all portal automation in one place: task rules, CRM robots, recurring templates, operation guards, and business processes. Without it, automation spreads across modules, and a leader cannot tell what is turned on, who is responsible for it, and when it last ran.
The hub opens at /automation. It is the workspace of the process owner and the department lead.
If a manual-task, instance, or rule card shows a technical ID instead of a name, status, or linked object, this is a display defect. Check the human title, status, assignee, and source; do not treat the raw ID as a working name or include the card in shared docs or screenshots. Send the screen to an administrator.
A single automation list: name, module, type, status and owner of every rule.
Why the hub matters
Why the hub matters — conceptual flow, not a UI screenshot or evidence.
Automation in LadVen OS lives in several engines: task rules, CRM robots, and business processes, plus shared operation guards. The automation hub brings them into a single list so you can manage your automation portfolio instead of hunting for each rule inside its own module.
Use the hub as a control point: it is the convenient place to start — see what is turned on, who the owner is, and what has not run in a long time, then move into the right editor.
What the hub shows
What the hub shows — conceptual flow, not a UI screenshot or evidence.
The hub gathers every automation type into a single table with shared columns:
- automation name;
- module — tasks, CRM, or workflow; an operation guard appears under the module of its operation;
- type — task rule, recurring task, CRM robot, operation guard, business process;
- scope — company, pipeline, stage, project;
- state — enabled, disabled, read-only;
- who changed it and when;
- last run;
- jump into the right editor.
At the top you see a short summary: how many automations there are in total, how many are active, how many processes there are, and how many are available to you as read-only.
Filters and search
Filters and search — conceptual flow, not a UI screenshot or evidence.
To avoid drowning in the full list, use the filters:
- search by name;
- filter by module (tasks, CRM, workflow);
- filter by automation type;
- filter by state (enabled, disabled).
This makes it easy to build a working slice: "all active CRM robots", "disabled task rules", "processes with no recent runs".
Creating automation
Creating automation — conceptual flow, not a UI screenshot or evidence.
From the hub you can create automation of any type through the single "Create" menu: a task rule, a CRM robot, an operation guard, or a business process. Each item leads into its own editor and is available based on permissions — if your role has no rights to create any type, the button is disabled.
You should create automation from a described process, not from the button: first understand which repeatable step needs to be standardized, and only then choose the tool.
Read-only and ownership
Read-only and ownership — conceptual flow, not a UI screenshot or evidence.
Some automations are visible but not editable — marked as "read-only" if you do not have management rights in their scope. This is normal: automation is configured by whoever has rights to the relevant module, pipeline, or project.
Every important rule, process, and guard should have an owner. The "who changed it" column helps you understand whom to ask, rather than changing someone else's automation blindly.
States you may see
States you may see — conceptual flow, not a UI screenshot or evidence.
- the list is loading;
- some sources are unavailable based on permissions, so the list does not show everything (partial list);
- no results for the selected filter;
- a row is marked "management" or "read-only";
- the create button is disabled if the role has no rights to any type.
Good practices
Good practices — conceptual flow, not a UI screenshot or evidence.
- Start automation control from the hub, not from individual modules.
- Regularly check what is turned on, who the owner is, and what has not run in a long time.
- Disable unused and duplicate rules.
- Create automation from a described process, not for the sake of the button.
- Respect "read-only": request access instead of working around the limit.
Common mistakes
Common mistakes — conceptual flow, not a UI screenshot or evidence.
Configuring automation per module and losing the overall picture. Without the hub, duplicates and forgotten rules pile up unnoticed.
Leaving rules without an owner. When automation misbehaves, it is unclear whom to ask.
Treating a partial list as complete. If some sources are hidden by permissions, the hub does not show everything — that does not mean there are no other automations.
Breeding similar rules. The more alike rules there are, the harder it is to tell which one fired.
How to verify the result
How to verify the result — conceptual flow, not a UI screenshot or evidence.
- the hub shows every automation available to you, with its state and owner;
- a filter builds the slice you need (active, by module, by type);
- unused rules are disabled, and important ones have an owner;
- a jump from a row opens the correct editor.
Section pages
Section pages — conceptual flow, not a UI screenshot or evidence.
Automation is documented surface by surface — open the one you need from the hub:
- Task rules — event → conditions → action;
- Recurring tasks — template and schedule;
- CRM robots — action chain triggered by a commercial opportunity or service-request event;
- Operation guards — block an operation until a condition is met;
- Message templates — email drafts with variables;
- Workflows — multi-step scenarios with manual tasks;
- Workflow instances — monitoring running workflows;
- Manual workflow tasks — steps handed to people;
- Run history and troubleshooting — why a run did or did not fire;
- Automation permissions and scope — who can configure and run what.
On /automation/agreement-renewal, you can turn agreement-renewal reminders on or off, choose an employee, and review the task name. If no setting exists yet, the current employee is prefilled; the portal watches agreement end dates and creates a task as the end approaches. Multiple identical settings can create multiple tasks, so keep one. Use Retry for loading or save errors and ask an administrator when access is denied; this screen has no lead-time/date setting or archive action.
The settings screen alone does not prove that a task was created or that the scheduler ran. Check the result separately after enabling the reminder and its condition occurs; do not treat an open setting as proof of a run.
Related scenarios
Related scenarios — conceptual flow, not a UI screenshot or evidence.