The Missing Name on a Work Request

A work request is easy to make and surprisingly hard to trust. A colleague fills in a form, a task appears in a project, and the team has a title, a deadline and perhaps an attachment. Then the first triage question arrives: who raised this, and can we ask them a follow-up?

An Asana community user described that exact frustration while setting up a form for colleagues. They could not get the “Reported by” name onto the task and did not want every requester to type their name again. The detail looks small, but it changes the usefulness of an intake system. If a request loses its source, the team may route it wrongly, chase the wrong person, or let an important question sit unanswered.

The useful opportunity is not to build another form platform. It is a small intake provenance card: a fixed-scope review that proves a team can identify the source, reply through an expected route, retain decision fields, and assign a triage owner for each kind of request.

A task is not the same as a traceable request

Asana describes forms as a way to collect requests that create tasks in a connected project. Its forms can be shared with people outside an organisation, can capture attachments, can use branching, and can add a submitter as a collaborator on follow-up work. Its field-mapping guidance explains that form answers can be connected to project custom fields.

Those features are useful, but a team still has to choose the intended provenance rule. An internal employee may be identified through a work account. An external customer may be invited to give an email address. An anonymous feedback route may intentionally collect no name. Those are three different workflows, and they should not be confused by a single label that happens to say “reported by.”

The central judgment is simple: identity is an intake decision with consequences for follow-up and routing. A form should state whether a person is identified, whether a response is possible, and what the team will do when either condition is absent. That avoids the common workaround of making a name field mandatory without checking whether the typed name is useful, accurate or connected to the follow-up.

The card has four proof points

Run the card with the team’s own account and one safe practice submission. Do not rely on an administrator’s memory of how the form was configured.

• Source: submit once through every intended path. Record what the created task displays about the requester and whether the result matches the promised identity rule.
• Reply route: confirm how a triager can ask a follow-up. This may be a collaborator relationship, a verified email field, or an explicit instruction that the channel is anonymous.
• Decision fields: check the fields that determine routing, such as request type, urgency, location or budget. Confirm that answers arrive where triagers will actually filter or report on them.
• Triage owner: name the person or rotation that reviews the new task and the expected response point. A request can have perfect fields and still be ignored if nobody owns the first look.

This acceptance test makes the team's design visible without promising that every request will receive an answer. A failed test is useful: it tells the owner whether to revise the form, change the communication promise, or ask platform support about a specific configuration.

Why a small review can have commercial value

Asana earns subscription revenue from work-management plans and sells richer workflow capabilities at higher tiers. Its public pricing describes forms, custom fields, rules and branching as part of paid plan value. That establishes the commercial software category. A small reviewer serves an implementation layer rather than competing with the platform.

The accessible layer is implementation clarity. A small team may have a form but lack time to test it from the requester's perspective. A freelancer who understands one platform can sell a fixed review: one form, two intended submitter paths, four proof points and a one-page record. The payer is a team lead, agency owner, community organiser or operations manager who wants fewer ambiguous requests. The operator is paid for observation and a practical decision record. The platform remains the software provider; the reviewer is only making the team's intended intake promise legible.

The service needs a narrow boundary. The reviewer should not request passwords, read sensitive submissions, alter permissions, make access decisions or claim legal compliance. The team submits the test requests and controls all configuration. The reviewer documents the visible results and provides questions for the team's administrator. This keeps the review useful even for a small team that has no technical specialist on staff.

That boundary makes the work possible for an ordinary operator without pretending that an intake review is a security audit or a systems integration project.

A better offer names the request type

“Form setup” is too vague to price honestly. A useful offer is tied to a real request stream: creative briefs for a small agency, maintenance requests for a shared workspace, volunteer applications for a local organisation, or internal equipment requests for a growing company.

For each stream, the card should say who may submit, what information is needed to decide, who may reply, who owns triage, and what happens when a source is missing. A public feedback form may deliberately allow anonymous submissions. In that case, the right result is not a failed identity test. It is a clear anonymous route with a separate way to provide contact details voluntarily.

This is where the service becomes more valuable than a checklist. It links a form setting to the actual promise the team makes to a person who submits it. A request for a quick estimate needs a response path. A confidential suggestion may need a boundary around identity. A maintenance request needs a location and a triage owner before it needs a polished cover image.

Test demand before building templates

Speak with five teams that use online forms to start work. Ask for the last request that took too long to route or needed a follow-up they could not make. Listen for a repeated question: “Who sent this?”, “Can we reply?”, “Which queue owns it?” or “Why did this field not appear in reporting?”

Offer two owner-run reviews at a fixed price or as a carefully bounded pilot. Each review should cover one form, one project and no more than two submitter routes. Give the team the four-point card and a short list of unresolved questions. Continue only if a participant asks for a second form, a staff handover note, or a repeat review after a change. That is evidence that the problem repeats.

Stop if the work requires access to confidential submissions, identity verification, data migration, bespoke integrations or legal interpretation. Those requests signal a different level of risk and expertise.

The risk is collecting more than the team can use

Forms can create a false sense of control. Making every field required can discourage people from submitting, while collecting identity information without a real follow-up purpose can damage trust. The right amount of information depends on the request and the people involved.

There is also platform dependence. A form's behaviour can vary with plan, permissions, internal versus external use, and connected automations. A reviewer should document the exact path tested and avoid broad claims about every account. Platform documentation remains the authority for configuration details.

The strongest small service therefore remains modest: prove the route, record the gap, and leave account actions to the team.

A request deserves a usable origin

The missing “Reported by” name is not merely a field problem. It is a reminder that work begins with a relationship: somebody asked, somebody needs to decide, and somebody may need a reply. An intake provenance card makes those conditions testable before a form becomes a quiet queue of orphaned tasks.

For a small operator, that is a credible place to help. Offer a narrow observation exercise with a plainly stated boundary. If the team can prove source, reply route, decision fields and triage ownership with a safe test, the form has a much better chance of producing work that can actually move.

Sources

• Asana community question on the missing reported-by name
• Asana forms
• Asana form field mapping
• Asana pricing

Related Reading

• Late Invoices Are Often an Onboarding Problem Before They Become a Collection Problem
• The Missing Layer in an Ad-Fraud Conversation