Asana and CodeWords: custom fields are the reporting model

Asana's distinctive idea is that one task can live in several projects at once. It is genuinely useful — a piece of work can appear in a team's board and in a cross-functional initiative without being duplicated — and it is the thing most likely to confuse an automation that assumes a task has one home.

The second thing worth understanding before building anything is custom fields, because they determine what can be reported on and they are the difference between a work tracker and something a manager can answer questions from.

What we'll cover

• Find out what already runs
• One task, several projects
• What the Asana API reaches
• Connecting it to CodeWords
• Seven automations worth building
• Custom fields, which decide what you can ask
• Intake, done without adding process
• Status reporting for people outside the team
• Building it so it survives
• Limits worth knowing about
• What to build first
• Frequently asked questions

Find out what already runs

Asana has built-in automation, and it is usually already covering some of what you plan.

Rules move tasks, assign them, set fields, and add them to projects on triggers.

Forms attached to projects create tasks with defined fields, which is often the right intake mechanism without any code.

Templates create consistent task structures, including subtasks and assignees.

Installed apps write to tasks and fields, sometimes the same ones you intend to use.

List these before adding anything. If a rule can do it, use the rule — it is visible to the team in the project's own settings, which external automation never is.

One task, several projects

A task has memberships, not a single parent. Adding it to another project does not copy it; the same task appears in both, and a change in one place is a change everywhere.

Sections are per project. The same task can be in different sections in each project it belongs to, which is a common source of confusion for automation setting a section.

Removing from one project does not delete it, and a task removed from its last project becomes hard to find rather than gone.

Subtasks do not inherit project membership, which surprises people whose reporting silently omits all the subtask work.

Portfolios group projects, not tasks, and are the layer above for cross-project status.

For automation: be explicit about which project's membership and section you are manipulating, and decide deliberately whether subtasks are in scope for any report you build.

What the Asana API reaches

Tasks can be created, read, updated, searched, and completed, including custom field values and multiple project memberships.

Projects and sections can be created and read, including from templates.

Portfolios can be read with their projects and status, which is the basis for cross-project reporting.

Custom fields can be read and set, including their definitions and enum options.

Stories are the activity log and comments on a task, and posting a comment is how automation leaves a visible trace.

Attachments can be added, including links to external resources.

Users and teams can be enumerated, which anything assigning work needs.

Webhooks fire on changes to projects and tasks, with a handshake on establishment.

Connecting it to CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which project, what triggers it, and what should be created or updated.
3. Authorize the connection with a service account or a token belonging to a dedicated integration user rather than a person.
4. Describe the exceptions: a duplicate of an existing task, a custom field option that no longer exists, an assignee who has left.
5. Test against a scratch project before anything touches real work.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Seven automations worth building

Intake from elsewhere. Requests from forms, tickets, or email becoming tasks with fields populated, in the right project, without anybody retyping.

Enrichment on creation. Attach the source, the customer, the relevant links, so whoever picks it up is not reconstructing context.

Cross-project reporting. Portfolio status assembled for people who do not open Asana, which is most of the people who ask for it.

Stale task reporting. Tasks with no activity, past their due date, or with no assignee, sent to the project owner rather than to a channel.

Completion propagation. When work finishes, tell the system and the person who asked for it. Closing the loop is the most commonly skipped step in any intake process.

Recurring work creation. Periodic tasks generated with the right context attached rather than from a template somebody has to remember to use.

Field hygiene reporting. Tasks missing the fields that reporting depends on, which is what keeps the portfolio view meaningful.

Custom fields, which decide what you can ask

Nothing determines the usefulness of an Asana workspace more than this.

Use enum fields for fixed values. A text field holding status accumulates variants that cannot be grouped or filtered.

Number fields for anything you want to sum. Effort, value, and count in text fields are not reportable.

Field definitions are shared or project-specific, and knowing which you are dealing with matters, since a project-specific field cannot be reported across projects.

Match on the field identifier, not the name, since names are renamed casually.

Read enum options rather than hard-coding them, because options are added and removed and writing an option that no longer exists fails.

Keep the set small. Twenty custom fields means most are empty, and a field that is usually empty cannot support a report.

Intake, done without adding process

The most valuable automation here, and the one most likely to be built badly.

Capture where the request is made. A form, a chat message, an email — whichever people already use. Asking them to open Asana instead is how intake gets bypassed.

Populate the fields at creation, since fields somebody must fill in afterwards are fields that stay empty.

