Asana for Internal Requests: Forms, Rules, and Workload (A Complete Playbook)

Internal requests—design tweaks, data pulls, access permissions, content reviews—are the hidden tax on productivity. They arrive in DMs and emails, lack the right details, and bounce between people. Asana can turn this chaos into a clean, measurable flow if you set up three core pillars: Forms for intake, Rules for automation, and Workload for capacity. This guide walks small and medium teams through a step-by-step implementation that scales from a single help desk to a multi-department service hub.

The operating model (what “good” looks like)

A strong internal-request setup in Asana has these traits:

• A service catalog of request types, each with a tailored Form that captures the right details the first time.
• A central Intake project where all requests land, auto-routed to the right team or sub-project using Rules.
• Consistent status stages and SLAs that are visible to requesters and measurable for managers.
• Workload views that prevent overcommitment by balancing tasks by assignee and effort.
• Dashboards that show volume, lead time, on-time completion, and bottlenecks.

Blueprint: projects and structure

Create a Portfolio named “Internal Services” and add one project per service line:

• Design Desk
• Marketing Requests
• IT Access & Hardware
• Data & Analytics
• Web Updates
• Facilities

Optionally keep one shared Intake (Routing) project for the main form and triage. The intake project’s tasks are auto-moved to the right service project in seconds.

Standard fields (use across all service projects)

Create custom fields you’ll reuse everywhere:

• Request Type (single select): Design, Data, Access, Content Review, etc.
• Priority (single select): P1 Critical, P2 High, P3 Normal, P4 Low.
• SLA Target (number or single select): 4h, 1d, 3d, 5d.
• Effort (number, hours) or Points (1–8 scale for knowledge work).
• Requester (text or a People field via tags/assignee handoff).
• System/Platform (single select): Google Workspace, CRM, CMS, Billing, etc.
• Compliance Needed (boolean): triggers an approval path.
• Environment (Dev/Stage/Prod) for IT/web.

Keep list sections consistent:

• New (untriaged)
• Ready (approved to start)
• In Progress
• Waiting on Requester
• In Review
• Done

Build forms that collect the right info the first time

Create a Form for each service project, optimized to eliminate back-and-forth. Forms create tasks with mapped fields and templates.

Design Request form (example)

• Short description: “What are we making? (banner, slide, PDF)”
• Required fields: Audience/Use Case, Dimensions, Deadline, Brand/Team, Required Assets (upload), Approver.
• Conditional logic: If “PDF” → ask Page count; if “Social** → ask Channel and Aspect ratio.
• Auto-set fields: Priority defaults to P3, SLA Target to 3d, Effort to 3 points unless deadline < 48h (then set P2 and 1d).

IT Access form (example)

• Request Type: New user, Role change, Hardware, License.
• Person needing access (email).
• System/Group.
• Manager approval required? If Yes → add Manager email and block until approved.
• Auto-add a Checklist via task template: create account, assign group, confirm 2FA, send welcome.

Data Pull form (example)

• Business question (free text).
• Fields/segments needed (multi-select).
• Time window and refresh frequency.
• Sensitive data? If Yes → Compliance Needed = true and route to senior analyst.
• Effort estimate auto-set based on data sources count.

Pro tip: In each form’s Thank you message, link to a “How requests work” page (Asana project overview) with SLA definitions and tips to avoid delays.

Rules: automate triage, enrichment, and handoffs

Rules save hours of manual triage. You can chain multiple rules; Asana executes them in milliseconds.

Universal rules worth copying

• Route by Request Type
  Trigger: Task added to Intake project
  Condition: Request Type = Design
  Action: Add task to Design Desk and remove from Intake
• Auto-assign by domain owner
  Trigger: Field changed → System/Platform = CMS
  Action: Assign to Web Lead; set Section to Ready; add Followers: Product Manager and QA
• SLA deadline stamping
  Trigger: Task created
  Actions: If Priority = P1 → set Due Date = today + 0.25d; P2 → today + 1d; P3 → +3d; P4 → +5d
• Request quality check
  Trigger: Task created
  Condition: Attachments empty AND Request Type = Design
  Action: Comment with a template asking for assets; set Section to Waiting on Requester; pause SLA (custom field flag)
• Compliance approval
  Trigger: Compliance Needed = true
  Action: Add Approver; create Approval subtask; block main task until Approved; notify Compliance channel via Slack
• Escalation
  Trigger: Due Date approaching in 1 day AND Status ≠ In Review/Done
  Action: Increase Priority; notify project owner; add 🔴 label

Task templates + Rules work together

Create a Task Template per request type with subtasks and custom-field defaults. Example: “Web Update Template” subtasks:

• Clarify copy and screenshots
• Apply change on Stage
• Peer review
• Deploy to Prod
• Verify analytics event

Rule: when Request Type = Web Update, apply the template and set Effort = 2 points.

Visual execution: views your team will actually use

• Board View for daily work: columns by Section, card legend by Priority, quick filters “Only My Tasks”, “Due this week”.
• List View for batch edits: sort by Due Date, then Priority.
• Timeline for larger requests with dependencies (e.g., content + design + web).
• Calendar view for planned releases or maintenance windows.
• Saved filters: P1 only; Waiting on Requester; Over SLA; Compliance Needed.

Use Project Overview to pin the service catalog, SLA table, and definitions of “Ready” and “Done”.

Workload: protect people from overcommitment

Workload (Business/Enterprise) lets you see capacity by person across projects.

Set up capacity

