A new lead. A clear next step.
Use an automation for a repeatable CRM action triggered by an event. Our example assigns a new, unowned lead to Dana and creates a task due 24 hours later. All records in this lesson are isolated demonstration data.

Choose when to start, what to check and what to do. Then inspect the result.
A 6-minute video in 24 chapters. Jump directly to the step you need.
One rule assigns a lead and creates a follow-up task. Your team knows who takes it and when.
The video is currently unavailable. You can continue with the written steps and demonstration below.
A new lead. A clear next step. One rule assigns a lead and creates a follow-up task. Your team knows who takes it and when. Real Lynxbe screens · Demonstration data
Open CRM Automations Open the system menu, go to CRM and choose Automations. Real Lynxbe screens · Demonstration data
Choose the board Create a rule and choose the leads board where it should run. Real Lynxbe screens · Demonstration data
Give the rule a clear name Describe what it will do. The automatic identifier field can be left empty. Real Lynxbe screens · Demonstration data
Set the starting event Choose Item created. The rule is checked when a new item is created on the selected board. Real Lynxbe screens · Demonstration data
Continue only without an owner Add a condition: Owner is empty. A lead already assigned will keep its owner. Real Lynxbe screens · Demonstration data
Add owner assignment For the first action, choose Assign owner and direct assignment. Real Lynxbe screens · Demonstration data
Choose who takes the lead Select Dana from the sales team. The rule will assign the new lead to her. Real Lynxbe screens · Demonstration data
Add the next step Add a second action: Create a task. Place it after owner assignment. Real Lynxbe screens · Demonstration data
Use a title that updates Enter Call {{item.name}}. The lead name will appear in the task title when the rule runs. Real Lynxbe screens · Demonstration data
Set when to follow up Set the task due time to 24 hours and choose Normal priority. Real Lynxbe screens · Demonstration data
Assign the task too Select Dana as the follow-up task assignee too. Check that a different person was not selected. Real Lynxbe screens · Demonstration data
Read the complete rule Check the board, event, condition and both actions: assign to Dana, then create her task due in 24 hours. Real Lynxbe screens · Demonstration data
Save and check the state Save the rule and check that it is active in the list. This creation flow enables the rule when saved. Isolated demo data · No live customer changes
Pause while preparing Turn the rule off and check the changed state. Test the settings before enabling it for your workflow. Isolated demo data · No live customer changes
Test without performing actions Run Test from the rule list and read the simulation result. Real Lynxbe screens · Demonstration data
A predicted result is a start Check that the condition matches and both actions are described. An actual run still needs review. Real Lynxbe screens · Demonstration data
Enable when ready Enable the rule after checking its settings. Confirm that it is active. Isolated demo data · No live customer changes
A new lead reaches the board A new, unowned lead is created on the selected board. This matches the event and condition we set. Real Lynxbe screens · Demonstration data
Check who received the lead Open the lead and check Owner. Dana’s user ID is 7 in this example. Isolated demo data · No live customer changes
Check the follow-up task In the follow-up center, check the task title, Normal priority and the due time 24 hours later. Isolated demo data · No live customer changes
Check the run too Open the rule and its run history. Read the status and action results. Isolated demo data · No live customer changes
When an owner is already set A new lead arriving with an owner does not meet the condition. This run skips the actions. Isolated demo data · No live customer changes
Keep the rule aligned with your team When the team or process changes, pause, update and test before enabling again. Isolated demo data · No live customer changes
Original Lynxbe screens use isolated demonstration data. Check the owner, task and runs; your customers are unchanged and no messages are sent.
Before starting: access to the page and required actions, a leads board and the right teammate. Decide who takes a lead and when to follow up.
Use an automation for a repeatable CRM action triggered by an event. Our example assigns a new, unowned lead to Dana and creates a task due 24 hours later. All records in this lesson are isolated demonstration data.
The page lists your rules and their activation states. You can open a rule, test it and inspect runs. Available entry points and actions depend on your permissions and business capabilities.
The board determines which items the rule belongs to. Choose the board receiving the relevant leads and check it before continuing. This lesson uses an isolated Leads board.
A clear name helps identify the rule in the list and when investigating a problem. For example: New lead — assignment and follow-up. Leaving Identifier (auto) empty generates an identifier when saved; our screenshot uses a chosen identifier. The name does not replace the trigger, condition and action settings.
A trigger is the event that starts checking a rule. This example uses item.created. It does not automatically scan every old lead or restart just because an existing lead was edited.
A condition determines whether the actions should run after the event. Choose owner_id and is_empty. This comparison needs no value. A new lead arriving with an owner does not meet this condition.
An action describes the change to make when the conditions match. Our example assigns to a specific person, so it uses direct assignment. Check the setting itself, not only the action name.
Choose a teammate who should handle leads from this board. Dana is explicitly selected in this example. When the responsible person changes, update both the assignment and follow-up action before enabling the rule.
Actions have an execution order. First assign the lead, then create a task describing the next step. These are internal CRM actions in this example; no customer message is sent.
The title is what the teammate sees on the task. {{item.name}} is replaced with the name of the item that triggered the rule. Keep the braces and variable name intact, and use a title describing a clear action.
The example task is due 24 hours after its creation during action execution. This is a task deadline, not a promise of an automatic call. Choose a due time and priority that fit your workflow.
Lead ownership and task assignment are separate settings. This example explicitly selects the same teammate in both actions. Before saving, check who will receive the task; the action name alone does not establish its assignee.
Review the settings together. Check that there is no unwanted extra action, that the task has the right assignee and that the due time is 24 hours. Our example uses Normal priority and a title containing the lead name.
Do not assume saving creates an inactive draft. The current creation form saves a new rule as active. Check its state immediately and pause it during preparation if it should not yet handle new events.
A paused rule does not perform its actions for a new event. Pausing does not delete earlier tasks or reverse an owner assignment already made. Use it to control future actions while preparing.
Rule testing shows how the conditions and actions are evaluated against the sample selected for the test. Read the shown sample and result. Testing is a simulation; it does not create the follow-up task or actually assign a lead.
A suitable test result helps check the configuration. It is not evidence of a saved task or changed lead owner. After enabling the rule and a matching event, inspect the lead, task and run history.
An active rule handles future events matching its board and trigger. Enabling it does not rerun it over every existing lead. Next, our isolated demonstration creates a new lead and checks the result.
The example lead is named Website request and has no owner. Item creation matches the trigger and the condition passes. Next, inspect the engine results in the isolated records, rather than relying on the simulation.
The item screen displays a user ID in its Owner field. Here 7 corresponds to Dana selected in the teammate picker. Check the correct lead and that its owner ID matches the selection. These are isolated demonstration records; your customer records are unchanged.
Check that the title uses the right lead name and the due time was saved. We explicitly selected Dana as assignee in the creator; this task card does not show her name. An active rule alone does not prove a task exists. The demonstration task was created by the rule and checked alongside the lead and run.
Run history connects the event with what happened. Review the relevant run and both actions alongside the lead and task themselves. If an action failed, inspect the current records before trying again; a test message does not replace a saved result.
In the second example, a new lead already has an owner. The engine skips the actions: ownership is retained and this rule creates no additional task. A condition-based skip is an expected outcome, not necessarily a fault.
Review the rule when the teammate, board or follow-up time changes. Check both lead ownership and task assignment. Our example ends paused; choose the activation state for your ready workflow and inspect its first runs.
Check three things: the lead owner, a task with the correct assignee and due time, and a run explaining the actions. A simulation alone does not prove execution.
Pause and update the rule when the team or process changes. When a run reports a failure, inspect the records before trying again.
Checked against Lynxbe screens and source behavior on 11 October 2026. Creation saves an active rule; rule testing is a simulation. The lesson actions and runs use isolated records.
A read-only walkthrough. Choose a step or use Next. It does not enable a rule in an active business or change your leads.
Use an automation for a repeatable CRM action triggered by an event. Our example assigns a new, unowned lead to Dana and creates a task due 24 hours later. All records in this lesson are isolated demonstration data.

