How mail really moves — in plain language

If the words “pipeline”, “desks” and “manager review” worry you — this page is for you. It answers, honestly and simply: is my mail normal email? who sees what? can work get stuck if someone is away? and what does the manager-review checkbox actually do? Every statement here was verified against the running system.

Is my mail normal email? Yes.

Let's start with the most important thing, because it answers your biggest worry.

When you write a message and press send, it is delivered immediately. Just like normal email. The person you sent it to sees it right away, opens it right away, and can reply right away. Nothing holds it. Nothing hides it. There are no desks, no stages, no approvals in the way.

The "pipeline" you heard about — the one with three desks — does not apply to your messages. It only applies to one very specific thing: a formal paper letter that arrives from outside the organization and that someone deliberately logs into the system as an official record. Your everyday messages never go anywhere near it.

And one more reassurance: replying is never blocked. Even for those official letters, the very first person who receives one can reply immediately. No stage, no desk, no checkbox ever takes away the reply button.

• Ordinary message → sent and delivered instantly, like any email.
• Pipeline → only for official incoming letters that someone chooses to register.
• Manager review → only if the sender ticks a box on purpose (and even then, the message still sends immediately — more on that below).

So if you never touch those features, your mail behaves exactly like the email you already know.

The official-correspondence pipeline, told as a story

Imagine the old paper mailroom. A formal letter arrives from another organization. In the paper world, it would pass across three desks before being filed. The system simply recreates those three desks on screen — nothing more mysterious than that.

  A formal letter arrives from outside
        │
        ▼
  [ 1 · Receive Desk ]  someone LOGS it: "this official letter arrived today"
        │
        ▼
  [ 2 · Review Desk ]   someone reviews it and chooses ONE of:
        │                  • "finish here"  → journey ends
        ▼                  • "forward to Secretary" ↓
  [ 3 · Secretary Desk ] final stamp → finalized & filed

  ► A desk is a LABEL on the journey — never one specific person.
  ► Any signed-in colleague can move the letter to the next desk.
  ► Reply is available at EVERY point — even at desk 1.

The letter's journey

• Desk 1 — the Receive Desk. Someone logs the letter into the system: "this official letter arrived today." That's the registration step.
• Desk 2 — the Review Desk. Someone looks it over and makes one choice: pass it on to the Secretary Desk, or say "this is done, finish here."
• Desk 3 — the Secretary Desk. If it was passed on, someone gives it the final stamp: finalized.

The order is always the same: Receive, then Review, then (sometimes) Secretary. That's the whole journey.

The most important truth: desks are labels, not people

Here is what removes most of the fear. A desk is a label on a stage of the journey — it is never one specific person. No stage is ever "assigned to Ahmed" or "waiting on Fatima." So a stage can never be stuck on someone. In fact, in the system as it is today, any signed-in colleague can move the letter to the next desk. If one person is away, anyone else can step in and advance it. The work is never locked to a single pair of hands.

Who sees it?

Same rule as any message: the sender, the people it was addressed to, and — if a department was addressed — everyone in that department. There is no "hidden until it reaches your desk." If it's addressed to you, you see it from the start. If it isn't, you simply never see it.

Two honest warnings

• There is no "reject" or "send back" inside this chain. It only moves forward or stops.
• Nothing reminds anyone automatically. A forgotten letter doesn't get lost — but it does sit quietly and wait until a human moves it. Someone has to remember to check.

Registering a received letter — what it looks like on screen

This is the part you asked about directly: “an official paper letter arrived and I need to archive it — so I am the recipient, and I choose who receives it?” Yes — almost exactly. Here it is, field by field, on the real screen.

Step 1 — open a new message

DWMail → New message. The same window you use for everyday email is also where an incoming letter is registered — you just fill in the extra “official” details below. In the top “To” box choose the internal receiver (a department is best — see the shared-tray section below).

Step 2 — open “Correspondence options”

Click Correspondence options in the ribbon. This reveals the fields that turn an ordinary message into an official record:

• Classification / confidentiality (السرية) — Low / Medium / High.
• Requires approval (يتطلب اعتماد) — ask a manager to endorse it. This does not hold delivery — see “Manager review, step by step”, below.
• Notes (ملاحظات) — free internal notes about the correspondence.

Step 3 — record the paper: the “Hard copy” fields

This is the heart of archiving a received paper. Expand Hard copy (نسخة ورقية) and record where the physical letter came from and how it was received — its provenance. None of these are email addresses; they mirror the stamp-and-register book of the old paper mailroom:

What happens when someone is away (the fear answered)

You asked the hard question directly: what if the employee is in the hospital, or worse — does the work stop? Here is the honest answer: if the work was sent to a department, no. It does not stop.

The shared tray

Think of a department's mail as landing in one shared tray on a shared table, not in anyone's personal drawer. Everyone in the department (including its sub-departments) sees the same tray. This is the default way departments receive mail.

From that tray, anyone in the department can:

