How I destroyed 1200 data points in Asana by mistake, and fixed it

English Forum Community Tips Forum Leader tips
1

I recently destroyed 1,200 data points in Asana, and learned a lot by restoring them.

I was doing a major cleanup of our account. One project contained two very different types of tasks. Each type needed its own custom fields, views, rules, and dashboards, but everything was mixed together. My solution was to split the project in half.

The plan was simple: duplicate the project without tasks, move half of the tasks into the new one, then clean up views and rules on each side. On paper, perfect. I did it, felt great, shared with the team.

Then someone came back saying: the values in some fields were all showing as TBD. At first, I didn’t believe it was my fault. We jumped on a call, and she was right. I destroyed values!

What happened? The original project had a rule: “when a task is added > set default values for some fields”. By moving tasks into the duplicated project, that rule triggered again. Three fields on 400 tasks were reset. That’s 1,200 data points gone.

There’s no undo for this kind of bulk change. The only options: restore a backup or use the API. So I wrote a script (in Custom Scripts) that went through task histories, found the overwritten values, and restored them. It worked, all data was recovered.

What I learned:

  1. Always trust your teammates. The ones closest to the work will notice problems before you do.
  2. When moving tasks between projects, review the rules carefully. Especially rules that apply defaults on “task added.” Always use conditions.
  3. Having someone who can quickly script fixes is a lifesaver.

Mistakes happen. Fixing them is where you really learn.

Bastien, Asana Expert
i.DO (Asana Partner: Services & Licenses)

3 Likes
2

Whew, what a relief that you recovered the data!

On the point of reviewing rules, I recently ran into unexpected things being broken as well. We had three separate projects that were all using the same fields, but none of the fields were global fields. It made more sense for the fields to be global fields, because occasionally a task might be multi-homed between the two projects. By not using the fields from our account library, it made it so that contradictory information could potentially be entered into the two different versions of the field.

When I replaced all the fields with global ones, suddenly all our rules were broken. I hadn’t thought of that happening. It was also very hard to see exactly WHAT had broken, because many rules referenced the version of the field that had been deleted from the project. Once the rule was broken, you could no longer click into that and see what field used to be or what actions that had triggered.

Fortunately, I was able to rebuild the rules from an intact/duplicate version of the project that hadn’t yet been edited. But it was a bit of an eye opener when it happened!

I would say that rebuilding the rules was a pain, but actually it was so educational and I learned so much about our projects from doing it that I can’t really complain.

1 Like