The page lists your rules and their activation states. You can open a rule, test it and inspect runs. Available entry points and actions depend on your permissions and business capabilities.

The board determines which items the rule belongs to. Choose the board receiving the relevant leads and check it before continuing. This lesson uses an isolated Leads board.

A clear name helps identify the rule in the list and when investigating a problem. For example: New lead — assignment and follow-up. Leaving Identifier (auto) empty generates an identifier when saved; our screenshot uses a chosen identifier. The name does not replace the trigger, condition and action settings.

A trigger is the event that starts checking a rule. This example uses item.created. It does not automatically scan every old lead or restart just because an existing lead was edited.

A condition determines whether the actions should run after the event. Choose owner_id and is_empty. This comparison needs no value. A new lead arriving with an owner does not meet this condition.

An action describes the change to make when the conditions match. Our example assigns to a specific person, so it uses direct assignment. Check the setting itself, not only the action name.

Choose a teammate who should handle leads from this board. Dana is explicitly selected in this example. When the responsible person changes, update both the assignment and follow-up action before enabling the rule.

Actions have an execution order. First assign the lead, then create a task describing the next step. These are internal CRM actions in this example; no customer message is sent.

The title is what the teammate sees on the task. {{item.name}} is replaced with the name of the item that triggered the rule. Keep the braces and variable name intact, and use a title describing a clear action.

