Add Workspace and Tab Group Routing Rules to Microsoft Edge Workspaces (domain/URL → workspace)

[twcau]

Feature Request: Workspace Routing Rules (Domain → Workspace)

Scenario

I maintain a “Job Hunting” workspace and want every seek.com.au link to open in that workspace automatically—regardless of where I click the link (from another workspace window, an external app, or a typed URL).

Current limitation: Edge Workspaces don’t support URL-based automation. While Custom Site Switch can route domains to specific profiles, I intentionally avoid multiple profiles and need this behavior inside Workspaces.

Docs describe Workspaces’ collaboration and organization, but not URL routing rules:

• Microsoft Support — Getting started with Edge Workspaces:
  https://support.microsoft.com/en-us/topic/getting-started-with-microsoft-edge-workspaces-63a5a6d7-3db4-468f-aba8-fdd00dce4c35
• Microsoft Learn — Edge Workspaces overview and prerequisites:
  https://learn.microsoft.com/en-us/deployedge/microsoft-edge-workspaces

---

Goal

Add a policy and user-facing controls to route domains, URL patterns, or protocol/host/path rules directly into specified Workspaces.

---

Feature Request

1. Per‑workspace routing rules

   • Match by Domain, Subdomain, Path, or Regex → open in this workspace.

2. Triggers

   • External app links (OS-level hand-off)
   • Links clicked in other Edge windows/workspaces
   • Typed/go-to-URL and middle‑click/open‑in‑new‑tab behaviors

3. Conflict resolution

   • Priority order: specific path > subdomain > domain > default.
   • If multiple rules match, show a lightweight toast with an override (e.g., “Opening in Job Hunting — change”).

4. User controls

   • Per-open toast: “Always open this site here” (creates a rule).
   • One‑off override: “Open here this time” without saving a rule.

5. Enterprise & policy support

   • Group Policy/JSON that preconfigures rule sets per workspace (similar in spirit to existing policy infrastructure such as UserFeedbackAllowed), with sync via account.

6. Privacy & identity

   • Preserve current Workspaces model: each participant brings their own identity/cookies; routing respects access constraints and shows placeholders for protected content.

7. Resilience & lifecycle

   • If a targeted workspace has been removed/renamed, alert the user and offer options: re‑target to a different workspace, keep rule but disable, or delete rule.

8. Future enhancement (advanced)

   • Granular routing to Tab Groups within a workspace (e.g., route SharePoint IT‑support URLs into the “Customer‑Facing” tab group in the “IT Documentation” workspace).

9. Auditability/logs

   • Optional per‑workspace routing log: when, what URL, source context, and whether an override occurred.

---

Benefits

• Reduced friction: fewer manual window switches; instant context alignment.
• Cleaner projects: all relevant tabs for a topic (e.g., job hunting) reliably land in the right workspace.
• Team alignment: shared Workspaces remain semantically correct; new resources appear where collaborators expect.
• No extra profiles: maintain a single, signed‑in environment while keeping strict project boundaries.

---

Key Requirements (detail)

1. Per‑workspace rule list

   • UI: Workspace Settings → Routing rules
   • Rule types:
     • Domain match: seek.com.au → open in “Job Hunting”
     • Subdomain match: jobs.example.com → open in “Hiring”
     • Path/regex (advanced): example.com/(careers|jobs)/ → open in “Hiring”

2. Triggers

   • External app links
   • Links clicked in other Edge windows/workspaces
   • Typed URLs and middle/open-in-new-tab behaviors

3. Conflict resolution

   • Priority: specific path > subdomain > domain > default
   • When ambiguous: small toast, “Multiple rules match—opening in X (change)”

4. User controls

   • “Always open this site here” (creates a rule)
   • “Open here this time” (one‑off override)

5. Enterprise & policy support

   • Admin-defined JSON (per account/tenant) to preconfigure routing
   • Sync via account (consistent with Workspaces prerequisites)

6. Privacy & identity

   • Keep identities/cookies per user; placeholders for protected content

7. Auditability/logs

   • Optional routing log per workspace

---

Example Rules

• Rule A

  • Match: Domain = seek.com.au
  • Action: Open in Workspace = “Job Hunting”

• Rule B

  • Match: Host = sitename.sharepoint.com
  • Action: Open in Workspace = “Intranet”

• Rule C

  • Match: Path = sitename.sharepoint.com/sites/it-documentation
  • Action: Open in Workspace = “IT Documentation”

• Rule D (advanced)

  • Match: Path = sitename.sharepoint.com/sites/it-support
  • Action: Open in Workspace = “IT Documentation”
    • Open in Tab Group = “Customer‑Facing”

---

Sample UX Copy

• “This site is routed to Job Hunting (manage rules).”
• “Always route seek.com.au to Job Hunting?”
• Workspace Settings → Routing rules → Add rule
  • Match: Domain / Subdomain / Path / Regex
  • Pattern: seek.com.au
  • Action: Open in Job Hunting
  • Save

---

Example Enterprise Policy (JSON concept)

(Conceptual example to illustrate how admins could preconfigure rules; exact schema TBD.)

{
  "WorkspaceRoutingRules": [
    { "pattern": "seek.com.au", "type": "domain", "workspace": "Job Hunting" },
    { "pattern": "sitename.sharepoint.com", "type": "host", "workspace": "Intranet" },
    { "pattern": "sitename.sharepoint.com/sites/it-documentation", "type": "path", "workspace": "IT Documentation" },
    { "pattern": "sitename.sharepoint.com/sites/it-support",
      "type": "path",
      "workspace": "IT Documentation",
      "tabGroup": "Customer-Facing"
    }
  ]
}

[pl4nty]

Might be out-of-scope, but I'd love equivalent pattern-based routing rules for regular profiles. Like many orgs, we use profiles to segment security controls (settings/extensions/etc) based on threat model (standard/dev/prod). Routing prod URL patterns to the prod profile (and dev-to-dev etc) would save us a lot of time