How to Set Up Your First Automation in Senitix CRM

Building your first Senitix CRM automation takes five steps: pick a trigger, add a condition, add an action, test it on a small group of deals, then turn it on for everyone. This guide builds one rule end to end (opening a dated task the moment a deal reaches a stage), then shows two ways to extend it once the first one is proven.

What you need before you build your first rule

Before you look for the automation builder in settings, confirm your workspace includes automations; plan details are on the pricing page. Beyond that, you need three things already in place: a pipeline with the stage you want to trigger on, at least one test deal you can safely move without affecting real reporting, and a clear idea of who the created task should go to. Skipping that last point is the most common reason a first rule gets built and then ignored: a task with no obvious owner is a task nobody checks.

This walkthrough uses the same trigger, condition and action model described on our features page. If you want the underlying anatomy of a rule before building one (what a trigger, a condition, a wait and a branch each are), our guide to CRM workflow automation covers that in full; this post assumes you know the parts and walks through building one rule with them.

The rule we’re building: a task the moment a deal reaches a stage

Picture a twelve-rep B2B SaaS sales team in Omaha, Nebraska, running one pipeline with six stages. Deals stall most often right after “Negotiation”: a rep sends final pricing, the prospect goes quiet, and nobody circles back until the deal is already cold. The fix isn’t a bigger pipeline review; it’s a task that appears automatically the moment a deal enters that stage, so follow-up doesn’t depend on a rep remembering.

The rule: when a deal’s stage changes to Negotiation, create a task for the deal owner, due two business days later, titled with the deal’s name. Nothing about the deal itself changes; the rule only makes sure a follow-up exists.

Step-by-step: build the rule

Each step below has one owner and one output, so you can tell exactly when the rule is ready to test.

1. Open Automations and start a new rule. Owner: whoever has automation access, usually an admin or sales manager. Output: an empty rule ready for a trigger.
2. Choose the trigger: deal stage changed. Set the target stage to Negotiation, on the pipeline the team actually uses. Owner: builder. Output: the rule now listens for exactly one stage move, on one pipeline.
3. Add a condition if more than one pipeline shares this trigger. Scope the rule to the specific pipeline so it doesn’t fire on deals in an unrelated process. Owner: builder. Output: the rule reacts only to the deals it was built for.
4. Add the action: create an activity. Set the type to Task, assign it to the deal’s owner (not a fixed person: the owner changes deal to deal), set the due date two days out, and give it a plain title like “Follow up: [deal name], Negotiation.” Owner: builder. Output: a dated, owned task appears on the deal the instant it enters the stage.
5. Name the rule clearly and save it. Something like “Task on entering Negotiation,” specific enough that another admin reading the rule list in six months knows what it does without opening it. Owner: builder. Output: a named rule any admin can find and audit later.

Test the rule before turning it on

A rule that has never touched a real deal is still a guess. Before it runs for the whole team:

• Move one real (or clearly marked test) deal into Negotiation by hand and confirm the task appears: right owner, right due date, right title.
• Check a deal that stays in a different stage and confirm nothing happened to it; that’s the condition doing its job, not the trigger over-firing.
• Open the automation’s run log and confirm the run is recorded there, not just visible on the deal. The log is what tells you the rule fired for the right reason, not by coincidence.

Once those three checks pass, leave the rule live for a few real stage changes before treating it as proven: a rule that works once on a test deal can still miss an edge case, like a deal that skips straight past Negotiation to Closed Won, which never triggers a task at all and isn’t a failure, just a case the rule was never meant to catch.

Two variations to build next

Once the first rule is running without surprises, these two reuse the same skills on a different trigger or a different action:

Variation 1: escalate instead of remind. Keep the same shape but change the trigger to a later stage, such as Contract Sent, and change the action from a task on the rep to a notification sent to the rep’s manager. This gives a manager visibility into deals sitting at the finish line without adding a status meeting to check for it.

Variation 2: a win-back check on a lost deal. Trigger on the deal being marked Lost, and set the action to create a task 90 days out, assigned to the original owner, titled as a check-in. Circumstances change (budget frees up, a contract with a competitor ends), and a rule like this is the only reliable way a lost deal gets a second look instead of disappearing from view the day it’s marked closed.

Common mistakes when building your first automation rule

• Leaving the condition too loose. A trigger with no pipeline condition fires on every deal in every process, not just the one you built it for.
• Assigning the task to a fixed person instead of the deal owner. That works until a deal has a different owner, and then every task lands on the wrong desk.
• Skipping the due date. A task with no date attached is easy to postpone indefinitely; the two-day window is what makes it a nudge instead of a line item nobody opens.
• Publishing to the whole pipeline on day one. Testing on one deal first is what catches a wrong field or a mistyped stage name before it reaches every rep.

Where Senitix CRM automation fits in your process

In Senitix CRM, every rule you build runs in the same no-code builder, writes to the same run log, and can be edited or turned off without losing its history, and how many active rules a workspace can run grows with the plan. For more rules to build once this one is proven, see our list of sales tasks worth automating first.

To see what’s included at each level for your team size, compare plans or talk to the sales team.

Frequently asked questions

How many automation rules can I run at once?

Free includes 1 rule to try the builder with; Growth supports up to 50 active rules, with a higher limit on Professional and Enterprise. Most teams use far fewer than the limit at first: two or three well-tested rules, like the stage-entry task above, cover the highest-value gaps before it’s worth adding more.

Can I edit a rule after it’s published, or do I have to start over?

You can edit any part of a published rule (the trigger, the condition or the action) and save the change without rebuilding it. Test a meaningful edit the same way you tested the original: on one deal first, before letting it run against the full pipeline again.

Does the rule apply to deals that are already sitting in Negotiation?

No. A stage-changed trigger fires on the moment of the change, so it only affects deals that move into the stage after the rule is turned on. Deals already there when you publish it won’t get a task retroactively; check that list manually once, and the rule takes it from there going forward.

What’s the difference between this and what Senitix AI does?

An automation rule executes exactly what it was configured to do, the same way every time: it doesn’t read the deal or make a judgment call. Senitix AI works differently: it can draft a follow-up email or summarize a thread, but nothing it drafts is sent or changed until a person confirms it. Use automation for steps that never need a judgment call, and AI drafting for the ones that do.