Asana Workflow Specialist Certificate flashcards

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

Workflow stage mapping rule

Each workflow stage should correspond to exactly one structural element - either a section or a status field value - so that views, filters, and rules read progress from a single consistent source.

Handoff identification

A handoff occurs where one person or team completes work that another then begins. Each handoff is a candidate for a dedicated assigned task, rule trigger, and notification.

Design sequence order

Define outcomes, then stages, then required data per stage, then automation. Automating before stages stabilize forces rework because triggers and conditions reference structures that later change.

Reversible workflow stages

Rework, blocked, and on-hold stages should be modeled explicitly. Without them, tasks get parked in incorrect stages, distorting cycle-time and workload reporting.

Workflow role to permission mapping

Requesters need comment or form-submit access, doers need edit rights, approvers need edit plus approval action, and stakeholders need read-only access. Permissions are granted per project.

Workspace project task hierarchy

The structure is workspace, then team, then project, then section, then task, then subtask. Subtasks are associated with the parent task but are not section members of the parent project.

Multi-homing a task

A task can belong to several projects at once. Each project membership carries its own section placement, custom field values, and completion state, while name and comments stay shared.

Subtasks and inheritance

Subtasks inherit nothing automatically from the parent task except association. Assignee, due date, and custom field values must each be set deliberately on the subtask.

Deleting a section effect

Deleting a section does not delete its tasks. They relocate to the sectionless area of the project and must be manually re-filed into a valid stage.

Section move as stage change

Sections appear as ordered columns in board view and as groupings in list view. Moving a task between sections is the standard stage-transition event used to trigger rules.

Workspace versus project fields

Workspace-level custom fields are shared across projects and edited centrally. Project-local fields exist only within one project and cannot be reused or reported on elsewhere.

Custom field type constraint

Field type determines what can consume it: filters, rules, and form mappings each require compatible types. A text question cannot populate a dropdown field, for example.

Dropdown option governance

Dropdown options form a closed list. Every added option becomes a permanent reporting dimension and filter value, so additions should be reviewed rather than made ad hoc.

Computed field limitation

Formula and rollup fields are read-only because they derive values from other data. A workflow must never require a person to type into a computed field.

People field routing

People-type custom fields support 'is me' filter conditions, making them the standard mechanism for building personal work queues and routing reviewers to assigned items.

Rule anatomy

A rule consists of a trigger event, optional conditions that must all pass, and one or more actions. Conditions are evaluated at trigger time, not continuously.

Rule trigger examples

Common triggers include task added to project, section changed, custom field changed, due date approaching, task completed, comment added, and form submitted.

Automation loops

Two rules that each change a field the other reacts to can oscillate indefinitely. Field-changing actions should be idempotent so repeated evaluation produces the same state.

Rules and existing tasks

Rules act on future trigger events. They do not retroactively process tasks that already exist unless a new qualifying event occurs on those tasks; bulk edit handles backfill.

Rule creator permission context

Rules often execute under the permissions of the person who created them. If that person loses project access, the automation can silently stop working.

Dashboard chart requirements

A dashboard chart needs a source (project or portfolio) and a measure such as task count. Grouping by a dropdown field produces one bar per option, including unspecified values.

Filter combination logic

Conditions on different fields combine with AND. Multiple selected values within a multi-select field combine with OR, so a task matches any selected option.

Date-based view gaps

Calendar and timeline views display only tasks that have dates. Tasks missing dates are invisible there, a frequent cause of apparently missing work during reviews.

View settings versus task data

Sort, group, and filter settings are stored at the view level. Changing them alters what an individual sees without modifying any task's underlying field values.

Portfolio reporting scope

Portfolios aggregate multiple projects for cross-project reporting. Portfolio dashboards report project-level status and custom fields rather than individual task-level detail.

Form to project mapping

A form is attached to one project, and each submission creates a single task there. Questions map to task name, description, and custom fields of matching type.

Form default routing

Forms can specify a default section and default assignee, which routes incoming requests to the correct stage and owner automatically at the moment of creation.

Template relative dates

Project templates define sections, tasks, subtasks, and relative due dates anchored to the project's start or end date, so dates populate when the project is created.

Intake workflow pattern

A standard intake pattern is a form creating a task in an intake project, a rule assigning owner and due date, then a section change signaling triage is complete.

Project permission roles

Project roles are owner or admin (settings, members, fields), editor (tasks and comments), commenter (comments only), and viewer (read only). Permissions apply per project, not per task.

Private project visibility

A project set to private to members is invisible to non-members, including workspace admins, unless they are explicitly added. This is the primary confidentiality control.

Archive versus delete

Deleting is destructive and cascades to tasks. Archiving preserves history and removes the project from active views, so archiving is preferred for completed work.