Put it in a triage location, not straight into somebody's assigned work. A request arriving is not a commitment to do it.

Acknowledge the requester with what happens next and a link they can check, which removes the follow-up message.

Deduplicate on arrival. The same request submitted twice is common and two tasks is a poor start.

Tell them when it is done. This is the step that makes people keep using the intake route rather than going back to asking somebody directly.

Status reporting for people outside the team

Portfolio status is the feature managers ask about, and it degrades for a predictable reason: somebody has to write it and nobody wants to.

Assemble the factual part automatically. Tasks completed, tasks added, what is overdue, what has not moved. None of that needs a person and all of it is currently typed by one.

Leave the judgement to a person. Whether a project is genuinely at risk is a call, and an automated colour derived from overdue counts is wrong often enough to be misleading.

Draft it, do not publish it. Generate the status with the numbers filled in and let the owner add the sentence that matters, which takes a minute rather than twenty.

Report what changed since last time, since the audience read the previous one and wants the delta.

Flag projects with no recent status rather than letting them fade, because a portfolio where a third of projects have stale status is a portfolio nobody trusts.

Send it out rather than expecting people to look. Portfolios are visited by the people who maintain them and almost nobody else.

Building it so it survives

Make it idempotent. Store the source identifier in a custom field and check before creating.

Be explicit about project and section, since a task in several projects has a section in each.

Decide about subtasks for every report, because omitting them is the default and is usually wrong.

Handle the webhook handshake, which Asana requires when establishing one, and expect at-least-once delivery afterwards.

Report the outcome. Tasks created, updated, duplicates avoided, and requests that could not be routed.

Limits worth knowing about

Rate limits apply per token and vary by plan, so bulk work needs pacing.

Search has its own constraints and is not a general query language, so complex selection is easier done by filtering retrieved results.

Pagination applies to task listings, and reports built from a first page understate.

Some features are plan-dependent, including portfolios and parts of the rules engine.

Webhooks require an established handshake and can be deactivated if your endpoint fails repeatedly, which is a silent failure worth monitoring.

What to build first

Intake: requests captured where people already make them, becoming tasks in a triage location with the fields populated and the requester acknowledged. It removes retyping, it produces consistent records, and it makes the work visible that currently arrives as a message to somebody's inbox.

Two habits make the difference. Populate every field at creation rather than relying on somebody to complete them later, since fields left for later stay empty. And build the completion notification at the same time, because an intake route that swallows requests silently gets abandoned within a month.

Frequently asked questions

Why does my report omit a lot of work?

Subtasks, probably. They do not inherit project membership, so a report built on project membership misses them entirely. Decide explicitly whether they are in scope rather than accepting the default.

Should automation create tasks directly in someone's assigned work?

No. Create into a triage project or section so somebody reviews before it becomes committed work. An intake that assigns automatically fills people's queues with things nobody chose.

Why does setting a custom field fail?

Usually an enum option that no longer exists, or a project-specific field being set on a task in a different project. Read the field definition rather than hard-coding options, since options change.

Asana rules or external automation?

Rules for anything driven entirely by data inside Asana — they are visible in the project settings, which external automation is not. External automation when the logic needs systems Asana cannot see.

How do I stop duplicate tasks?

Store the source identifier in a custom field and check for it before creating. Requests get submitted twice routinely, and webhooks deliver more than once, so both paths need the same check.

What makes portfolio reporting useful?

Consistent custom fields across the projects in it. Portfolios roll up what exists, so projects with different or empty fields produce a view with gaps, which is why field hygiene reporting is worth building alongside.

Why did our webhook stop firing?

Asana deactivates webhooks whose endpoint fails repeatedly. It is a silent failure, so monitor that events are still arriving rather than assuming the absence of events means nothing happened.

Can automation write project status updates?

It can assemble the factual half — completed, added, overdue, not moving — and it should leave the judgement about risk to the owner. Draft it with the numbers filled in and let a person add the sentence that matters.

Why does portfolio reporting stop being useful?

Because status updates go stale and fields are inconsistent across projects. Both are worth reporting on: projects with no recent status, and tasks missing the fields the roll-up depends on.

What is the best signal that a project is in trouble?

Tasks that have not moved, rather than tasks that are overdue. Due dates get pushed; a task nobody has touched in three weeks while the project is supposedly active is the more honest indicator and nothing surfaces it by default.

Related reading

• ClickUp and CodeWords
• Trello and CodeWords
• CodeWords integrations and templates