Hi
We have just moved all our work to Asana via the .csv import but now we have no history of our completed tickets, so we were hoping we could run a API command to update the “completion date” field to reflect the date they were closed in our previous task management system
I was told by Asana support to post here as this is not a option in the .csv importer
else our history looks like we just closed hundreds of tickets on one date :
Hi @Jóhannes_Ólafur_Jóha , the ‘workaround’ I will describe below may be too late if you have already imported your CSV, so this will require you to be open to the idea of re-importing your CSV if you want to (partially) solve this
If you have the ‘completed date’ data in your CSV which was exported from your previous platform, you could have mapped that column to a date field (for it to be created as a new custom field), as per below:
to get to the above pictured menu, make sure to select white button ‘Make changes’ during the import process. (your field may be ignored in the columns, so check the dropdown on the right that says ‘X columns ignored’)
The benefit is that you will be able to bring in this data to Asana.
The downside is that, moving forward in Asana, all the completion date for your tickets will not be displayed in this field (unless you manually update - not recommended), instead you will enable the ‘Completed on’ meta-field from the Hide button as per below:
So you will end up with two ‘completed on’ fields which I understand is not ideal:
- The completion dates imported from your previous platform, which you should name this field accordingly, such as ‘Completion date of tickets on Jira’
- Asana’s native meta-field ‘Completed on’ which will be automatically populated going forward.
You could then create a dashboard as per your screenshot, but one chart for each of your two completion date fields, set side-by side in your project dashboard. Not ideal, but it’s better than what you’ve currently got, right?
Or someone else could indeed do their magic using the API! (@Bastien_Siebman ?)
What would be the “magic API” method ?
i would be interested to explore that if the API allows us to update the built in completion date field after the .csv import
and we did use a custom field which was a date field type so we have the data per say in Asana and yes i could create a separate dashboard but our entire history would be skewed and forever a massive spike in “completed” tickets going forward on the date of import
I find it hard to believe that Asana does not support migrations from other task management systems and retain the previous history
You would use the update task API endpoint to update the completed_at
field.
is the documentation then missing “completed_at” as it only contains Completed which is a boolean true false ?
If you click on the “Tasks” section header on the Reference tab, you’ll get the complete Task object model including all fields.
However, you’re right - in the individual endpoint docs like for “Update a task”, the field listing for the Task object is very partial and is missing a lot of fields including completed_at
.
(cc’ing @AndrewWong @John_Vu regarding the partial field listing)
Right, so the endpoint should allow to update the completed_at ?
Absolutely. Basically, any task endpoint has access to the full task object and its properties.
I’m so sorry, @Jóhannes_Ólafur_Jóha, I don’t know what I was thinking in my previous response, I totally spaced out - as you note, the Completed At date is a read-only field, Asana does not allow it to be changed either in the UI or via the API. Apologies again for my incorrect answer.
1 Like
that’s totally fine Phil … it’s friday after all
Still remains a quite big migration issue for Asana as we described in the gist though
given that support could not help us in, API can not
is this then just the end of the road, how have companies been migrating from other platforms to Asana is then a mystery to me
Are we perhaps (fingers crossed) missing another migration option ?
Don’t think so; the only option is probably something like the workaround that @Richard_Sather provided above.