The example task is due 24 hours after its creation during action execution. This is a task deadline, not a promise of an automatic call. Choose a due time and priority that fit your workflow.

Lead ownership and task assignment are separate settings. This example explicitly selects the same teammate in both actions. Before saving, check who will receive the task; the action name alone does not establish its assignee.

Review the settings together. Check that there is no unwanted extra action, that the task has the right assignee and that the due time is 24 hours. Our example uses Normal priority and a title containing the lead name.

Do not assume saving creates an inactive draft. The current creation form saves a new rule as active. Check its state immediately and pause it during preparation if it should not yet handle new events.

A paused rule does not perform its actions for a new event. Pausing does not delete earlier tasks or reverse an owner assignment already made. Use it to control future actions while preparing.

Rule testing shows how the conditions and actions are evaluated against the sample selected for the test. Read the shown sample and result. Testing is a simulation; it does not create the follow-up task or actually assign a lead.

A suitable test result helps check the configuration. It is not evidence of a saved task or changed lead owner. After enabling the rule and a matching event, inspect the lead, task and run history.

An active rule handles future events matching its board and trigger. Enabling it does not rerun it over every existing lead. Next, our isolated demonstration creates a new lead and checks the result.

The example lead is named Website request and has no owner. Item creation matches the trigger and the condition passes. Next, inspect the engine results in the isolated records, rather than relying on the simulation.

The item screen displays a user ID in its Owner field. Here 7 corresponds to Dana selected in the teammate picker. Check the correct lead and that its owner ID matches the selection. These are isolated demonstration records; your customer records are unchanged.

Check that the title uses the right lead name and the due time was saved. We explicitly selected Dana as assignee in the creator; this task card does not show her name. An active rule alone does not prove a task exists. The demonstration task was created by the rule and checked alongside the lead and run.

Run history connects the event with what happened. Review the relevant run and both actions alongside the lead and task themselves. If an action failed, inspect the current records before trying again; a test message does not replace a saved result.

In the second example, a new lead already has an owner. The engine skips the actions: ownership is retained and this rule creates no additional task. A condition-based skip is an expected outcome, not necessarily a fault.

Review the rule when the teammate, board or follow-up time changes. Check both lead ownership and task assignment. Our example ends paused; choose the activation state for your ready workflow and inspect its first runs.