• Claim (استلام) an item — "I'm handling this," so two people don't do the same work.
• Release (إلغاء الاستلام) it — put it back in the tray for someone else.
• Assign it to a colleague — hand it directly to someone, or take it yourself (إسنادها إليّ).

Now the key part. If the person who claimed an item disappears — sick, hospitalized, left the company — the department manager can release it back to the tray, and anyone else picks it up. The item belongs to the department, not to the person. Work does not die with a person.

The other two department modes

• Fan-out: every member gets their own private copy and acts on their own copy. If one person is absent, their copy just sits unread — but everyone else still has theirs, so the department as a whole still knows.
• Shared + notify: the same shared tray, plus everyone gets an alert when something arrives.

Delegation — planned absences are now covered, platform-wide

For a planned absence (leave, travel), you can hand your authority to a colleague ahead of time: DWMail → Settings → Delegation (التفويض). You pick the person, the services it covers (all, or specific ones — mail approvals, WorkFlow requests assigned to you…), and a start–end period; they must accept before it activates; either of you can end it at any moment. While active, your colleague sees your pending items with an “on behalf of” (بالنيابة عن) badge and can act — the record always shows who actually pressed the button. Even signing can be delegated, but only if you explicitly ticked “includes signing authority” — and the deputy always signs with their own signature, marked «بالنيابة عن» on the document itself. Full details in the Email guide §11i.

Where work could still get stuck — and the safety valve

• An approval sent to one specific named person who is suddenly gone (no delegation arranged). This no longer needs a database fix: an administrator can now list all pending approvals and reassign one to another person — or cancel it. That is the safety valve for the hospital case.
• A message addressed personally to one user (not to their department). Nobody else can claim it — it's like a letter in someone's personal locked drawer. This is why work items should be addressed to departments.

So the advice is simple

• For work items, address the department, not the individual. Shared tray = safety net.
• For approvals, prefer the department-manager route over naming one specific person.
• Before a planned absence, set up a delegation — it takes a minute.

And, plainly, what the system does not have today

• No automatic escalation to the boss when something waits too long.
• No deadline that auto-moves an item on its own.

With the shared tray, the manager's release power, delegation for planned absences, and the admin's reassign-or-cancel for surprises — an absence is an inconvenience, not a crisis.

Manager review, step by step

This is the feature that confuses most people, and honestly, it works differently from what you might expect. Here is the one surprising truth to hold onto:

Ticking "requires approval" (يتطلب اعتماد) does NOT hold your message back. It sends immediately. The manager's approval is a stamp added afterwards, on top of a message that already arrived.

Think of it like mailing a letter and then asking your manager to add an official seal to the copy on file — the letter is already in the recipient's hands.

  You tick "requires approval" ──▶ SEND
        │
        ▼
  message DELIVERED immediately (recipients read & can reply now)
        │
        ▼
  approval request opens for: any manager of YOUR department
                              (fallback: your direct boss)
        │
        ├── Approve (اعتماد)  → endorsement recorded. Nothing else changes.
        ├── Return  (إرجاع)   → message PULLED BACK to your drafts ("fix & resend")
        └── Reject  (رفض)     → message PULLED BACK to your drafts ("no")
                               (pulled back = it disappears from recipients' inboxes)

The walk-through

• Step 1. You write your message and tick "requires approval" (يتطلب اعتماد) before sending.
• Step 2. The message is sent and delivered right away. Your recipients see it and can read and reply immediately — the review has not started yet and they are not waiting on anything.
• Step 3. The system opens an approval request for a manager. Who? First choice: any manager of your department. If your department has no manager set up, it falls back to your direct boss. If neither exists, no approval is created at all — the message simply stays sent, and that's the end of it.
• Step 4. The manager opens the sent message and sees three buttons: Approve (اعتماد), Reject (رفض), Return (إرجاع). Everyone else who opens the message sees the approval status too, but only as information — only the eligible manager gets the buttons.
• Step 5. What each button does:
  • Approve (اعتماد): the official endorsement is recorded on the message. Nothing else changes — it was already delivered.
  • Return (إرجاع): "fix this and send it again." The message is pulled back: it disappears from the recipients' inboxes and lands back in your drafts as a draft, ready to edit and resend.
  • Reject (رفض): "no." Same pull-back — the message vanishes from recipients' inboxes and returns to your drafts — but the meaning is refusal, not "try again."

What recipients experience if it's returned or rejected

They saw the message when it arrived. If the manager later returns or rejects it, the message disappears from their inbox — because it became a draft again. So be aware: recipients may have already read the first version before it was pulled back.

One footnote: there is also an older, separate "office manager" flow

Separately from this checkbox, the system has an older routing feature built for a boss's office: an office manager forwards an item up to the boss, the boss records a recommendation, and the office manager publishes it as directives to departments (or completes it on the boss's behalf). That is a different mechanism for a different situation. For everyday "my manager should endorse this," the checkbox flow above is the one you'll use.

Quick decision guide

Keep this table handy. Find your situation on the left, do the thing on the right.