The 25% Misroute: A Request Queue That Depends on Optional Data
Meridian Marketing's creative services team runs one Workfront request queue that receives about 60 submissions a week across three intake forms. Requests are sorted into queue topics for Brand, Digital, and Events. Routing rules send each request to a team based on the Brand field, with a single catch-all rule at the bottom of the list that assigns requests to the Digital team. The Brand field is optional, because the original builder considered it redundant when the requester is internal. The intake manager reports that roughly one in four requests reaches the wrong team, and last month a genuinely urgent request sat in the catch-all queue for nine days. Separately, when the team converts a request into a project, the requester's budget estimate and desired launch date no longer appear anywhere the delivery team can see, so project managers re-key both fields by hand.
1. Diagnose why requests are reaching the wrong team and propose a fix that does not depend on requesters behaving correctly.
Read the worked answer
Two design defects compound each other.
- A routing-critical field is optional. Routing rules evaluate fields in order and assign on the first match. If Brand is blank, no brand rule fires and the request falls through to the catch-all, which is an active misroute rather than a parking state.
- The catch-all rule is a destination, not a safety net. It silently assigns work to Digital, so no one is ever prompted to triage an unrouted item. The symptom is invisible by design.
Fixes, in order of leverage:
- Make Brand required on every form that feeds the queue. Workfront cannot conditionally require a field per topic, so if a field drives routing it must be mandatory on the form itself.
- Replace the catch-all with an explicit Triage assignment to the intake manager (or a Triage team), so unmatched requests surface as a person's work rather than as Digital's backlog.
- Add an urgency indicator (a dropdown with a Rush value plus a required business justification) and give it a routing rule high in the order so urgency escapes the normal path.
- Verify rule order after any change; reordering rules is the most common cause of a queue that 'suddenly' behaves differently.
- Instrument it: a report of open requests where the assigned team is Triage, on the intake manager's dashboard, converted from a silent failure into a visible one.
The test of the fix is not 'do fewer requests fail' but 'when one fails, does someone own it within a day.'
2. Why do the budget estimate and desired launch date vanish from the delivery team's view after conversion, and how would you redesign the intake so the data survives?
Read the worked answer
Conversion does not move data between objects. A request is an issue carrying the request custom form; converting it creates a project, typically from a template, and the project carries whatever custom form the template carries. Those are two separate field sets on two separate objects, so a field that exists only on the issue form has nowhere to land on the project.
That means the team is not losing data, it is storing it on an object nobody looks at after conversion.
Redesign:
- Put the shared fields where both objects can hold them. Add budget estimate and desired launch date to the project custom form attached to the intake template, and confirm in a sandbox exactly how values behave across a real conversion before promising anything to the team. Field-name coincidence is not a guarantee; test the specific path you will ship.
- Keep the issue attached to the project after conversion, and build a report that surfaces issue-level fields alongside the project so the original ask is auditable.
- Separate requester intent from delivery commitment. The requester's 'desired launch' is not the project's planned completion date. Keep them as distinct fields; overwriting planned dates with a requester's wish destroys the schedule's meaning.
- Make manual re-keying unnecessary, not merely discouraged. If a human must copy two values per request, the design has failed regardless of instructions.