monday.com Form Routing: 8 Real Examples
Published on May 05, 2026
Form routing lets you serve different forms from a single link based on monday.com column values. Instead of managing separate form URLs for each department, request type, or workflow stage, you create one link and let the routing rules decide which form the respondent sees.
This post walks through eight real monday.com form routing examples you can build with FormFlow today.
Quick answer
- Form routing uses monday.com column values (Status, Dropdown, People, etc.) to decide which form to show.
- Rules run top to bottom — first match wins. Always set a default form as a fallback.
- Combine routing with visibility rules inside each form for two layers of dynamic behavior.
Build your first route. Install FormFlow and set up monday.com form routing in under 30 minutes.
How monday.com Form Routing Works in FormFlow
Before the examples, here is how routing works at a high level:
- You create multiple forms on the same board (each with different fields, layouts, or purposes)
- You create a route with rules that check column values on the item
- When someone opens the route link for a specific item, FormFlow evaluates the rules top to bottom
- The first matching rule determines which form is displayed
- If no rule matches, the default form is shown
This means one link can serve completely different experiences depending on the item’s data. Learn the full setup in Forms Routing documentation.
Example 1: Support Ticket Triage by Priority
Use case: Your support team uses different forms for different priority levels. High-priority tickets need more detail upfront (affected systems, number of users impacted, workaround status). Low-priority tickets just need a description.
Board setup:
- Status column: Priority (Critical, High, Medium, Low)
Routing rules:
| Rule | Condition | Form |
|---|---|---|
| 1 | Priority = Critical | Critical Incident Form (detailed fields, escalation contact, SLA timer) |
| 2 | Priority = High | High Priority Form (affected area, impact description, timeline) |
| Default | — | Standard Ticket Form (description, category, contact email) |
Why this works: Critical incidents get the right information collected immediately without back-and-forth. Standard tickets stay lightweight so they are quick to submit. One link serves both experiences.
Example 2: IT Request by Category
Use case: Your IT team handles equipment requests, software access, account setup, and hardware repairs. Each type needs different fields, but employees should not have to find the right form themselves.
Board setup:
- Dropdown column: Request Type (New Equipment, Software Access, Account Setup, Hardware Repair)
Routing rules:
| Rule | Condition | Form |
|---|---|---|
| 1 | Request Type = New Equipment | Equipment Request Form (device type, specs, budget code, manager approval) |
| 2 | Request Type = Software Access | Software Access Form (software name, license type, justification) |
| 3 | Request Type = Account Setup | Account Setup Form (systems needed, start date, department) |
| 4 | Request Type = Hardware Repair | Repair Form (device serial number, issue description, photos) |
| Default | — | General IT Request Form |
Combine with visibility rules: Inside each form, use visibility rules to show follow-up fields. For example, if the equipment type is “Laptop”, show fields for OS preference and screen size. If it is “Monitor”, show resolution and mount type.
For a full walkthrough of building this setup, see How to Build an Internal Request System.
Example 3: Client Onboarding by Service Tier
Use case: An agency onboards clients differently based on their service package. Enterprise clients need detailed brand guidelines, access credentials, and stakeholder lists. Starter clients need basic contact information and project goals.
Board setup:
- Status column: Tier (Enterprise, Professional, Starter)
Routing rules:
| Rule | Condition | Form |
|---|---|---|
| 1 | Tier = Enterprise | Enterprise Onboarding Form (brand guidelines upload, stakeholder list, access credentials, SLA preferences) |
| 2 | Tier = Professional | Professional Onboarding Form (brand assets, primary contact, project scope) |
| Default | — | Starter Onboarding Form (contact info, project goals, timeline) |
Why this works: Each client sees a form tailored to their engagement level. Enterprise clients are not confused by a stripped-down form, and starter clients are not overwhelmed by fields that do not apply to them.
Example 4: Employee Updates by Department
Use case: HR sends update form links to employees quarterly to refresh their personal information. But Engineering needs to update tool access and certifications, Sales needs territory and quota info, and everyone needs basic emergency contact details.
Board setup:
- Dropdown column: Department (Engineering, Sales, Marketing, Finance, HR, Operations)
Routing rules:
| Rule | Condition | Form |
|---|---|---|
| 1 | Department = Engineering | Engineering Update Form (certifications, tool access, GitHub username, on-call preferences) |
| 2 | Department = Sales | Sales Update Form (territory, quota target, CRM access level, client list) |
| 3 | Department = Marketing | Marketing Update Form (campaign tools, social handles, content calendar access) |
| Default | — | General Employee Update Form (emergency contacts, address, phone, dietary preferences) |
Security: Use per-item passwords so each employee only accesses their own record. Automate password generation with monday.com automations.
See How HR Teams Use FormFlow for Onboarding for the full onboarding workflow.
Example 5: Project Feedback by Stage
Use case: You collect client feedback at different project milestones. The questions change depending on where the project is in its lifecycle.
Board setup:
- Status column: Stage (Kickoff, Midpoint, Delivery, Post-Project)
Routing rules:
| Rule | Condition | Form |
|---|---|---|
| 1 | Stage = Kickoff | Kickoff Feedback Form (clarity of scope, communication quality, expectations alignment) |
| 2 | Stage = Midpoint | Midpoint Check-In Form (progress satisfaction, blockers, scope changes) |
| 3 | Stage = Delivery | Delivery Feedback Form (quality rating, timeline adherence, issue resolution) |
| Default | — | Post-Project Review Form (overall satisfaction, NPS, testimonial permission) |
Why this works: Feedback is stage-appropriate. You do not ask about delivery quality during kickoff, and you do not ask about expectations alignment after the project is done. One link per client, reused at each milestone.
For more on feedback forms, see Client Feedback Forms: Collecting Reviews with FormFlow.
Example 6: Vendor Management by Status
Use case: Your procurement team manages vendors at different lifecycle stages. New vendors need full registration, active vendors need annual certification renewals, and exiting vendors need offboarding documentation.
Board setup:
- Status column: Vendor Status (New, Active, Renewing, Offboarding)
Routing rules:
| Rule | Condition | Form |
|---|---|---|
| 1 | Vendor Status = New | Vendor Registration Form (company details, insurance, tax ID, bank details) |
| 2 | Vendor Status = Renewing | Renewal Form (updated insurance certificate, license renewal, contact changes) |
| 3 | Vendor Status = Offboarding | Offboarding Form (final invoice, equipment return, access revocation checklist) |
| Default | — | Vendor Info Update Form (contact details, address, capabilities) |
Security: Add per-item passwords and geographic restrictions for vendors in specific regions.
Example 7: Operations Intake by Location
Use case: A multi-location company uses one board for facility maintenance requests. Each location needs slightly different fields (building codes, floor plans, local contacts).
Board setup:
- Dropdown column: Location (HQ - New York, Office - London, Warehouse - Chicago, Remote)
Routing rules:
| Rule | Condition | Form |
|---|---|---|
| 1 | Location = HQ - New York | NYC Maintenance Form (floor number, building wing, NYC-specific fields) |
| 2 | Location = Office - London | London Maintenance Form (building code, UK compliance fields) |
| 3 | Location = Warehouse - Chicago | Warehouse Form (zone, rack section, equipment ID) |
| Default | — | General Maintenance Form (location description, issue type, photos) |
Why this works: Location-specific fields (building codes, zone numbers) only appear for the relevant location. The maintenance team gets the exact information they need to dispatch the right crew.
Example 8: Multi-Stage Approval Workflow
Use case: Purchase requests go through multiple approval stages. Each stage needs a different form: the requester fills in details, the manager reviews and approves, and finance verifies the budget.
Board setup:
- Status column: Approval Stage (Draft, Manager Review, Finance Review, Approved, Rejected)
Routing rules:
| Rule | Condition | Form |
|---|---|---|
| 1 | Approval Stage = Draft | Request Form (item description, vendor, estimated cost, justification) |
| 2 | Approval Stage = Manager Review | Manager Approval Form (read-only request details + approval decision + comments) |
| 3 | Approval Stage = Finance Review | Finance Review Form (read-only request + manager decision + budget code + PO number) |
| Default | — | Read-Only Summary Form (all fields visible, none editable) |
Key technique: Use read-only fields to show prior-stage data without allowing edits. Each approver sees the full context but can only fill in their stage’s fields.
Routing Best Practices
Rule Order Matters
Rules evaluate top to bottom, and the first match wins. Put your most specific rules at the top:
- Most specific conditions first (e.g., Priority = Critical AND Department = Engineering)
- Broader conditions next (e.g., Priority = Critical)
- General conditions last
- Default form catches everything else
Always Set a Default Form
If no rule matches (a column is empty, a value was renamed, a new option was added), the default form gives respondents something useful rather than an error.
Test Before Launch
Use test links to validate routing rules before sharing with respondents:
- Publish your route
- Open the test link and select different items with different column values
- Confirm the correct form appears for each scenario
- Check edge cases: empty columns, unexpected values, newly added options
Combine Routing with Visibility Rules
Routing chooses which form to show. Visibility rules control which fields to show within that form. Use both:
- Routing: Show the IT form vs the HR form vs the Finance form
- Visibility rules within each form: Show laptop fields vs monitor fields based on the equipment type dropdown, with AND/OR conditions across multiple fields when one dropdown is not enough to decide
Keep Forms Focused
Instead of one giant form with dozens of conditional fields, create multiple focused forms and let routing select the right one. This is easier to maintain, faster for respondents, and simpler to debug.
Frequently Asked Questions
Can I use routing with insert forms? Routing is designed for update forms where each item has column data to evaluate. For insert workflows, use visibility rules within a single form to show/hide fields dynamically.
What columns can I use in routing conditions? Status, People, Dropdown, and other column types that have defined values. The conditions use operators like equals, not equals, and contains.
What happens if I add a new dropdown option but forget to update routing? The default form is shown. This is why setting a default form is critical: it prevents dead ends.
Can I have multiple conditions per rule? Yes. Each rule can have multiple conditions. All conditions must match for the rule to fire.
Get Started with Form Routing
Pick one of the examples above that is closest to your workflow, install FormFlow, and build your first route. Most teams have routing working in under 30 minutes.
