Sections are dead! Long live sections!



Not sure if im missing somthing. I tried to create a subtask with the field is_rendered_as_separator: true but that didnt create a subtask-section. Is it possible at this moment to create separators on a subtask or should that be created on a section endpoint to the apI?




@Jonas_O, I haven’t tried setting the field myself (only getting it), but a quick possible cause to confirm: Are you positive you have enabled the deprecation header when trying this?



@Joe_Trollo - Thank you for keeping us up to date. However, I still have not received an answer to how to sort sections within the new Sections framework. We have a process which would create Sections in Alphabetical order and then tasks under the correct section. The sorting of the sections is critical to our workflow under this project.

We currently are able to do this by using the Task API on projects which have not been converted to the new Sections interface. The documentation for new Sections does not allow for sorting. Additionally, I created a Board Project and attempted to use the “section” and “insert_after” option (both listed under the task API and were referenced ealier in this thread as possible options) when creating a new section but had no success.

Please provide thoughts on how to insert of Sections in Alphabetical order with the new Sections API.

If this is not an option, it will break our current workflow and make Asana unusable.

Thanks for your feedback!



Hi @Benjamin_Ragan,

Did you try this endpoint with the before_section or after_section parameter?



@Phil_Seeman - I tried “after_section”. It does not appear to work when creating a new Section. This appears to move a section after the Section has been created. This would require 2 calls, which can be done, but is not ideal.

If I am missing something, please let me know.



I haven’t tried it myself but there is a specific example on that page of adding a new section and including before_section in the insert call (it’s under “Add or move a section in a project”); maybe try that to follow that example and see if you can get that to work?



Thank you for your feedback. I agree there is a heading Add or move a section in a project, but the example assumes the call already has a gid for the section.

curl -H "Authorization: Bearer <personal_access_token>" \ \
--data-urlencode "section=2001" \
--data-urlencode "before_section=2002"

This would indicate the section was already created prior to adding to a project or moving within a project.

Any other suggestions, other than making two separate calls API calls (Create the Section then Move the section)…

Again, thank you for your help.

1 Like


Good point! Time to call in the cavalry.

@Joe_Trollo @Matt_Bramlage @Jeff_Schneider: is there a way to add a new section in a particular location within a project’s sections, or do you need to add it first, and then do a second call to place it?



Hi @Benjamin_Ragan, the API should support insert_before and insert_after when creating a section, but upon inspecting our code I found a bug which was ignoring these parameters. The fix should be deployed in another day or so, after which both POST /sections and POST /projects/<project-id>/sections will accept insert_before and insert_after.



How do I migrate a project? Is there a way to opt in for the new API? @Joe_Trollo



Hi @Nikolay_Yanev, the API does not permit migrating projects—migration will be triggered by users in the web app on a per-project basis. This is not yet available to users, though, and we do not yet have a timeline for rolling it out.


API for milestones?

Hi @Joe_Trollo ,

Not sure if you answered already or not. When do you plan to disable (in the API) the ability to create a section just by using the colon? I just need to make sure I fix my code before you do.




Hi @Bastien_Siebman, there is no way to create a section in the API with a task whose name ends in a colon. It is only possible to create separators. When creating new tasks (i.e., POST /tasks) there are two cases:

  • You are not sending a change header, or are sending the Asana-Disable: new_sections header. In this case, when you create a task that ends in a colon, it will be rendered as a separator in unmigrated projects and will have the is_rendered_as_separator field implicitly set to true. It will not be rendered as a separator in migrated projects or current boards projects. This behavior will naturally be deprecated as more and more projects are migrated.
  • You are sending an Asana-Enable: new_sections header. In this case, tasks are never created as separators based on the name. Instead, you will need to set the is_rendered_as_separator field explicitly. Tasks will only be rendered as separators in unmigrated projects (and lists of subtasks and users’s My Tasks).
1 Like


Is it correct to say that all the new projects (created from now on) are “migrated projects” from the start?

Does that mean any project created with the API will be displayed as board by default and user will have to manually set the view to list? Will we be able to choose the list layout by default at creation?



Hi @Bastien_Siebman,

No, no projects are migrated yet. The UI to choose to migrate a project has not been rolled out to us yet.

It seems like, if you enable the deprecation, you can only create a Board project with the API and that’s what the user will see, but @Joe_Trollo should answer this one for sure! If so, then I think, Bastien, that you might want to test with the deprecation enabled, but not enable in production early as a result of this.

Hope that helps,


1 Like


This is correct. So far, nothing has changed about how the vast majority of projects are structured or created in Asana, with the exception of a few beta tests. We will eventually roll out the ability for users to migrate their own projects, and sometime after that we will enforce that all new projects follow the new data model.

The default view for a project created through the API will be the same as the default view as projects created in the web app. I am almost certain that once the project data models are unified, “list view” will be the default for any new project, but this is a product decision in the hands of another team.



That is very clear. A big thank to you and to @lpb who helped me sort things out.