Wrike's built-in automation engine lets you set up if-this-then-that rules inside a project: a task gets created and gets assigned automatically, a status changes and the task moves folders, a due date approaches and someone gets notified. Recurring task templates work the same way, on a schedule instead of a trigger. It only sees events inside Wrike, and it can only take actions Wrike itself knows how to perform.
The automation engine's rules follow a familiar pattern: a trigger (task created, status changed, field updated, a date arriving), an optional condition, and an action (assign someone, change a status, move the task, send a notification). Recurring tasks run on their own schedule and spin up a fresh copy of a template without anyone remembering to create it.
For a lot of repetitive project setup, this native layer genuinely covers it. A recurring compliance checklist, a status change that automatically reassigns ownership, a due-date reminder, none of that needs custom code.
The automation engine can't see what happened in a different tool, and it can't take an action in one either. A rule can move a Wrike task into a different folder when someone marks it approved. It can't update a billing record, send an external e-signature request, or create a calendar hold in a system Wrike doesn't talk to.
That's the exact point where native automation hands off to custom work against Wrike's API. The rule itself might stay simple; what happens next, outside Wrike, is where we usually get involved.
A recurring monthly compliance task spins up in Wrike on schedule, same as always, but now it also generates the matching document request or sign-off in whatever system actually handles that approval, instead of someone doing that part by hand every month.
A custom status like 'Client Approved' triggers the native rule inside Wrike, and simultaneously updates a billing or account record somewhere else, something the automation engine alone has no way to do.
If a Wrike automation does the first half of something and a person still finishes the rest manually, that's usually fixable. Tell us what the rule does now and what it doesn't reach.
Tell us what a Wrike rule currently triggers and what someone still has to do by hand once it fires. We'll figure out whether that's a bigger native rule or custom work against the API. And if the real gap is in a completely different tool, that's just as fair game.
Let's talk →Common ones include a task being created, a status or custom field changing, a due date arriving, or a task moving between folders. The action that follows can reassign someone, change a status, move the task, or send a notification.
Plan features and limits change over time, so wrike.com/pricing is the reliable source for what's included at your tier. Heavier automation use is typically gated to higher-tier plans.
Wrike's native notifications are built for people already in the account. Reaching someone entirely outside Wrike, or triggering an action in another system, is the kind of thing that gets built against the API instead.
Yes, recurring task templates create a fresh copy on whatever schedule you set, separate from the trigger-based automation rules.