Wrike Integrate - Example recipe to add a project-specific prefix to the task title for all new tasks within each project
Prerequisites
- Wrike Business or Wrike Enterprise (in order to use custom fields)
- Wrike Integrate (paid add-on)
- Wrike custom text field named Wrike Integrate (available to tasks, used to distinguish new tasks vs. updated tasks)
- Wrike custom text field named Task Title Prefix (available only to projects, used to record the project-specific task title prefix that should be added to all tasks within each project)
When creating custom fields used in Wrike Integrate recipes, we share these fields only with our Wrike Admins, so other users can't see or change the value in these fields. Keep in mind that the user linked to your Wrike Connector in Wrike Integrate will also need access to these fields in order to see/update them.
Recipe results
This recipe will trigger only for new tasks, and will look for a Task Title Prefix up to 4 folder/project levels above the task. The first non-blank prefix value found will be automatically added to the task title.
Important caveats
-
Because this recipe triggers only for new tasks, it will work only if you create the task within the desired folder/project tree. If you create a task then move or tag it to another folder, this recipe will not update the task title.
-
This example recipe only traverses 4 levels of parent folders/projects to look for a task title prefix. If you use more than 3 levels of nested sub-folders in your projects, you will need to modify this recipe to handle your desired number of nested sub-folders.
Great post, thanks a lot for sharing, Laura Boylan 🙂
Lisa Community Team at Wrike Wrike Product Manager Become a Wrike expert with Wrike Discover
Lisa Wrike Team member Become a Wrike expert with Wrike Discover
A few questions about this community recipe referenced in this update https://www.workato.com/recipes/1102718:
1. shouldn't the parent file directory tree be traversed via recursive callable function rather than assuming there will only ever be a maximum of 4 parent folders?
2. Shouldn't the task title prefix be checked (via title contains task title prefix) to ensure it isn't already present within the task title?
3. Can't we determine if the task is new by comparing the created time and updated time rather than dedicating a whole custom field (Wrike Integrate)? and if the custom field is to be used, shouldn't that update (step 18) be moved to step 1 based on the comment?
Hello David R Cariello,
Thanks for taking a detailed look at this recipe. (And I apologize in advance for the long-winded answer...)
First, note that all of the example recipes I post are just that... examples. They're intended to get other Wrike users thinking about what they can accomplish with Wrike Integrate, and they should always be reviewed and adjusted as needed for any organization's specific needs.
Also, many of my organization's running recipes include additional error handling and bulletproofing steps that I don't include in the Community recipes I share, to keep the examples a bit simpler for newer Wrike Integrate users. I'll try to find time to post examples of those steps at some point in case they're helpful for anyone.
----------
1. Your question: shouldn't the parent file directory tree be traversed via recursive callable function rather than assuming there will only ever be a maximum of 4 parent folders?
Short answer... yes.
Workato (Wrike Integrate) doesn't offer a built-in feature for this need (at least I haven't found one), so I took a cheap shortcut in my original recipe. Your question got me thinking about workarounds, and I've updated the recipe accordingly, to support as many nested subfolders as your organization might need. That number should be entered as the list size in step 4 (although for some reason Workato has begun showing a mismatch in the step numbers between the on-screen numbers and the data pills... I'll report that). Thanks for the nudge to find a better way. And if you find a solution without manually specifying a folder depth, please share it!
One thing to note... the deeper the task exists within nested sub-folders, the longer the recipe will take to run (which means the longer it will take to update the new task's title). The tests I ran with the newer recipe version showed the following run times for new tasks created below a space's top-level folder:
2. Your question: Shouldn't the task title prefix be checked (via title contains task title prefix) to ensure it isn't already present within the task title?
Given that a user could manually enter the prefix on a new task's title without realizing it will be automatically added... yes, this check could (and probably should) be added for additional bulletproofing. I've updated the example recipe accordingly.
Note that multiple prefixes (manual and automatic) would still be possible if the manually entered prefix has a typo or other variation.
3a. Your question(s): Can't we determine if the task is new by comparing the created time and updated time rather than dedicating a whole custom field (Wrike Integrate)?
That was actually the first thing I tried. The short answer for why I took a different approach... I couldn't count on the timestamps to reliably identify new vs updated tasks.
The longer answer, if you're interested... Many of our projects and tasks are created from request forms & blueprints, and the Create/Update timestamps for these projects/tasks are never identical when reported to Wrike Integrate (I think because Wrike first creates the project/task by copying the blueprint as-is, then updates the project/task with info from the request form submission). I tried checking for a difference of no more than a few seconds between creation/update to indicate a "new" task, but had to keep increasing that time difference to catch all the new tasks created by request form submissions. By the time I landed on a time difference that seemed to catch all the new tasks from request forms, the recipe started running twice for some manually created tasks that were quickly updated by the author. I realized I needed a more reliable way to identify new vs. updated tasks.
I like the custom field approach because I can hide the custom field from most users so nothing clutters up our workspace and users can't interfere with or change this field manually, and I can also update the custom field with debug info showing when Wrike Integrate processed each task (e.g. "Processed 02/24/2020 5:31PM").
If you'd prefer not to use a custom field, another approach suggested by Admin Bot is to create a dedicated folder within Wrike for every Wrike Integrate recipe, and tag tasks to this folder when they've been processed by the recipe.
3b. Your question: if the custom field is to be used, shouldn't that update (step 18) be moved to step 1 based on the comment?
I chose to perform this update at the end of the recipe, right before the other task updates, as a bulletproofing measure to minimize the possibility of partial task processing in the event that an error happens somewhere else in the recipe actions. For example, if one of the API calls to get parent folder information fails (e.g., temporary API outage that starts mid-recipe), the recipe will throw an error and stop, so the task title will not get updated. If the task's custom field had already been updated as the first step within the recipe, the task wouldn't get re-processed when the error resolves and the job gets re-run.
----------
I hope this info helps. If you have ideas for further ways to improve this recipe (or any of the example recipes I've posted), please share!
Edited this post today to change the links to Workato recipes to support the new sharing mechanism they introduced a while back that broke the older links.