@Bastien_Siebman is on the right track here, but you can’t just omit requested_dates, you need to pass it. That is, if any of your template’s tasks have relative dates set on them, as yours do, then when creating a project from the template, you need to tell Asana what date you want to use as the “anchor” date from which it should calculate all of the relative task dates. Send that “anchor” date in the requested_dates property as shown here in the API docs. Note that the gid property can be any GUID of your choosing; it doesn’t correspond to any existing object but rather it just provides a unique value to go along with the anchor date you pass.
Having said that, if you don’t want to provide your own “anchor” date but just want Asana to calculate all of its task dates from an “anchor” date of today (that is, whatever the current date is that you’re creating the project), then instead of sending the requested_dates property, omit it and send a property of is_strict set to a value of false. As shown in the docs, this will not generate an error but will use a default value of today as the anchor date.
When a project template is created and it contains tasks with relative dates, it also gets an element stored as part of its definition called requested_dates. You can see the specification for that element in the API docs:
Now, when you want to instantiate a project from the template (and it contains tasks with relative dates), you have to provide it with the calendar date to use for that “anchor date”. You do that via the requested_dates element, just like you included in your instantiate_project request. Except that you have to give it the id that matches the requested_dates element in the template’s definition, in this case, “1”. In my testing, Asana currently always assigns that element a “1”.
Now you might ask, “why do I have to give it an id when there is only one requested_dates element in the template definition?”
I can’t go into too much detail in answering that question without violating my NDA with Asana, but let’s just say that in the future, there might be more than one requested_dates element in a template definition. Let’s say there are two, with ids of “1” and “2”. Now when you instantiate a project from that template, you’ll have to provide two calendar dates - and you’ll have to include an id of “1” with the first date and “2” with the second one, so that Asana knows which of your calendar dates to use for each of those two defined relative dates in the template definition.
Hopefully the above makes sense but let me know if not!
Another way I just thought of to explain it is to say that in the template definition, you’re defining a variable, and when you instantiate that template, you have to provide a value for that variable. The “id” is the variable name. Currently a template can only contain one variable, with an id/name of “1”; but imagine that, in the future, templates will be able to define multiple variables, each with a unique id/name; and in your instantiation, you’ll provide values for all of those variables.
Makes sense Phil. Thanks for the detailed explanation. The example shown in the API documentation confused me a bit here because it as the gid as 12345, which from what i now understand will never work.
It’s not that it will never work, just not currently. Imagine a future time when you can create a project template programmatically, and when you do, you can define your own “variables” and what their ids are. Then the id can be anything you choose.
Nonetheless, I’ll point out the issue you had here to Asana as it seems it would be good for the docs to include this additional info about how the id works.
@Phil_Seeman I’ve got a Template Project (Legacy) that I use as a template for other Projects with Flowsana. If I change this to the New Project Template, will Flowsana still be able to apply all the subtasks and assignemnts on the New Project Template? Do I have to change anything?
Unfortunately when Asana creates a Project Template 2.0 from a 1.0 template, the 2.0 version is a whole new object in Asana independent of the original project object, so you’ll have to create the workflows in the 2.0 template.
Also note that 2.0 templates don’t yet support Flowsana rule actions in the template’s rule builder, so if you have any rules involving Flowsana that live in the Asana rule builder in your 1.0 template, you’ll have to create those rules in the Flowsana web portal instead (and make sure they can be built there, as the Asana rule builder has a few capabilities the Flowsana web portal does not have.)