Righthand
← All posts

How to use a Righthand with Asana

Prepare an Asana dependency review using task IDs, assignees, due dates, completion state, and reviewed escalation proposals.

Focus an Asana review on one project decision

Use Righthand with Asana to prepare a dependency review for an approved project. The useful output is a short list of tasks whose dates, ownership, or dependencies need a human decision. A generic summary of every task often repeats the project view without helping the lead decide what to do next.

Asana's task reference describes task identity and scheduling fields. In particular, a date-only dueon value differs from a timestamped dueat value. Preserve that distinction so a task due Tuesday does not acquire an invented midnight deadline.

Define project and task scope

Give the project identifier, included sections, completion rules, and dependency information the connection can actually read. Include subtasks deliberately. The same task may appear in more than one project, so deduplicate by task identity rather than by title.

Inspect Asana's exposed tools in integrations. If the required task or dependency read is unavailable, supply an approved project export with task IDs and a snapshot time. An export can support a decision brief without being described as live project management.

A complete illustrative request

At 2 PM America/LosAngeles on Thursday, review the linked launch project and its approved subtasks. Return a private dependency brief for work due in the next seven days. Show task ID, task link, explicit assignee, dueon or due_at as supplied, completion state, and known blocking task references. Group missing owners separately from blocked work. Do not reassign tasks or change deadlines. Send to me for project-lead review and reconcile the unique task count with the selected project scope.

This example is illustrative. The assistant should not declare a dependency cleared because the blocking task has a reassuring comment if its recorded completion state remains unresolved.

Show useful evidence beside each proposal

An example entry might say: “Packaging review due Tuesday; assignee absent; dependency points to an incomplete copy task; owner must confirm sequencing.” The proposed next step can be to assign an owner or review the date, but it remains a proposal until approved.

Separate absence of a due date from lateness. A task with no deadline may still be important, but the report cannot compute overdue status from an unspecified date. Include the team's definition of completed and excluded sections with the report.

Reconcile updates and concurrent work

A repeat run should match task IDs, then report changes in assignee, deadline, or completion. Do not recreate the same escalation just because a task has moved to a different section. If updates are authorized later, apply only supported changes to the approved tasks and reread the resulting fields.

Permission loss can hide a task or dependency. Treat that as unavailable evidence rather than a resolved blocker. A stale export may show yesterday's owner, so request a refreshed snapshot before making a time-sensitive handoff.

Use Righthand's responsibility guide to define the recurring review, its checkpoint, and its human owner. Review plans against the scope of ongoing project support.