Docs: multiple traffic forwarding profiles coverage gaps and fix ideas

[Thomas Detzner (tdetzner)]

Adds docs/featureImprovements/mtfp-coverage-fixideas.md, a proposal document for the remaining multiple traffic forwarding profiles (MTFP) coverage gaps.

Documentation only — no module or behaviour changes.

Context

PR #82 fixes the immediate breakage on preview tenants (a false Private Access is not enabled error), but that only restores the on/off gate. The exports and provisioning still have no notion of forwarding-profile topology. This document captures the analysis so the work can be scoped and the blockers raised with the preview product team.

Tracking issue: #83

Contents

• Background on the two previews (Multiple Forwarding Profiles for Private Access on private, Fail-Close on internet) and the per-profile attributes they introduce — priority (101–199 for custom), state, clientFallbackAction, user/device assignment, device-platform assignment, and the AND evaluation between the two assignment axes.
• What was already fixed, including why the array member-enumeration made the old guard throw.
• Three remaining gaps — export loses profile topology, provisioning cannot reproduce a preview tenant (security-relevant: apps intended for a narrow custom profile become broadly reachable), and the IA export misses fail-close posture.
• Proposed two-CSV shape — an additive ForwardingProfiles column on the existing app CSV plus a new {timestamp}_EPA_ForwardingProfiles.csv, following the pattern Export-EntraInternetAccessConfig already uses for its separate Policies and SecurityProfiles CSVs. Backward compatible: existing CSVs keep importing unchanged.
• 12-item work breakdown with relative sizing and risk, split into a read-only slice and a write slice.
• Five blockers that gate the write slice, all needing preview product team input — chiefly that the profile→app join has no confirmed public Graph surface and associations is still opaque.
• A/B recommendation — ship the honest read-only export now, defer everything that depends on the unconfirmed join model.
• Four open questions for the preview team.

Note on placement

This is under docs/featureImprovements/ rather than Specs/, since it is a problem/option analysis rather than an approved design. If it graduates to a committed design, slice A would move to Specs/Export/ following the existing spec conventions.

assistance: agentic-ide
type: docs
agent-tool: copilot-chat
agent-model: claude-opus-5
work-item: n/a