Automations in Wrike save time when they are set up well and maintained. A Wrike account that has been in use for a year or two typically has automations that were set up at different times, by different people, with different levels of documentation.
Here are some practices you and your team can use to manage this. They are practical enough to apply directly.
Every automation should have a name that tells you what it does, where it applies, and what triggers it. Something like “NA – Projects — Task Status Change to In Review — Notify Reviewer” is immediately understandable. You can always hover over the text to see the full title when it is too long. Go back and rename everything that does not describe its own function.
Categorise by function or department
Group automations by what they do or which team they serve. Automations that handle status changes for the content team should be findable by looking at content automations, not by scrolling through a flat list of everything in the account.
In Wrike, this means being deliberate about whether automations are at the space level or the account level. Space-level automations only run in the spaces they are configured for. Account-level automations run everywhere. An automation specific to one team’s process belongs at the space level. Only automation logic that is company-wide should be at the account level.
A document or spreadsheet that lists every major automation in the account, its name, trigger condition, action, and what process it supports, is one of the most useful things you can maintain for a Wrike account.
This is especially valuable when something breaks. A task being assigned to the wrong person, a status changing unexpectedly, a notification firing at the wrong time, having a complete record of every automation that touches that workflow is what lets you find the cause quickly instead of guessing.
The documentation does not need to be elaborate. A simple table with name, trigger, action, and purpose covers what you need.
Designate someone to own the automations
They should have access to them, know what exists, approve new automation requests, and be responsible for making sure active automations stay accurate as processes change.
Regular reviews
Monthly reviews make sense for fast-moving accounts where workflows change frequently. Quarterly works for most organisations. Annual reviews are enough for accounts where processes are stable.
At each review, ask the same questions: Is this automation still relevant to a process that exists? Is it triggering correctly? Has anything in the workflow changed that might affect how it behaves?
Automation rules that are no longer needed should be deactivated or deleted. Leaving them active means they continue to fire on conditions they were built for, which may no longer be the right outcome.
Test before you use
Every new automation should be tested before it goes live. Run through the trigger condition manually and verify that the action happens correctly. Then get feedback from the people who will interact with it, the end users who will receive the notifications or see the status changes, and adjust based on what they experience.