• Choose a single effort unit (hours or points). Don’t mix.
• In Portfolios → Workload, set each teammate’s weekly capacity:
  Designer A: 20h (leaves 20h for meetings/strategy)
  Analyst B: 15 points (if points reflect complexity)
• Map which custom field is your effort source. Ensure all service projects use the same field.

Make Workload actionable

• Color over-capacity in red; adjust by reassigning or moving due dates directly from Workload.
• Use Scenario planning before accepting rush P1s: drop the tentative task on Workload to see who has headroom. If no one, negotiate scope or deadline with the requester instead of silently overloading the team.
• Pair with Goal/Portfolio Progress to show leaders the cost of ad-hoc work vs strategic projects.

SLAs that mean something

Define SLAs per Request Type and Priority, not one-size-fits-all. Example:

• Design: P1 same-day, P2 two business days, P3 five business days
• IT Access: P1 4 hours, P2 1 day, P3 3 days
• Data Pull: P1 24 hours for existing datasets; net-new 5 days

Implement with Rules that set Due Date and a SLA Target field. Track whether “Due Date met?” with a formula proxy (use a rule to flip On-time to No when a task moves to Done after the due date, or create a “Completed At” custom date via completion rule and compare in reporting).

Approvals and proofing flow

For creative and content:

• Use Proofing on attachments to collect time-stamped comments directly on images or PDFs.
• Create an Approval task or use the Approval task type. Rule: when subtask “Approval” is marked Changes requested, move main task back to In Progress and @mention the owner with the requested changes. When Approved, auto-move to In Review with Due Date today.

For IT/web:

• Require a Peer review subtask and use Rule: cannot move to Done until Peer review is completed (enforced by a human gate; Asana Rules can comment or re-set the Section if a checklist remains open).

Dashboards: measure and improve

In each service project, create a Dashboard with widgets:

• Requests by Request Type (bar)
• Volume over time (line)
• Average lead time (New → Done) by Request Type (bar)
• SLA attainment % (number)
• Overdue tasks (list widget)
• Work in progress by Assignee (bar)
• Waiting on Requester count (number)

In the Internal Services Portfolio, add:

• Total requests this month vs last
• P1 count and average time to resolve
• Team capacity vs forecast (from Workload)
• Bottleneck stage (time in stage proxy)

Tip: Review the dashboard weekly, prune widgets no one reads, and add one improvement action item every cycle.

Intake etiquette: set expectations publicly

Reduce noise by educating requesters:

• Pin a “Start here” guide in each project’s Overview and paste it into the Form confirmation message.
• Define the minimum info needed for “Ready” (example: exact dimensions, copy, link to brief, deadline).
• Explain prioritization rules and SLA clock pauses (e.g., if Waiting on Requester, SLA is paused).
• Provide a track-your-request saved search they can open anytime.

Integrations that matter

• Slack/Teams:
  Post P1 creations to #service-alerts. Allow “Create Asana task from message” for quick escalation. Send status change notifications for Done and Changes requested to the request thread.
• Email to Asana:
  For departments living in email, route requests to a unique project email; Rules add fields based on subject (e.g., subject contains “[ACCESS]” → Request Type = IT Access).
• Drive/SharePoint:
  Enforce a folder structure by template. Rule: on task creation, add a shortcut to the correct client or campaign folder.
• Jira/Dev tools:
  When a web request requires code, create a linked Jira issue; keep the original Asana task as the business request, and auto-update status when Jira transitions to Done.
• Calendar:
  For deployments, mirror Due Dates to a shared calendar so stakeholders see upcoming changes.

Security, privacy, and compliance

• Use private projects for HR, finance, or anything sensitive.
• Restrict who can submit to certain Forms by sharing links only internally or whitelisting domains.
• Create separate projects for Prod access vs General access so permissioned users don’t see sensitive histories.
• If you log PII, instruct teams to put PII in encrypted systems and only add IDs or links in Asana.

30-day rollout plan

Week 1

• Create Internal Services Portfolio, Intake project, and 2–3 service projects.
• Build Forms for the top two request types; draft Task Templates.

Week 2

• Implement Rules: routing, SLA stamping, quality checks, compliance approvals.
• Standardize stages and custom fields across projects.

Week 3

• Turn on Workload, set capacities, and review conflicts.
• Launch Dashboards with 4 key widgets; remove or add based on feedback.

Week 4

• Publish the “Start here” guide and Form links.
• Train requesters (15-minute demo).
• Hold a retro; capture top three process fixes and ship them.

Common pitfalls and easy fixes

• Too many priorities: limit to four and define each.
• Vague forms: add conditional questions per Request Type.
• Shadow channels: disable ad-hoc DM requests by policy; point to Forms.
• Over-automation: if Rules create confusion, simplify to route + SLA + one quality guard.
• Capacity mismatch: if Workload is always red, use data to renegotiate SLAs or add headcount.

Real-world examples

A 6-person design team handles 200+ requests/month. After Forms and Rules, their first-response time fell from 2 days to 4 hours and on-time delivery climbed from 62% to 88% in two months. A 3-person IT desk split access vs hardware into separate projects and slashed average resolution time by 35% by pausing SLAs when Waiting on Requester and auto-assigning by system owner. A marketing ops duo used Workload with points and discovered half their “quick edits” were really multi-hour jobs; they reset expectations and reduced after-hours work by 40%.

Final take

Asana can be a lightweight internal-service platform when you anchor on good intake, sensible automation, and visible capacity. Start with one service project and its Form, add routing and SLA Rules, and switch on Workload to prevent accidental overtime. Within a few weeks, you’ll spend less time chasing details and more time actually completing requests—with the data to prove it.