Changes to Clarizen Data Model in Clarizen 6.0 – updates to customizations needed

Clarizen Version 6.0 introduces a powerful new capability called ‘To Do’ tasks, that is; tasks not attached to a parent work item (project, task, milestone), as opposed to Version 5.4, where tasks are required to have a parent; a project, milestone or another task.  

To Do tasks allow people to track their own personal or operational Clarizen tasks as well as opening a wide range of scenarios for people to keep their Clarizen work coordinated and centralized.

Version 6.0 offers four ways to distinguish To Do tasks:

1) Task Project field is empty (blank)

2) A Toggle (checkbox) field called To Do List item (API name: $FloatingTask), which is checked if the field is exposed on the grid.

3) Hovering the mouse pointer over the task name exposes the path [To do list]

4) The To Do tasks has a different icon from tasks with a parent: 

•  ─ To Do task
•   ─ Parented task

Technically-speaking, this change affects the way customizations are built under Version 6, and might have an effect on customizations imported from a previous version of Clarizen.

Implications for Admins

Regarding customizations, when building customization associations to work items in Version 5.4, and referring the work item’s - $Parent or $ParentProject, or $Project, you could rely on the fact that the relation would not be empty and the customization (based on the specific case, requiring this referencing) would always work.

However, in Version 6.0 this assumption might not be correct, and in the case of a To Do task, the customization fails because of a non-exiting parent. A similar error message might appear:

If you have a customization on your account referencing the $parent, $ParentProject or $Project which will fail several times when triggered by a To Do task, the rule shuts down and notifies the organization Admins. However, this can affect your workflows and user experiences. This, of course, is not desired behavior.

What you need to do:

You will have to go through your customizations before migrating to Version 6.0 and ensure to complete the following steps for your customizations to continue to work seamlessly.

If you make your changes under version 5.4:

1. Use the Isnull() function on each reference to: $Parent, $ParentProject, $Project and check in the Rule that the parent is actually defined. i.e.: “if( not isNull ($Project) ||  not isNull ($ParentProject) || not isNull ($Parent), [do something], [do something else])”

2. Wrap your customization with the “ Catch” function:

Sample 1

i.e.: “catch($Project.ID,’’[do something if fail]’)”

Sample 2 

The 'Catch' function can be useful in case you have a large piece of code which you wish to leave 'as-is', and not edit it phrase by phrase.

i.e.: your original code is something like this:

$project.Name <> 'My Project' && $Parent.Manager= 'Bart Simpson' || $StartDate<Date(2014,01,05)

Instead of checking the isNull() function on both the $project and $parent, you can edit the code to be:

Catch($project.Name <> 'My Project' && $Parent.Manager= 'Bart Simpson', [do something if catch return error]) || $StartDate<Date(2014,01,05)

If you make your changes under Version 6.0:

1. Same changes as 5.4 can be applied.
2. Use the “$FloatingTask”  Boolean to make safety checks.

i.e.: “if($FloatingTask,[do somthing],[do something else])”

Notes:

• Clarizen customizations support nested referencing, aka $Parent.Parent.Parent; up to five nested levels.
• Ensure your customizations are safe including when using such a structure in your code.  

How to find these potential exceptions easily?

Clarizen recently released a new capability to search customization content from the Customization screen search box, making it simple to find the cases in which Project, Parent Project and/or Parent is used in your customizations, and prompts you to add a checkmark to verify that the field does in fact have a value prior to attempting to update or run any other actions on it.