Asana

Project access can be set at different levels, including admin, editor, commenter and viewer, while form links can be limited to the company or exposed on the web. Before putting sensitive requests or external guests into a project, test a sample account's actual visibility and check the plan's sharing controls.

Asana guests see only work explicitly shared with them: a shared task exposes that task, while a shared project exposes its tasks. Organization guests can invite other guests by sharing work they can access, so test a client or contractor's visibility and who can extend it. Division super admins can set guest invite controls on Enterprise, Enterprise+, and Legacy Enterprise plans.

If an Asana project needs to be archived or moved, compare its JSON and CSV exports using a small project that includes tasks, comments and attachments. Asana describes these as per-project text exports; its separate full organization Domain export is available to organization admins or super admins on Enterprise+ or Legacy Enterprise and returns JSON. Check which details and original files actually survive the chosen route, who can request it, and how the team would restore or import the result before treating either export as a complete backup.

Before clearing an Asana project, test Archive and Delete with a fictional project. An archived project stays accessible and can be unarchived; deleting a project removes it for everyone, although assigned tasks and tasks linked to other projects are not deleted. Asana's Deleted view offers a 30-day recovery window for tasks and projects, but only the item's creator or the person who deleted it can see and restore it there. Permanent deletion cannot be recovered, so confirm who will handle recovery and what work remains visible elsewhere.

Before deactivating an Asana user who is the only member of a project, portfolio or dashboard, verify who can still access and own each item. Asana says deactivation does not transfer ownership of those existing items when no other members are present. It separately creates a project for the user's assigned tasks and gives super admins access to that task project; check that handoff independently from the original items before the user leaves.

Before relying on Asana subtasks to track a project handoff, try a small sample with two owners. Subtasks do not inherit the parent's assignee, so assign each one. Add a subtask to the project and give it a due date if it must appear alongside other tasks in the project list, calendar or timeline. Completing the parent does not complete its subtasks; review unfinished child work before reporting the deliverable done.

Before adding sensitive Asana work to another project, check who can see and edit it. A task created privately in My tasks becomes visible to members of a project when multi-homed there. If a person can access the task through multiple projects, Asana applies their highest permission, such as Editor over Viewer. Test a fictional task with representative members under the team’s actual project privacy, roles and plan, then confirm the intended access before moving real work.

Before relying on an Asana automation during an access change, inspect its owner, destination and enabled state. Asana says an existing automation can keep adding tasks to a destination project even after its owner loses access there; removing that access alone may not stop the action. Saving an edit to a cross-project automation requires the editor to have permission in the destination. A duplicated project or template may disable its automation when the new owner lacks required access, and a project with no other users interacting can also disable it. Asana describes automatic ownership transfer after deprovisioning only for automations without external actions or triggers. Test a fictional cross-project action under representative roles before changing a real workflow.

Converting an Asana task into a project changes the handoff record. The task assignee becomes project owner, collaborators become project members, and subtasks become parent tasks. The original task stays linked, but its comments do not move; attachments can be added as key resources. Asana says a public task yields team-only project privacy, while a private task yields a members-only project with an option to exclude collaborators. Before using conversion for a client handoff, try a fictional task with a comment, file, collaborator and subtask, then inspect both records, the new project's members and its privacy under the intended team.

An Asana recurring parent task duplicates when completed. Its guide says the next copy includes subtasks but not task comments, and warns that making both the parent and its subtasks recur can multiply the subtasks exponentially. For a repeating checklist, use a fictional two-cycle task to compare the new due date, copied subtasks and missing comments before choosing which level repeats. Periodically recurring due dates follow the last completion date, while the calendar shows only the next due occurrence; check the resulting schedule and keep needed discussion history separately.