Stop Forwarding Work Into the Void

Stop Forwarding Work Into the Void

“Can you just forward this to the right person?”

There it is. The sentence that makes my eye twitch.

A customer sends an invoice question to Support. Support forwards it to Finance. Finance forwards it to Operations. Operations replies, “I think Sarah handles this.”

Sarah is on holiday.

Five days later, the customer sends another email. This time, the subject line contains three question marks.

We have successfully moved the message through four inboxes. We have not completed one piece of work.

Every forward costs attention. Every new recipient must read the history, understand the context, and decide whether the problem belongs to them.

Multiply that by 30 requests a week. You are not managing a process. You are funding a very inefficient postal service.

I do not solve this with another meeting about communication. I build a simple routing Flow with one owner, one record, and one exception lane.

The Chaos

Forwarding feels productive because the email disappears from your immediate view.

This is the trap.

You clicked a button. You typed “FYI.” You mentally crossed something off your list.

But the work did not disappear. It changed location.

Forwarding is not assigning. Forwarding is hoping.

Here is what the typical forwarding workflow looks like:

1. A request arrives in a shared inbox.
2. Someone reads it and guesses who should handle it.
3. They forward it with a vague message.
4. The recipient assumes someone else is coordinating.
5. The original sender asks for an update.
6. Everyone searches their inbox.

Notice what is missing.

There is no recorded owner. No deadline. No reliable status. No proof that anyone accepted responsibility.

The only tracking system is collective memory.

And collective memory is terrible software.

The real damage is not the extra clicking. It is the uncertainty. Managers cannot see outstanding work. Team members duplicate effort. Customers chase answers that should already exist.

Clear is kind. Unclear is expensive.

The System

I built a simple Flow in Power Automate to replace this relay race.

Nothing fancy. No artificial intelligence required. No six-month transformation project.

Just a few rules that everyone can understand.

Step 1: Create one entry point.

Requests arrive through a designated shared mailbox or intake address.

Not Sarah’s personal inbox. Not a private Teams message. Not the mysterious chat group created last Tuesday.

One entry point gives us one place to observe incoming work.

Step 2: Define routing rules.

I use a small routing table:

If the message…	Then assign to…
Comes from a known vendor and concerns an invoice	Finance queue
Contains a recognized contract topic	Legal or contract owner
Concerns access or permissions	IT queue
Matches no reliable rule	Intake review queue

The rules are ordered. Specific matches take priority over broad ones.

A subject containing “invoice” does not automatically override a known security request. Context matters.

Step 3: Create a work record.

The Flow creates an item in a SharePoint List, Planner, or another shared task system.

Every item receives:

• A unique reference
• The original message link or secure reference
• The assigned owner
• The arrival timestamp
• A status and next-action date

Now the email is no longer just correspondence.

It is visible work.

Step 4: Notify the owner once.

The owner receives a Teams notification with a link to the tracked item.

Not six reminders. Not three copied managers. Not a public channel containing confidential attachments.

One useful notification.

Step 5: Log what happened.

The system records the routing decision and any later reassignment.

If someone asks where the request went, we check the record.

We do not conduct an archaeological expedition through Outlook.

The Exception Is Part of the Process

Here is where most quick automations fail.

Someone creates rules for the obvious cases and forgets that humans send terrible emails.

Subject: “Question.”

Attachment: “final_NEW_2.pdf.”

Message: “Please advise.”

What category is that?

I do not pretend the Flow can read minds.

If the message is unclear, it enters an exception queue with a named reviewer. The reviewer decides where it belongs and can update the routing rule for next time.

An unknown request is not an automation failure.

An unknown request without an owner is a process failure.

The system must also allow reassignment. Wrong routes happen. The important part is that ownership changes remain visible.

One Request. One Owner. One Next Action.

The routing Flow handles delivery. People still handle decisions.

I use three rules with every team:

1. One accountable owner: A team can collaborate, but one person or explicitly managed queue remains responsible.
2. One visible status: New, In Progress, Waiting, or Done. Everyone uses the same definitions.
3. One next-action date: If the item is waiting, we record who or what it is waiting for and when to review it.

No “someone is looking into it.”

Who?

No “we should follow up soon.”

When?

Telepathy is not a management strategy.

Measure Ownership, Not Forwarding Speed

I do not celebrate when the team forwards emails faster.

I measure whether requests become owned work.

Every week, I check:

• How many incoming requests received an owner?
• How long did assignment take?
• How many requests remain unassigned?
• How many were routed incorrectly?
• How many exceeded their next-action date?

If assignment is fast but completion is slow, the routing Flow is not the bottleneck anymore. We investigate the actual work.

That is the point of a good process. It makes the next problem visible.

BEFORE: The forwarding chain

Incoming email -> Support -> Finance -> Operations -> Unknown owner

AFTER: A recorded handoff

Incoming email
      |
      v
Routing Flow
      |
      +-- Rule matched --> Tracked work item --> Named owner
      |
      +-- No match ------> Exception queue ----> Named reviewer
                                                      |
                                                      v
                                             Assign and log owner

Stop Passing the Parcel

Forwarding has its place. Sometimes you genuinely need to share information.

But when forwarding becomes the standard way to assign work, you have built a workflow out of guesses.

Replace the guesses with rules.

Replace the forwarding chain with a tracked record.

Replace “I thought you had it” with a named owner.

Process is not bureaucracy. Process is freedom.

And the right person should receive the work without everyone else becoming a full-time email router.

FAQs

Why is forwarding emails a bad way to assign work?

Because forwarding moves information without guaranteeing ownership, tracking, or completion. The recipient may never act, and the sender has no reliable status.

Can Power Automate route incoming requests automatically?

Yes. A Power Automate Flow can classify messages using sender and topic rules, create tracked work items, and notify the appropriate owner. Unmatched requests should go to a review queue.

What if the automation sends a request to the wrong person?

Give each item a reassignment option, log ownership changes, and maintain an exception queue. Automation needs correction paths. Telepathy is not a fallback.